汤一白君1. 环境准备与版本选型
1.1 先把JDK和构建工具定下来
用 IntelliJ IDEA 做 Spring Boot 开发，第一件事不是装软件，而是把 JDK 和构建工具理清楚。JDK 我建议直接用 Java 17 或 Java 21 的 LTS 版本，原因很直接：Spring Boot 3.x 强制要求 Java 17 起步，而且从实际项目来看，Java 21 的虚拟线程、Records 这些特性在日常业务代码里确实能派上用场。你要还在用 Java 8，那只能停留在 Spring Boot 2.7.x，很多新版特性都享受不到，时间越久迁移成本越高。
构建工具的选择上，Maven 和 Gradle 各有拥趸。我自己的习惯是多数项目用 Maven，原因很朴素：Spring Initializr 默认生成的是 Maven 项目，IDEA 对 Maven 的支持极其成熟，pom.xml 的依赖提示和冲突分析都做得非常直观，团队协作时心智负担也低。Gradle 适合构建脚本特别复杂的场景，比如多模块的大工程、需要自定义构建逻辑的项目。对大多数 Spring Boot 业务项目来说，Maven 足够，别过度设计。
IDEA 里配置 JDK 的方式也值得说一句：打开 File -> Project Structure -> Project，在 SDK 下拉框里点 Add JDK，选好本地解压的 JDK 目录即可。注意 IDEA 有自己内置的 JBR（JetBrains Runtime），那个是 IDE 自己用的运行时，跟项目编译用的 JDK 是两码事，很多人刚接触时容易搞混。
1.2 IDEA 选哪个版本：社区版还是旗舰版
这个问题几乎每个入门 Spring Boot 的人都会问。社区版免费，但只提供 Java/Kotlin 的基础开发能力；旗舰版收费，但不止多了 Spring 专门的 Bean 跳转、依赖图、自动装配提示，还集成了数据库客户端、HTTP Client、Docker 支持等常用工具。
我的建议是：如果能用正版 License 或者公司有采购，直接上旗舰版，配合 Spring 插件的开发体验差距非常明显；如果是学生或者个人学习，社区版也完全能跑通 Spring Boot 开发，无非是少了几个便捷入口，核心编码体验没有本质差别。IDEA 官方本身也提供 30 天试用期，适合用来评估到底值不值得买。我更推荐在官方渠道下载，尽量不要碰网上那些来路不明的所谓“破解版”，一是安全没保障，工具链里被塞恶意脚本的案例不少；二是团队协作时工具不正规，出了问题很难向同事和领导交代。开发工具上省下的钱，最后大概率会在排查问题上加倍还回去。
1.3 让 Maven 在国内网络环境下跑得更顺
Spring Boot 项目创建后第一件事就是下载依赖，这一步在国内经常慢得让人怀疑人生。解决办法就一条：把 Maven 镜像换成阿里云或者其他国内源。修改 settings.xml 里的 <mirror> 节点，或者直接在 IDEA 的 Build Tools -> Maven 设置里指定自定义的 settings.xml，两种情况我都用过，后者更直观，不用跑到本地目录里找文件。
具体配置参考这一段：
xml复制<mirror>
<id>aliyunmaven</id>
<mirrorOf>central</mirrorOf>
<name>阿里云公共仓库</name>
<url>https://maven.aliyun.com/repository/public</url>
</mirror>
另外，IDEA 里的 Maven 设置还藏着两个常见坑：一是 Maven home path 默认指向 IDEA 自带的 Maven，版本可能偏旧，建议手动指定自己下载的 Maven 3.9.x；二是 Runner -> JRE 选项要和项目的 JDK 版本保持一致，否则构建时偶尔会报 Unsupported major.minor version 的错误。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 创建一个规范的 Spring Boot 项目
2.1 用 Spring Initializr 初始化项目
创建 Spring Boot 项目最稳妥的方式，就是直接在 IDEA 里用内置的 Spring Initializr。操作路径是 File -> New -> Project -> Spring Initializr，然后填 Group、Artifact，选 Java 版本和依赖。这里我建议使用 https://start.spring.io 地址，而不是默认的 https://start.aliyun.com，因为官方地址的版本更新最快，新的 Spring Boot 版本出来当天就能用上，阿里云这个地址偶尔会滞后几个小版本。
依赖选择的原则是“按需加，不要贪多”。很多人创建项目时恨不得把 Spring Web、MyBatis-Plus、Redis、Security 全勾上，结果项目还没写代码，启动时就因为依赖冲突或者配置缺失报一堆错。我建议第一版只加必要的几个：Spring Web、Validation、Lombok（如果团队允许）、Spring Boot DevTools。数据库、消息队列这些等真正要用了再通过 Maven 坐标添加，这样问题出现时你能清楚地知道是哪个新引入的依赖造成的。
2.2 项目结构怎么摆才不容易乱
Spring Boot 对项目结构的约束非常少，但越是没约束，越容易乱。我看到很多初学者把 Controller、Service、Mapper 一股脑塞在同一个包下，项目小的时候看着还好，等过了几千行代码就开始头疼了。推荐的分层结构是清晰区别于“包名按层分”和“包名按功能分”两种模式的：
按层分包，就是常见的 controller、service、mapper、entity、dto、config，适合业务简单的 CRUD 项目，大多数人上手最快。按功能分包，比如 user、order、payment 各包下放自己专属的 Controller、Service、Mapper，适合业务复杂、模块边界清晰的中大型项目。
我个人的习惯是：如果是做给客户交付的后台管理系统，用按层分包，团队里不管是初级还是高级工程师，找文件都无脑方便；如果是做长期演进的业务中台，按功能分包能大幅减少合代码时的冲突。这个选择没有绝对对错，只要团队内部统一即可。
再补充一个被很多人忽略的小点：Application 启动类一定要放在最外层包，也就是所有业务包的父包。否则 Spring Boot 扫描不到下面的 @Service、@Component，启动后所有的接口都会 404，而控制台还看不到任何报错，这种问题排查起来特别费时间。
2.3 多模块 Maven 工程要不要上
纯业务开发初期，我没推荐大家一上来就搞 Maven 多模块。模块拆分的核心收益是“编译边界清晰、强制依赖规范”，但代价是开发、调试、启动链路变复杂，IDEA 里模块之间的引用偶尔还会出现刷新不及时的情况。
如果项目的确到了需要拆的时候，参考下面的模块划分：
text复制parent-pom
|-- api-gateway （网关/入口模块）
|-- common-core （公共工具、常量、统一返回值）
|-- system-module （系统管理相关业务）
|-- business-module （具体业务模块）
`-- scheduler-module （定时任务模块）
父 POM 里统一管理依赖版本，子模块里只声明自己用到的依赖，不要在每个子模块里重复维护版本号。IDEA 对多模块工程的支持已经很成熟，模块间跳转、重构都做得很顺手，但要注意：所有被依赖的模块要先执行 install 到本地仓库，否则跨模块引用时 IDE 可能提示找不到符号，这个细节经常坑到第一次接触多模块的人。
3. 把日常开发效率拉满
3.1 热部署配置：改完代码不用重启
Spring Boot 开发中最影响心情的事情，就是每改一次代码就重启一次项目。解决这个问题的标准方案是加 spring-boot-devtools 依赖。这个依赖做的事情是监听 classpath 下的文件变化，检测到代码改动后自动重启应用上下文。注意它跟 JRebel 这种字节码热替换方案不一样，DevTools 本质还是“自动重启”，只不过重启速度极快，体感上基本就是秒级。
在 pom.xml 中加入：
xml复制<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-devtools</artifactId>
<optional>true</optional>
</dependency>
然后记得在 application.yml 里把触发热重启的开关打开：
yaml复制spring:
devtools:
restart:
enabled: true
还有一个关键动作：IDEA 默认不会自动编译 Java 文件，所以需要开启 Build Project Automatically，或者更实用的是在 IntelliJ IDEA 中按 Ctrl+Shift+A（macOS 是 Cmd+Shift+A），搜索 Registry，勾选 compiler.automake.allow.when.app.running。如果不做这一步，你会发现改完代码项目纹丝不动，然后怀疑 DevTools 是假的。这个问题我一年内至少被同组的同事问了三次，所以单独拿出来说。
3.2 Lombok 与注解处理的配置
Lombok 在 Spring Boot 项目里几乎是标配了。它的原理是在编译期通过注解处理器自动生成 getter/setter、builder、构造器 等方法，好处是实体类代码显著缩短。IDEA 里使用 Lombok 需要装 Lombok 插件（新版 IDEA 已经内置），并且在 Settings -> Build, Execution, Deployment -> Compiler -> Annotation Processors 中勾选 Enable annotation processing。
一个具体的例子，一个用户实体加上 @Data 和 @Builder 之后：
java复制@Data
@Builder
public class User {
private Long id;
private String name;
private String email;
}
IDE 里能直接调用 User.builder().name("张三").build()，也能看到自动生成的 getName()。如果你发现代码里写 user.getName() 一直标红，第一时间去检查注解处理开关，而不是怀疑 Lombok 依赖没引对。
有团队对 Lombok 持保留态度，理由是它隐藏了实现细节、对新手不友好。这个争论我不站队，但如果公司代码规范里明确不用 Lombok，就老老实实写 Getter/Setter，别为了省几行代码破坏团队规范。
3.3 Run/Debug 配置的几个实用小技巧
IDEA 的 Spring Boot 运行配置默认就是能用，但调好了能明显提升日常开发体验。
第一个技巧是加启动参数。开发环境经常要覆盖配置文件里的值，比如临时换一个数据库连接地址，做接口调试的时候临时指定 server.port=8081。在 Run/Debug Configurations -> Spring Boot -> Program arguments 里直接填 --server.port=8081，IDEA 会作为 Spring Boot 命令行参数传进去，优先级比 application.yml 高，所以会覆盖原来的配置，用完删掉就行，不用来回改配置文件。
第二个技巧是打开 Hot Swap 之外的一个隐藏能力：在 Debug 模式下修改方法体的代码，IDEA 默认会用 JVM 的 HotSwap 机制直接替换已加载的类，不需要重启。前提是你只在方法体内部改动，如果加了字段或改了方法签名，还是需要 DevTools 辅助或者手动重启。所以推荐开发时一直用 Debug 模式跑应用，顺手还能点断点调试，改动代码的生效速度也更快。
第三个技巧是常用的 Environment variables。很多项目把数据库密码、第三方密钥放在环境变量里，比如 DB_PASSWORD，IDEA 可以在运行配置里加 EnvFile 或者直接在 Environment variables 输入框中定义，比如 DB_PASSWORD=123456;REDIS_HOST=localhost。这样团队新成员拉代码后不用去改全局系统环境变量，每个运行配置独立管理，环境隔离也更干净。
3.4 用内置 HTTP Client 调试接口，不用再切窗口
很多人调试接口习惯开着 Postman 或者 Apifox，其实 IDEA 旗舰版内置的 HTTP Client 已经非常好用。它的好处是请求脚本可以直接放在项目目录里，随代码一起提交到 Git，团队协作时接口调用方式一目了然，新人进来直接照着文件点发送就行。
在项目根目录建一个 http 文件夹，里面新建 main.http：
http复制### 获取用户列表
GET http://localhost:8080/api/users
Accept: application/json
### 创建用户
POST http://localhost:8080/api/users
Content-Type: application/json
{
"name": "张三",
"email": "zhangsan@example.com"
}
IDEA 会在文件左侧显示绿色运行箭头，点击即可发送请求，响应结果直接在下方面板里预览，还支持定义变量、生成随机数据等高级功能。社区版虽然默认不带这个功能，但也可以使用第三方 REST 插件替代。接好后，日常写 Controller 测接口完全不用再开外部工具。
4. 深入调试与线上保障
4.1 断点调试的正确姿势
IDEA 的断点调试界面其实不复杂，但很多人只学会了“在行号旁边打红点然后看变量”，效率很低。我常用的几个能力：
条件断点：在断点上右键，输入 name == null 这样的条件表达式，只有表达式为真时才会命中。比如你在一个循环里排查某个特殊数据的异常情况，这个功能能省掉大量手动跳过无关循环的时间。
日志断点：断点上右键，取消勾选 Suspend，然后在 Evaluate and log 里输入表达式。这样命中断点时不会阻塞线程，只会打印日志。这个能力特别好用，尤其是在生产问题上远程调试不方便、又不能随意加日志的场景。
Evaluate Expression（求值表达式）：线程命中断点后，按 Alt+F8（macOS 是 Option+F8）打开求值窗口，可以直接执行当前上下文任意表达式，临时调用某个方法看结果。注意这里执行的方法会真实生效，如果有副作用要自己评估清楚。
调试的核心原则是“先缩小范围，再加日志”。我见过很多同事遇到问题就打一堆断点，然后程序跑到一半就停住，变量也不知道看哪些，最后还是在代码里逐步排查。正确做法是：先根据异常栈或者错误现象定位到大概的服务类，再在关键分支入口打条件断点，确认一下参数是否符合预期，最后再一步一步往下跟。
4.2 Actuator 的正确打开方式
Spring Boot Actuator 是很多人既熟悉又陌生的组件。熟悉的是它提供了监控端点，陌生的是大多数人只会看 /actuator/health 来确认服务存活，完全没发挥出它的价值。我建议在项目中引入：
xml复制<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
然后在 application.yml 中配置端点暴露：
yaml复制management:
endpoints:
web:
exposure:
include: health,info,metrics,loggers,headdump,threaddump
endpoint:
health:
show-details: always
配置好后，/actuator/health 能返回每个子系统的健康状态，/actuator/metrics 能查询 JVM 内存和线程数据，/actuator/loggers 可以在运行时动态调整某个类的日志级别，/actuator/threaddump 能拿到线程堆栈，排查死锁问题非常好用。
关于安全，重点提醒一句：生产环境暴露 Actuator 端点时，一定要做权限控制。根据我的实践，最简单的方案是：内网部署时只开放 health 和 info 给你的监控系统，其余端点通过 Spring Security 配置成只有运维跳板机能访问；公网访问场景下，尤其不能无脑暴露 env、headdump 这些端点，端点里携带的配置信息、运行内存快照都属于敏感数据。网关层对 /actuator/** 做一次统一的 ACL 白名单放行，是最稳妥的做法。
我曾经在一个内部项目中因为调试方便，把 include: '*' 所有端点全部打开，部署到预发环境半个月之后做安全巡检，发现 env 端点能直接读到数据库连接串的明文，当时就惊出一身冷汗。从那之后我的默认习惯就是：暴露最小集合，其他的用命名 show-details: never 或者干脆不暴露。
4.3 日志配置与排查思路
Spring Boot 默认使用 Logback，日志配置文件推荐命名为 logback-spring.xml，放在 src/main/resources 下。这样可以支持 Spring Profile 的差异化配置，如果用的是 logback.xml，则无法直接用 springProfile 标签，在区分测试和线上日志级别时很不方便。
一个常见的配置示例：
xml复制<configuration>
<springProfile name="dev">
<root level="DEBUG"/>
</springProfile>
<springProfile name="prod">
<root level="INFO"/>
</springProfile>
<appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
<file>logs/app.log</file>
<rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
<fileNamePattern>logs/app.%d{yyyy-MM-dd}.log</fileNamePattern>
<maxHistory>30</maxHistory>
</rollingPolicy>
<encoder>
<pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{50} - %msg%n</pattern>
</encoder>
</appender>
<root level="INFO">
<appender-ref ref="FILE"/>
</root>
</configuration>
排查问题时的日志策略也有讲究。我在实践中总结了一套节奏：先查 ERROR 级别的日志，看有没有未捕获异常；再根据时间点定位到当时正在处理的业务方法；如果日志量太大，用 Actuator 的动态日志级别接口把指定包的日志切到 DEBUG，跑一次复现拿到栈信息后立刻调回 INFO。动态调日志级别这个功能特别适合线上临时排查，比改配置重启快得多。
5. 测试、打包与部署实践
5.1 在 IDEA 里写单元测试的体验优化
Spring Boot 项目引入测试依赖是标准动作：
xml复制<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-test</artifactId>
<scope>test</scope>
</dependency>
IDEA 对测试的支持不错，在类名上按 Cmd+Shift+T 可以直接跳转创建对应的测试类。写 Controller 层接口测试，推荐用 @WebMvcTest 配合 MockMvc，只加载 Web 层，测试速度快：
java复制@WebMvcTest(UserController.class)
class UserControllerTest {
@Autowired
private MockMvc mockMvc;
@MockBean
private UserService userService;
@Test
void shouldReturnUserList() throws Exception {
when(userService.listAll()).thenReturn(List.of(new User(1L, "张三", "zhangsan@example.com")));
mockMvc.perform(get("/api/users"))
.andExpect(status().isOk())
.andExpect(jsonPath("$[0].name").value("张三"));
}
}
这里要注意 @MockBean 会替换 Spring 上下文中的真实 Bean，如果同时存在多个同类型 Bean，还需要指定具体的名称。跑测试时 IDEA 的绿色箭头旁边能直接看单个测试的耗时，右键还能使用 Run with Coverage 查看当前测试类对哪些行代码做了覆盖，用这个功能就能直观地发现哪些分支根本没测过。
很多朋友觉得测试代码没价值而不愿写，其实从长期维护角度看，测试就是最便宜的回归保障。我自己定了一个朴素指标：核心业务类的新增代码都必须有关键路径的单测，工具类方法至少要有正常路径和异常路径的覆盖，这样后续重构时心里才能有底。
5.2 Maven 打包与多环境配置
打包 Spring Boot 项目，我在 IDEA 里习惯直接双击右侧 Maven 工具窗口里的 package 命令，IDEA 会以 Maven 方式构建项目。执行结果会在 target 目录下生成可执行的 jar。Spring Boot 插件默认打出来的是 fat jar，内部包含所有依赖，直接 java -jar 就能跑。
多环境配置的标准做法是使用 application-{profile}.yml：
text复制application.yml （公共配置）
application-dev.yml （开发环境）
application-test.yml （测试环境）
application-prod.yml （生产环境）
启动时通过命令行参数指定环境：
bash复制java -jar app.jar --spring.profiles.active=prod
IDEA 里开发时可以在运行配置的 Active profiles 一栏里填 dev，点运行就会加载 application-dev.yml。注意不同环境之间的配置差异不要维护太多遍，尽量把公共项放到主配置，每个环境文件里只保留真正不同的部分，比如数据库连接、日志级别、第三方服务的地址等。
5.3 从命令行跑 Spring Boot 的注意事项
很多时候需要脱离 IDE 在服务器上直接跑项目，建议在本地先养成用命令行启动的习惯。我用 Maven 项目时的常用命令：
bash复制mvn clean package -DskipTests
java -jar target/myapp-0.0.1-SNAPSHOT.jar
还有两个容易踩坑的点必须提醒：
第一，mvn package 时如果没有配置 finalName，生成的 jar 会包含版本号，比如 myapp-0.0.1-SNAPSHOT.jar，写脚本按文件名匹配时要留意版本号变化，建议在 pom.xml 中加一行配置让它固定：
xml复制<build>
<finalName>myapp</finalName>
</build>
第二，服务器上运行 jar 最好不要直接放前台，用 nohup 或者 systemd 托管。简单点在开发机验证可以用 nohup java -jar myapp.jar > app.log 2>&1 &，这样即使 SSH 断开进程也不会退出。当然了，生产环境还是建议用 systemd 或者容器化部署，管理起来更规范。
6. 常见问题与排查技巧实录
6.1 热部署不生效：八成是少了这个开关
DevTools 依赖加了、依赖也导入了，但改代码还是需要手动重启，多半不是依赖的问题，而是 IDEA 没有开启自动编译。按顺序检查三步：
- 打开
Settings -> Build, Execution, Deployment -> Compiler，勾选Build project automatically。 - 按
Ctrl+Shift+A打开 Register，找到compiler.automake.allow.when.app.running，勾选上。 - 运行项目时最好是 Debug 模式，这样代码改动后 IDE 会自动编译，DevTools 才能感知到 classpath 变化并触发重启。
另外，application.yml 中正确启用了 spring.devtools.restart.enabled=true 也是必要的前提。如果做完这三步还是不生效，检查依赖里是否被 optional=true 干掉了 —— optional 只是在打包时不会传递给下游，编译和运行阶段仍然是生效的，一般不至于不生效。
6.2 端口被占用，启动直接失败
Spring Boot 启动报 Port 8080 was already in use 有两种处理方式。
第一种，换端口跑。运行配置里加上 --server.port=8081，或者改配置文件。
第二种，找到占用进程并杀掉。macOS 和 Linux 可以用：
bash复制lsof -i :8080
然后根据输出的 PID 执行 kill -9 <PID>。Windows 上则是 netstat -ano | findstr 8080，再 taskkill /PID <PID> /F。
但真正值得关注的是：“为什么”端口被占用了。如果每次启动都撞端口，大概率是你之前运行的实例没有停干净。IDEA 动不动会把上个进程留在后台，特别是用 nohup 方式跑过之后，这种脏进程除了占端口，还会占数据库连接、缓存连接，导致开发环境各种资源不够用。我建议每过一两周，随手清理一下端口列表里所有 Java 进程，能省不少事。
6.3 依赖冲突的排查思路
Spring Boot 的 spring-boot-starter-parent 帮我们把大部分常用依赖的版本都协调好了，但一旦引入非官方 starter，或者第三方库内部传递依赖了不同版本，就会出现 NoSuchMethodError、ClassNotFoundException 这类诡异异常。
遇到这种情况，我先用 Maven Helper 插件分析，这是 IDEA 中极推荐的排查工具之一。安装后在 pom.xml 底部会多出 Dependency Analyzer 标签页，能直观看到冲突的 JAR 落在了哪个版本。定位到之后，在 pom.xml 中用排除的方式强制移除传递依赖：
xml复制<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-redis</artifactId>
<exclusions>
<exclusion>
<groupId>io.lettuce</groupId>
<artifactId>lettuce-core</artifactId>
</exclusion>
</exclusions>
</dependency>
没有这个插件时也可以用 mvn dependency:tree -Dverbose | grep xxx 在命令行里手动看依赖树，虽然效率低一些，但排查逻辑是一样的：找到“谁引入了旧版本”，然后把它排除掉。
6.4 控制台中文乱码
开发时发现 Console 里中文变成乱码，多半是编码不一致。IDEA 的默认视图编码、系统命令行编码、项目源码编码三方不统一就会出现这个问题。统一入口是右下角的状态栏，点一下文件编码，把项目编码和属性文件编码统一调到 UTF-8。
启动时的乱码则可能出在 JVM 参数上。IDEA 的运行配置里给 VM options 加上：
text复制-Dfile.encoding=UTF-8
这样保证进程以 UTF-8 输出，就不会再出现一二三变成 ，½ 这类乱码符号。另外 Windows 系统如果默认编码是 GBK，可以在 Settings -> Editor -> File Encodings 里明确把 IDE 编码设为 UTF-8，同时勾选 Transparent native-to-ascii conversion（针对 properties 文件）。这几个地方都对齐之后，乱码问题基本能根除。
6.5 启动慢：如何定位瓶颈
Spring Boot 启动慢的原因通常集中在几个方面：自动配置类是否能精简、Bean 初始化是否有重活、数据库连接池初始化是否等待超时。
我自己的排查方式很简单，先在 application.yml 中加入：
yaml复制logging:
level:
org.springframework.boot.autoconfigure: INFO
org.springframework.boot.web.embedded.tomcat: INFO
再启动时观察日志里每个阶段的时间点分布，看大量时间花在了数据库初始化、Redis 连接还是自定义监听器里。之前有次项目启动要 40 秒，我定位后发现是一个定时任务在启动时扫描了整个服务器磁盘目录，调整成懒加载之后启动时间缩到 12 秒。
还可以设置 spring.main.lazy-initialization=true，把非必要的 Bean 延迟到首次被调用时再创建。这功能开发环境很好用，但生产环境不推荐依赖，因为它会掩盖 Bean 初始化阶段的依赖错误，上线前还是把延迟关掉跑一遍完整的启动日志更踏实。
写在最后
我在实际使用 IntelliJ IDEA + Spring Boot 的组合时，最大的心得是：IDE 本身不会让你成为更好的程序员，但合理配置 IDE 能帮你把精力从琐碎操作中释放出来，放到真正该思考的业务逻辑和系统设计上。上面提到的很多细节，像热部署开关、注解处理、调试技巧、Actuator 端点暴露，单看任何一个都不算“高深”，但组合在一起，每天省出来的效率是实打实的。
最后再分享一个小技巧：每季度抽一个下午，把 IDEA 更新到最新稳定版，同时快速过一遍官方 Release Notes，JetBrains 每一年都在优化 Spring 相关的支持，新的功能可能正好能解决你已经习惯了很久的痛点。开发工具上的小额时间投资，回报通常比你想的要大得多。