你花十分钟用Spring Initializr生成了一个项目却花了三个月在改它的结构。这种事太常见了——依赖一堆包结构随手建配置写死在代码里异常处理看心情。从零搭建SpringBoot项目技术本身不重要真正决定项目命运的是动手前那几张“白纸”上的推演。理清下面五件事比选择Java版本、钉死SpringBoot版本更值得你花时间。边界先画业务地图再谈技术分层很多人习惯先建controller、service、mapper这三个包然后让所有业务往里塞。这不是骨架是一个没有隔间的通铺。包结构的本质是业务边界的地图而不该是技术组件的抽屉。你的订单逻辑不会因为放在service包里就变得清晰它只会因为被塞进“工具类”而逐渐腐烂。动手前请回答三个问题这个系统要管理哪几类核心对象每类对象之间是什么关系哪些动作是跨越多个领域的比如一个简单的电商后端至少应该有订单、库存、支付三个领域。让订单服务直接调用支付服务的接口比让订单服务去访问支付表要健康得多。领域之间的通信用消息或接口而不是共享数据库表。实践中不要一开始就搞微服务拆分。单体项目同样需要边界——模块、包、接口的访问权限都能体现边界。最怕的是“以后可能要拆分为理由”把所有逻辑揉在一起。边界清楚后续拆分布式不是噩梦边界模糊你连做单体都费劲。记住技术分层是惰性业务分层是勇气。依赖少即是多版本是纪律SpringBoot的Starter让添加功能变得太容易了你引用一个spring-boot-starter-web就以为拿到了全世界。实际躺进项目里的可能是你永远用不到的AutoConfiguration以及几个互相看不顺眼的传递依赖。每引入一个依赖就是引入一个敌人——它可能是版本冲突的制造者也可能是安全漏洞的潜伏点。搭项目时请执行“减法策略”。能用Servlet容器解决的就别引入WebFlux能用一个工具类解决的就别引整个Apache Commons。Starter不是勋章是成本。每一次点击“Add Dependency”之前都要问没有它我能不能活着如果只是偶尔用某个函数自己写十个也好过让项目背上几十个类。版本管理更是纪律。BOMBill of Materials是护身符但只靠它还不够。SpringBoot的parent已经管理了大多数依赖的版本可一旦你为了某个新功能直接覆盖了版本号你就离开了安全区。建议用Maven Enforcer插件强制检查依赖冲突用dependency:analyze找出无用的依赖。这些过程很烦但比上线后因为jacksong版本不一致而收到诡异的反序列化错误要舒服一万倍。配置把不变的写死把会变的放外面配置文件是最容易被低估的“代码”。很多人喜欢把数据库密码、第三方密钥、业务参数直接写在application.yml里然后项目一出问题就改配置、提交、部署循环往复。配置文件里的注释比代码注释更能骗人——因为没人会去检查注释说的是不是真的。从零开始默认就要支持多环境。application-dev.yml、application-prod.yml或者干脆把配置放进环境变量和配置中心。凡是部署环境不同的值一律不许出现在默认配置里。数据库连接串、端口、日志级别、超时时间都算“会变的”。反而是一些业务阈值比如订单过期时间虽然可能变但应该有一个明确的默认值写在代码常量中而不是散落在配置里找不到。真正深层的问题在于“配置漂移”开发环境跑得好好的测试环境就炸最后发现是配置不一样。解决的思路不是建一个巨大的统一配置文件而是用占位符和Profile强制区分。启动时校验关键配置项是否存在任何缺失都直接报错而不是用空值继续运行。你要做到换一套配置代码一行不改环境立刻可靠。这一点比任何“微服务优雅”都有价值。异常与返回先定义“错误长什么样”再写业务代码接口设计的玄学不在返回值能装多少数据而在异常时你能给调用方多少确定性。很多项目成功时返回{code:200, data:xxx}失败时却抛出一个堆栈信息或者返回乱七八糟的字段。接口正常时回答千篇一律异常时千姿百态——这是设计失败的典型信号。搭项目的第一天就要约定统一的返回体code、message、data。但不要死板地所有接口都包一层比如文件下载、流式接口可以直接用原始响应。统一是给“业务错误”一个家不是给“HTTP状态码”做婚纱。业务异常要用自定义异常类表达系统异常由全局异常处理器兜底二者对应不同的日志级别。错误码是另一个学问。报“操作失败”等于没报。每个错误码要能定位到具体的业务规则或参数但也不要细到每个字段一个码。比较合理的粒度是模块码 业务码比如订单模块用ORDER_, 库存不足就是ORDER_STOCK_NOT_ENOUGH。把这些码集中在一个常量类或枚举中而不是散落在各个方法的魔法数字里。你还要考虑异常被全局捕获后日志里是否有traceId调用方拿到的message是否可读。这一套规则在写第一个接口之前就要定死否则后边每个人都会发明一套自己的“临时方案”。可观测性日志、指标、链路——从第一行代码就埋好没有哪次线上事故是“新鲜”的区别只在于你能不能迅速定位。SpringBoot项目启动时logback的默认格式够用但不够好。没有上下文信息的日志就是废纸。线程号、时间、类名这些默认项之外你必须加上请求的唯一标识——requestId或traceId。用一个过滤器为每个请求生成ID放进MDC之后所有日志都会带上这个ID。这样一次请求的链路就能从入口到SQL拧成一条线。Actuator不是可选项。/health、/metrics、/info等端点从第一天就暴露给监控系统。不要等到运维来问你要端口时才想起没配。指标是项目的体温计没有体温计的病人只能靠摸额头。用 Micrometer 记录核心操作的耗时、成功/失败计数哪怕只是简单记录下来也比事后猜要强。如果是分布式系统链路追踪工具比如 SleuthZipkin必须在第一批依赖里。纠结“现在系统小用不上”的人等系统大了之后再想添加链路成本会高到让你想重写。可观测性不是功能是基础设施。从第一个接口能跑通的时候就要验证日志能否打开为什么慢错误发生在哪个服务做不到这三点你的项目还只是个演示程序。收尾这五件事是骨架代码只是血肉回到最初那个Initializr页面。你可能会觉得加几个依赖、调一下配置格式这些事都不算“开发”。但正是这些不起眼的决定决定了你未来每个迭代是顺畅还是挣扎。业务边界定得越清楚往后的重构越有底气依赖管得越严升级版本时越敢睡觉配置隔离越彻底环境迁移时越不用跪着求人异常合同越早统一联调时越不会互相质问可观测性建得越早线上事故处理时越能谈笑风生。从零搭建项目不是一个技术动作而是一组承诺。承诺在没人看见的地方守秩序承诺不为图省事而引入糊涂账。你愿意在第一天多花一小时思考这些后面的每一个深夜都会少一个“为什么跑不起来”的哀嚎。动手吧但请先让上面五件事在你脑子里投影出清晰的答案。