五天速成销售订货系统 Day1：环境搭建踩坑记

《软件工程》个人技能测试给了我们一道满分100分的大题——销售订货系统，要求做传统系统端和飞书审批端两套实现。定了个"5天每天1小时"的冲刺计划，Day1的目标很简单：把Spring Boot工程骨架搭起来，跑通一个最简单的"新建订单"接口。
结果这一个多小时，几乎全花在环境搭建的坑里了。记录一下，给同样在学Java、第一次搭Spring Boot环境的同学参考。
项目骨架长什么样
按销售订单表和产品生产周期表的结构，设计了四张表：
sales_order：销售订单主表（客户名称、交货地址、金额、经理审批等）
order_item：产品明细，订购产品和赠品信息结构基本一样，合并成一张表，用gift字段区分
production_cycle：产品生产周期表，预置了产品A/B/C的数据
order_change_record：对应试卷5.4/5.5条的订单变更和急插单记录

OrderStatus枚举直接照着流程图的每个节点建：接单→评审→交期确认→审核分支→发货/生产→结束，Day3做业务流程联动的时候会直接用上。
技术栈是Spring Boot 3.2.5 + Spring Data JPA + MySQL，Lombok简化实体类代码。

怎么运行
如果你想跑起来，大致是这几步：
装MySQL（本地Community Server免费版，不是云端那种要注册账号的HeatWave服务）
建一个空库：CREATE DATABASE sales_order_db DEFAULT CHARACTER SET utf8mb4;
把application.properties里的用户名密码改成自己的
用IDEA打开工程根目录下的pom.xml（不是打开文件夹！），选"Open as Project"，等Maven把依赖下载完
运行SalesOrderApplication的main方法
用curl测试POST /api/orders接口，能收到201和自动生成的订单号就算跑通

看着简单，但每一步都有坑。

踩坑清单

1. IDEA没识别成Maven项目
   第一次打开的时候，项目目录下压根没有pom.xml，取而代之的是IDEA自己生成的一个空Maven骨架（groupId: org.example）。
   原因：没有直接打开解压后的pom.xml，而是用了"New Project"新建了一个空项目，再把源码文件夹拖进去，pom.xml没跟着进来。
   解决：关掉这个错误的项目，重新Open，直接选中解压后文件夹根目录下的pom.xml本身（不是选整个文件夹），IDEA会弹窗问要不要以Project形式打开，选是。

2. SDK版本和Lombok不兼容
   依赖装完之后，编译直接报错：
   java.lang.ExceptionInInitializerError
   com.sun.tools.javac.code.TypeTag :: UNKNOWN
   原因：项目SDK选的是JDK 26，而Lombok目前还没完全跟上——查了一下，JDK 26今年3月才GA，Lombok内部用的ASM组件目前还不认识JDK 26生成的class文件版本号，官方仓库2月份才提的bug，还没修完。
   解决：与其等Lombok修复，不如换一个成熟稳定的LTS版本。在 File → Project Structure → Project 里把SDK换成JDK 17，问题瞬间消失。
   这里学到一个教训：新出的技术不一定意味着更好用，尤其是生态里的第三方库（比如Lombok这种依赖编译器内部API的工具）往往滞后于JDK新版本好几个月。做项目选型时，LTS版本的兼容性通常比最新版本更可靠。

3. MySQL认证方式的坑：CachingSha2Password

4. 编译过了，运行报错：
   com.mysql.cj.protocol.a.authentication.CachingSha2PasswordPlugin
   原因：MySQL 8+以后默认用caching_sha2_password算法验证密码，Java驱动需要向服务端请求RSA公钥，但默认不被允许。
   解决：JDBC连接字符串里加一个参数：allowPublicKeyRetrieval=true。

5. Access denied（密码验证失败）
   Access denied for user 'root'@'localhost' (using password: YES)
   排查了一圈，最后发现是IDEA用了旧的编译缓存（target目录里还留着之前失败构建时的老配置），改了密码之后没有重新编译进去。Build → Rebuild Project 解决。

6. 配置文件被"手滑"污染两次
   一次是复制粘贴的时候，spring.datasource.url=这个键名被重复粘贴了一遍，变成：
   properties
   spring.datasource.url=spring.datasource.url=jdbc:mysql://...
   驱动直接报"claims to not accept jdbcUrl"，因为这压根不是一个合法的URL了。
   另一次更离谱——测试接口的curl命令被误粘贴进了配置文件里，把spring.datasource.url那一行整个覆盖掉了，导致报错'url' attribute is not specified。
   教训：改配置文件的时候，与其一行行小修小改，不如整个文件全选删除、重新完整粘贴一遍，能避免这种"半行覆盖"的诡异状态。

7. PowerShell里的curl不是curl
   测试接口的时候用curl -X POST ...，报了一堆参数绑定错误。
   原因：Windows PowerShell里curl是Invoke-WebRequest的别名，参数语法跟Linux/Mac的curl完全不一样。
   解决：显式调用curl.exe而不是curl，才是真正的curl程序。另外PowerShell里JSON字符串的双引号要用反斜杠转义（"），这点也和Linux不一样。
   一点感想
   这次踩的坑没有一个是"高深"的技术问题，全是环境配置、路径、语法差异这类新手最容易卡住、又最难在文档里查到的细节。回头看，整个过程其实印证了一句话：环境搭建往往比写业务代码本身更耗时间，尤其是第一次接触某个技术栈的时候。

Day1原本预计1小时能跑通新建订单接口，实际花了更久，但好在每个坑都彻底解决了，之后重复搭建同类环境应该会快很多。

Day2预告
接下来要在Service层里补上5.1、5.2条的业务逻辑：接单时判断库存/产品生产周期，有则走发货分支，无则进入评审流程。这部分是纯业务代码，应该不会再有这么多环境层面的坑了（希望如此）。