前几天后台收到一条很典型的私信课设题目是《基于 Spring Boot 的大学生就业推荐系统》代码是从某个开源社区下载的 Spring Boot MyBatis 多商户跨境电商源码结果第一次跑就撞上 8080 端口冲突改完端口又报数据源初始化失败折腾到凌晨两点还是没弄明白。这种经历我太熟悉了几乎每年都有人卡在同一个地方。Spring Boot 之所以能成为现在 Java 后端的绝对主流不是因为它是新玩具而是因为它在 Spring 那套复杂生态上做了一层非常聪明的包装把过去搭一个 Web 项目要花半天时间的配置工作压缩到几分钟。这篇文章我打算换一个讲法不按官网文档的顺序罗列概念而是按一个真实项目从零推进的流程来拆环境怎么准备、版本怎么选、数据库怎么集成、面向第三方的 API 怎么设计、上线前监控做到什么程度最后再附上一串我亲自踩过的坑。不管你是做课设的学生还是刚从其他语言转后端的老手应该都能找到可以直接抄走的部分。1. Spring Boot 到底是干嘛的先解决为什么火这个根本问题1.1 从配置地狱说起没有 Boot 之前的日子我在 2013 年前后开始用 Spring 3 搭项目那时候建一个 Web 工程不是写代码的问题是配置的问题。你需要手工维护 web.xml、spring-mvc.xml、applicationContext.xml、jdbc.properties还要操心 Spring、MyBatis、Jackson、Druid 这些框架之间的版本兼容性稍有不匹配启动时就会喷出一屏 NoSuchMethodError 或者 ClassNotFoundException。新人入职第一周往往全耗在环境搭建上真正写业务代码的时间少得可怜。更要命的是每次部署都是把 WAR 包丢进外置 Tomcat本地能跑不代表服务器能跑端口、字符集、日志配置全都要在容器层面再排一遍。Spring Boot 的核心价值我总结下来就三件事。第一spring-boot-starter-* 这种依赖把一组常用库的版本锁死你不用再纠结 spring-webmvc 5.x 配 Jackson 2.x 会不会打架第二自动配置机制根据 classpath 上的类自动创建 Bean你只要约定好配置项剩下的由框架推断第三Tomcat 内嵌进应用mvn spring-boot:run 或者 java -jar 就能启动开发环境和生产环境的边界一下子清晰了很多。1.2 约定优于配置Boot 到底替你做了哪些决定所谓约定优于配置不是没有配置而是把配置的默认值摆在了明面上。我常拿租房做类比老 Spring 是租一间毛坯房水电气、家具、网络全部你自己接Spring Boot 是精装房床、桌子、路由器都给你摆好了你要做的只是按需调整比如把床挪个位置、加一盏台灯。具体到代码层面SpringBootApplication 这个注解实际上是三个注解的组合SpringBootConfiguration 负责标记配置类EnableAutoConfiguration 触发自动配置机制ComponentScan 自动扫描主类所在包及以下的所有组件。自动配置的背后是 spring-boot-autoconfigure 里一堆 ConditionalOnClass、ConditionalOnMissingBean、ConditionalOnProperty 这类条件注解框架扫描 classpath 之后按条件决定哪些配置生效。比如你在 classpath 里引入了 HikariCP配置里又写了 spring.datasource.url它就知道你想连数据库自动帮你创建 DataSource 和 JdbcTemplate没写配置它就跳过。这也是为什么很多初学者刚接触 Boot 时觉得什么也没配就能跑——框架替你做完了大部分常规决定你只有用到非常规场景时才需要动手覆盖默认值。1.3 第一个 Hello World以及最常被问的端口号新建工程最快的方式是打开 start.spring.io选好 Maven、Java 版本依赖勾选 Spring Web生成后解压导入。最简启动类和接口长这样SpringBootApplication public class DemoApplication { public static void main(String[] args) { SpringApplication.run(DemoApplication.class, args); } }RestController RequestMapping(/api) public class HelloController { GetMapping(/hello) public MapString, String hello() { return Map.of(message, hello spring boot); } }启动后访问 http://localhost:8080/api/hello就能看到返回的 JSON。这里默认端口 8080 就是约定但每个人都会遇到要改端口的时刻。最直接的做法是在 application.yml 里写server: port: 8081如果你是下载的开源 demo经常还会看到别人在启动配置里加--server.port8081临时覆盖或者在 application-dev.yml 里按环境拆分。端口修改看着简单实际上背后有一套完整的配置优先级规则很多人改了没生效就栽在这上面这个我在第 6 章专门展开。2. 从零搭项目IDE 怎么选、版本怎么定2.1 IntelliJ IDEA 社区版与 VS Code 的真实使用感受提问IntelliJ IDEA 社区版怎么用 Spring Boot的人非常多这里先说结论社区版完全可以用只是有些便利功能需要自己绕路。社区版免费但确实少了 Ultimate 版里的 Spring Assistant、端点跳转、Bean 依赖图这类贴心工具。可 Spring Boot 本身就是一堆约定你用社区版跑通项目没有任何问题去 start.spring.io 生成工程然后在 IDEA 里 File Open 选择 Maven 项目等依赖下载完直接运行带 main 方法的类就行。调试、断点、Maven 生命周期这些基础能力社区版全都有我做课设和中小型内部项目时用社区版并没有觉得被明显拖慢。用 VS Code 也不是不行装齐 Java Extension Pack 和 Spring Boot Extension Pack 之后左侧会出现 Spring 面板可以直接通过 Spring Initializr 创建项目。我实测下来写写 Controller、Service 这种中小工程足够顺手启动、调试也都能跑通。但真到了多模块 Maven 项目、几十个占位符配置、profile 来回切换的时候VS Code 的 Java 支持还是没有 IntelliJ 顺手尤其是跨模块重构和大批量接口跳转。对比项IDEA 社区版VS CodeIDEA Ultimate成本免费免费付费创建 Spring 项目借助 start.spring.io 或 Maven archetypeSpring Boot Extension Pack内置 Spring InitializrBean 跳转/依赖图无无有多模块 Maven 体验中等一般强我的个人建议是能申请到 Ultimate 的企业版就尽量用年度订阅也算开发工具的合理成本个人学习和做课设社区版完全够不必因为工具再卡一道VS Code 更适合你平时还要写前端和 Python希望在同一个编辑器里解决问题的场景。2.2 2.3.x、2.6.x 与 Spring Boot 3.x版本差异别只看数字网上搜 Spring Boot 资料最常见的关键词就是 2.3.x、2.6.x 和 3.x。这几个版本之间的差异不是简单的数字递增它们直接影响你能用的 API、依赖命名空间和配置写法选不对第三方的包就会在编译或启动时报出各种看不懂的错误。版本线最低 JDK依赖命名空间典型场景升级注意点2.3.xJDK 8javax.*老项目、教材、课设官方已停止维护别用于新项目2.6.xJDK 8javax.*Java 8 环境下的生产项目默认禁止循环依赖、默认使用 PathPattern3.xJDK 17jakarta.*新项目、云原生javax 全部改名 jakartaSpringfox 不可用Spring Boot 3.0 是一次大跨度升级底层换成了 Spring Framework 6原来的 javax.servlet 全部改名为 jakarta.servlet。这意味着所有依赖 javax 前缀的老第三方库像很多旧版 springfox-swagger、老版本 druid都会在启动或编译期报错。我见过不少同学简历上写熟练使用 Spring Boot 3一到面试现场被问到 JDK 版本和 jakarta 迁移就露馅。最基础的一条规则就是Java 8 用不了 Spring Boot 3必须 JDK 17 及以上。2.6 这个版本被频繁讨论也是有原因的。它引入了两个让老项目集体炸锅的默认行为变化一是默认禁止循环依赖很多曾经设计松散的 Service 互相注入对方升级后应用直接启动失败二是默认使用 PathPatternParser部分带 ant 风格的路径匹配规则需要调整。这两个坑我后面会细讲这里先给大家一个选型结论新项目直接上当前还在维护的 3.x 小版本旧项目卡在 Java 8 又不想大动就盯紧 2.6/2.7 这一线别盲目往上升。判断标准永远是 JDK 版本和第三方依赖的兼容性不是越新越好。2.3 MyBatis 还是 JPA商城类项目的选择逻辑打开中文技术社区搜 Spring Boot 配 MyBatis 的源码十个里有八个是商城、电商、订单管理系统。这不是巧合是选择的结果。MyBatis 的核心优势在于 SQL 完全由你掌控多表联查、复杂统计、批量更新都直来直往而 JPA/Hibernate 的实体映射在多对多、嵌套关联上容易把查询变成性能黑洞调试时看 Hibernate 自动生成的 SQL又长又难定位问题。商城的订单、库存、对账场景恰恰对 SQL 的可控性要求最高所以我做这类项目一直偏向 MyBatis。当然这也不是说 JPA 一无是处。简单的 CRUD 场景、团队里都是 ORM 思维、业务实体关系清晰稳定JPA 的开发效率确实更高。我的选型逻辑是以复杂查询和报表为核心选 MyBatis以实体管理和简单增删改为主体用 JPA两者都有需求时用 MyBatis-Plus它把单表 CRUD 包掉了复杂 SQL 还是走 XML兼顾效率和可控性。顺手说一句像大学生就业推荐系统这类课设题目里带着系统两个字业务规模其实很小重点是把推荐逻辑和数据关系讲清楚MyBatis 或 MyBatis-Plus 是更稳的选择不要一上来就上微服务和消息队列那是给自己挖坑。3. 一个真实项目的骨架多商户跨境商城的模块拆解3.1 业务边界先想清楚模块、表和租户隔离说回最典型的热搜场景Spring Boot MyBatis 的多商户跨境商城。这种项目和单商户电商最大的区别在于所有数据都背着一个 merchant_id商户标识这就是最简单的租户隔离。在开发初期你不需要把每个商户拆成独立数据库只要在订单、商品、结算这些核心表的查询上统一按商户纬度过滤就行。等某个大商户的数据量和访问量明显超出平均水平时再考虑分库分表那是后话。通用模块大致是这些用户与商户入驻merchant 信息、审核、结算配置、商品中心类目、品牌、SPU/SKU、上下架、交易核心购物车、订单、支付、售后、促销营销优惠券、秒杀、满减、消息通知站内信、短信、邮件。跨境商城比普通商城又要多出货币字段、汇率、关税、海关编码、多语言文案这些维度建表阶段就要预留否则后面前端页面和结算逻辑都要跟着返工。我见过很多课设代码的问题不是功能太少而是把系统管理、推荐、用户、权限全塞到一个 Controller 里几千行代码平铺。分层这件事在 Boot 里不需要额外框架只要按 controller - service - mapper - DTO/VO 划包就足够清晰。到了大型项目再用 Maven 多模块把接口层、业务层、持久层拆开本质也是从这个划包结构演化过去的。先保证源发包结构正确再谈微服务。3.2 MyBatis 集成时的配置细节与动态 SQL 示例引入 MyBatis 时mybatis-spring-boot-starter 的版本号要跟着 Boot 主线走Boot 2 用 2.3.xBoot 3 用 3.0.x。如果你用 MyBatis-Plus同样有对应两个版本线别拿 Boot 3 的工程硬套 Boot 2 的 starter这是最常见的一种启动报错来源。配置示例spring: datasource: url: jdbc:mysql://localhost:3306/mall?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: your_password driver-class-name: com.mysql.cj.jdbc.Driver mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.example.mall.entity configuration: map-underscore-to-camel-case: true这里map-underscore-to-camel-case建议直接打开它能自动把数据库的 create_time 映射成实体的 createTime省下大量写 resultMap 的时间前提是实体字段命名规范。动态 SQL 是 MyBatis 的核心能力以多商户订单列表为例select idlistMerchantOrders resultTypecom.example.mall.dto.OrderVO SELECT o.order_no, o.amount, o.status, m.merchant_name FROM t_order o LEFT JOIN t_merchant m ON o.merchant_id m.id where if testmerchantId ! null AND o.merchant_id #{merchantId} /if if teststatus ! null AND o.status #{status} /if /where ORDER BY o.create_time DESC /selectwhere加if的组合避免了你用字符串拼接 SQL 的危险。这里特别提醒一句XML 里 resultType 最好写 DTO/VO 的全限定名而不要写实体类。如果列名和字段对不上MyBatis 不会报错只会静默返回 null排查起来非常隐蔽我踩过不止一次。分页方面我习惯用 MyBatis-Plus 的 PaginationInnerInterceptor 或 PageHelper选一个固定下来不要在同一项目里混用两套分页插件那是启动报错和 SQL 数量异常的根源之一。另外如果启动后报 Invalid bound statement (not found)优先检查三件事Mapper 接口类有没有加 MapperScan、XML 的 namespace 是否对应接口全限定名、mapper-locations 路径是否匹配。3.3 给第三方的 API 到底放哪先看业务阶段再谈架构有一个搜索问题很有意思Spring Boot 对外提供的接口给第三方应该放在哪里是单独的服务还是放在对应的业务服务里这个问题没有标准答案但你要先想清楚一件事所谓单独服务本质是想隔离什么如果只是想隔离认证逻辑和访问频率单独服务并不会帮你挡住数据库风险因为第三方仍然可以调用你内网的其他接口。我的建议是分阶段处理。项目初期、调用方不多、合作模式还没完全定下来时老老实实在同一个 Spring Boot 应用里划一个 openapi 模块统一用 /open/v1/ 前缀在过滤器或拦截器里统一做鉴权验签。这个阶段单独拆服务就是给自己添麻烦多一层网络调用多维护一套部署和日志。等第三方调用量上来或者你的业务服务本身要频繁迭代发版而第三方接口要求高稳定性时再把它拆成独立服务。拆的时候也不是只把一个 Controller 搬出去验签、限流、幂等、接口文档、访问审计这些配套能力要一起带走网关层可以接 Spring Cloud Gateway对外统一入口内部再路由。关于验签我提一个最基本的第三方接口鉴权流程也是我推荐业务项目优先实现的安全底线调用方先申请 appId 和 appSecret请求参数按 key 升序拼接加上 timestamp 和 nonce用 HMAC-SHA256 以 appSecret 为密钥生成 sign服务端在拦截器里重算比对同时校验 timestamp 是否在 5 分钟时间窗口内nonce 是否已被使用过。这套逻辑写成一个 OncePerRequestFilter 就能落地几十行代码成熟可靠。4. 上线前必须做的事监控、日志、故障预警4.1 十分钟接入 Spring Boot Admin讲完业务开发轮到很多人容易忽略的监控。如果你只有一两个 Spring Boot 应用先别急着上整套 Prometheus 全家桶Spring Boot Admin 可能是性价比最高的起点。它是一个管理界面一个服务端加若干客户端客户端启动后把自己注册到服务端网页里就能看到应用列表、健康状态、JVM 内存曲线、线程状态、日志文件甚至在线抓取 heapdump。服务端工程只需要两个东西dependency groupIdde.codecentric/groupId artifactIdspring-boot-admin-starter-server/artifactId /dependencyEnableAdminServer SpringBootApplication public class AdminServerApplication { public static void main(String[] args) { SpringApplication.run(AdminServerApplication.class, args); } }客户端那边加依赖并配置服务端地址spring: boot: admin: client: url: http://localhost:9000 management: endpoints: web: exposure: include: *客户端暴露的所有 Actuator 端点都会被 Admin Server 采集展示。这个方案适合团队规模小、需要人肉快速定位问题的场景十分钟接入立刻就能看到应用的健康脉搏。4.2 用 Actuator 梳理监控需求不是端点越多越好Spring Boot Actuator 是监控的基础设施它把应用内部状态暴露成 HTTP 端点。健康检查看 /actuator/health基本信息看 /actuator/info内存线程看 /actuator/metrics配置信息看 /actuator/env运行时调整日志级别看 /actuator/loggers。很多人配置 exposure.include: * 图省事这在调试阶段没问题生产环境尽量只暴露必要的端点并把 /actuator 路径放在内网或加上鉴权。Spring Boot 实现监控都有哪些需求和功能这类提问本质是在问监控到底监控什么我的理解是分四层。第一层可用性进程在不在、数据库连不连得上、磁盘有没有满第二层性能接口响应时间、吞吐量、JVM 内存、GC 频率第三层业务下单量、支付回调延迟、商户入驻数第四层安全审计登录失败次数、API 鉴权失败次数。Actuator 把前两层的基础数据全部提供给你了第三层和第四层需要用 Micrometer 自定义指标比如下单一进来就计数RestController RequestMapping(/api/orders) public class OrderController { private final MeterRegistry meterRegistry; public OrderController(MeterRegistry meterRegistry) { this.meterRegistry meterRegistry; } PostMapping public OrderVO create(RequestBody Valid CreateOrderRequest request) { meterRegistry.counter(mall.order.create.total).increment(); // 订单创建逻辑 } }这行计数打进 Micrometer 之后Prometheus 和 Grafana 都能直接采集展示业务指标和基础指标就统一在一个体系里了。4.3 一份可以直接用的监控指标清单我给自己带的项目整理了一份最小监控清单按这个标准盯大多数故障都能在用户感知之前被发现关注点指标来源建议阈值 / 动作进程存活/actuator/health连续 3 次不健康即告警堆内存jvm.memory.used使用率连续 5 分钟超 80%排查泄漏或扩容GC 停顿jvm.gc.pause单次 pause 超过 1 秒告警接口错误率http.server.requests超过 1% 进入排查接口性能http.server.requestsp95 超过 2 秒告警数据库连接池hikaricp.connections.active活跃连接长期超过池 50%优先查慢 SQL磁盘空间diskSpace使用率超过 85% 告警接入做法也很成熟引入 micrometer-registry-prometheus 依赖/actuator/prometheus 端点就会输出 Prometheus 文本格式Prometheus 定时抓取Grafana 出图Alertmanager 负责告警。这套体系和 Spring Boot Admin 不冲突Admin 适合人肉查看和中小团队快速定位Prometheus 体系适合真正意义上的 7x24 自动告警。小团队可以先用 Admin等应用数量增加之后再平滑上全套。5. 等等Python FastAPI 不香吗两种后端的真实对比5.1 同一套接口用两边实现的实际差距近两年后端 Spring Boot 3 和 Python FastAPI成了高频对比话题我两边的生产项目都做过说点真实感受。先看一个最小的创建用户接口。Spring Boot 3 需要一个 Controller 加一个 record DTO 加校验注解public record CreateUserRequest( NotBlank String username, NotBlank Email String email) { } RestController public class UserController { PostMapping(/users) public UserVO create(Valid RequestBody CreateUserRequest req) { // 业务逻辑 } }FastAPI 这边是一个装饰器函数加一个 Pydantic 模型from pydantic import BaseModel, EmailStr class CreateUserRequest(BaseModel): username: str email: EmailStr app.post(/users) def create_user(req: CreateUserRequest): ...写起来 FastAPI 确实更轻启动也快开发体验很顺滑。但那是表皮。Java 的编译期错误检查和 Spring 的生态力量体现在你项目到了十万行代码以后从一个 DTO 改名编译期就能把引用它的二十个地方全部揪出来而 Python 的类型注解基本只在编辑器层面给提示运行时靠 Pydantic 校验真正的逻辑错误大多要靠测试阶段暴露。性能方面Boot 启动慢、JVM 内存占用高是事实但稳定运行后的处理能力并不差FastAPI 配合 Uvicorn 高并发也很能打只是 Python 的 GIL 让纯计算密集型任务很难靠加线程解决。做推荐、做 AI 推理时用 Python 合理做订单、结算这类对事务一致性要求高的核心链路Java 的成熟度确实更让人放心。5.2 生态、团队、运维是真正的分水岭选型到最后拼的不是语法甜不甜而是生态和团队。Spring Security、Spring Batch、Spring Data、Spring Cloud Gateway 这些组件把权限、批处理、数据访问、网关全部包装好了一个团队里大家用的是同一套姿势招聘也容易新人上手有大量现成资料。FastAPI 的优势是学习和迭代成本低自带 OpenAPI 文档和 AI/ML 组协作时不用额外做协议转换几个文件就能把一个模型服务暴露成接口。运维层面的差异更明显。Spring Boot 应用一个可执行 jar 包跑起来JVM 参数、线程池、连接池全部有成熟约定运维修起来省心Python 部署要自己选进程管理方式Gunicorn 和 Uvicorn 的 worker 数、内存占用都要拿捏。不是说不可以做而是团队里每多一个技术栈就多一整套维护成本。我见过有些小团队图快全用 FastAPI 写交易系统后面遇到线上问题Python 的错误栈和 Java 的排查工具链完全是两种体验。5.3 我的选型思路核心业务与外围服务的分工我现在带的项目里两类技术都在用核心交易和商户域走 Spring Boot 3推荐算法和内容审核走 FastAPI 独立服务两者通过内部 HTTP 接口通信各管各的生命周期。复盘来看如果当时全部用 FastAPI 写交易链路我估计会在幂等、事务、审计这些地方焦头烂额如果全部用 Spring Boot 写推荐服务光是模型加载和在线推理的性能调优就够头痛。所以我的建议不是二选一而是看你的服务边界。对外业务接口、资金相关、复杂状态机优先 Spring Boot算法推理、数据处理、原型验证FastAPI 那种快速迭代的感觉无可替代。两者之间用标准的 REST 或消息队列衔接互不影响这是大型系统里非常常见的混合架构。6. 踩坑实录最容易翻车的几个细节6.1 明明改了端口还是 8080配置优先级排查全链路端口问题看着小实际上背后是 Spring Boot 完整的配置覆盖规则。有人说我在 application.yml 里写了 server.port8081启动还是 8080为什么应该按这个顺序排查启动命令行java -jar app.jar --server.port9090命令行参数的优先级是最高的。IDE 运行配置里的 Program arguments 或 VM options--server.port9090或-Dserver.port9090都会覆盖文件里的配置。操作系统环境变量名为 SERVER_PORT 的环境变量也会参与覆盖。application-{profile}.properties/ymlapplication-dev.yml 里的配置会覆盖 application.yml。最后才是 application.yml 里写的 server.port。我遇到过最典型的一次是同事在 IDEA 的 Run Configuration 里残留下了一个-Dserver.port8888的 VM option他自己完全不记得每次启动都跑到 8888反过来怪配置文件有问题。排查这类问题别只盯着 yml 看把启动日志最前面的 Tomcat started on port 和前几行配置来源提示打开一眼就能定位。另外一个常见原因是打包形态。如果你把应用打成了 WAR 部署到外置 TomcatSpring Boot 的 server.port 根本不会生效端口由外置容器的 server.xml 决定。很多下载的 demo 本地跑没问题一扔到云服务器就端口不对多半就是这个原因。6.2 Spring Boot 2.6 后循环依赖默认禁止升版本的必修课升级到 2.6 之后最常见的启动失败就是报 The dependencies of some of the beans in the application context form a cycle。这是 Boot 把循环依赖从默认允许改成了默认禁止。过去很多老项目写 Service 时习惯直接在字段上Autowired注入另一个 Service你注入我、我也注入你以前能跑这个版本一启动直接崩。一开始大家的第一反应是找配置项把检查关掉确实有spring.main.allow-circular-references这个开关能救急但长期看这是纵容坏味道。更推荐的做法是构造函数注入配合逻辑拆分。我处理过一个下单链路OrderService 依赖 InventoryServiceInventoryService 又反过来依赖 OrderService 去查订单拆开看其实就是库存扣减里不应该查订单表把那段逻辑抽到独立的 OrderQueryService 之后依赖关系立刻干净了连带着事务边界也清晰了。临时能救火的方案是在某个注入点上加 Lazy 打断初始化顺序但 Lazy 只是把问题延后上线后的隐性问题会更多。6.3 下载的开源商城跑不起来按这套顺序排查回到开头那位同学的场景下载的 Spring Boot MyBatis 多商户跨境商城源码跑不起来。我给你的建议是按顺序排查不要一上来就怀疑代码有 bug。先匹配 JDK 和 Maven 版本。Boot 3 工程用 JDK 17Boot 2 工程用 JDK 8/11pom.xml 里 spring-boot-starter-parent 的版本决定一切别拿 JDK 8 去跑 Boot 3。再确认依赖能正常下载。国内网络环境建议配置 Maven 阿里云镜像很多启动没反应其实是卡在依赖下载上盯着 IDEA 的转圈图标看不出任何有效信息要看 Maven 本地仓库目录和代理日志。检查数据库和 Redis 起没起。商城类源码几乎必配 MySQL 加 Redis先执行项目里的 sql 初始化脚本再核对 application.yml 里的数据库密码。报 Failed to configure a DataSource十有八九就是这里出了问题。处理端口冲突。8080 被占用是最常见的启动失败原因按第 6.1 节的优先级顺序改端口。确认是否需要切换 profile。有些源码默认启用生产配置需要注册中心、OSS、短信服务等外部依赖你本地没有就得找到 application-dev.yml 并切换激活。最后补一条最容易被忽略的Lombok。不少源码用 Lombok 生成 getter/setterIDEA 里没装插件或者 Maven 没引入注解处理器编译看着像成功了一运行就报 symbol not found这个坑虽然基础我见过太多人卡一整晚。装一下 Lombok 插件在 IDEA 设置里确认 Annotation Processing 是开启状态项目基本就能跑起来了。带团队这些年我对 Spring Boot 最深的感觉是它把上手的门槛压得很低但门槛低的代价是默认知识特别多。你以为你在学语法其实你一直在和版本、配置、工具链打交道。所以这篇文章我不想写成那种一分钟跑通的教程而是希望你把环境、选型、监控、对比这些容易漏掉的维度补上。真遇到问题记得按配置优先级的顺序去排查而不是对着代码干瞪眼。我自己也是靠这条经验救过不少发布会前的夜晚。