先说一段让人破防的经历
我手上有一个2017年用Spring Boot 1.5写的订单系统，当时上线时并发也就几百，没人觉得慢。到了2021年，业务方要求把接口响应时间P99压到500ms以内。我们堆机器、加缓存、调JVM，折腾了三个月，最后勉强到了600ms。后来隔壁用Go写的日志采集服务，一台2核4G的机器轻轻松松扛住了每秒两千个请求，日志照样写。当时很多人跟我说：看吧，当初选Go就没这事了。
但真相是什么？真相是那个Spring Boot系统慢，问题根本不在框架，而在于我们用了大量Hibernate的级联操作，还有一堆没做索引的关联查询。框架本身只占响应时间的百分之十几，数据库和代码质量才是大头。可当时谁听得进去？大家只记得“Java笨重，Go轻快”。
后来我花了半年时间，把那些垃圾查询改掉了，没换框架，P99直接降到280ms。这件事让我意识到：框架的“快”和“慢”，在真实业务里往往是个伪命题。 如果代码写得烂，用什么框架都一样卡成ppt。
真正拉开差距的五个维度
网上对比框架的文章，翻来覆去就是撸一段HelloWorld，然后跑几个并发请求，给出一张吞吐量对比图。这种对比毫无意义——你的业务会只做加法运算吗？你会把数据库连接池关掉吗？所以我只谈那些在长期维护中才会暴露出来的差异：
第一，团队排错效率。 Spring Boot的报错信息虽然长，但是堆栈追踪非常完整，出了问题，基本能从日志里一路追到SQL语句。Go的panic有时候会让你面对一长串goroutine栈，但如果你没写过pprof，排查内存泄漏能让你怀疑人生。我见过不少Go项目，线上OOM了，大家第一反应是“重启一下”，没有人知道heap profile怎么分析。框架本身没有绝对的优劣，关键是你的团队有没有能力驾驭它的调试工具。
第二，依赖管理的稳定性。 很多文章吹Go的依赖管理简洁，没有像Maven那样一大堆传递依赖。但实际维护过Spring Boot的人都知道，Maven虽然依赖树复杂，但你可以用dependencyManagement去锁定版本，加上maven-enforcer-plugin就能避免依赖冲突。Go的module看起来干净，可一旦某个间接依赖升级了一个不向下兼容的版本，那个报错会让你去翻GitHub的issue。我曾经帮人排查过一个Go项目，仅仅因为一个日志库的小版本更新，就导致整个服务的JSON序列化字段顺序全乱了。这种问题在Spring Boot里，基本不会发生。
第三，生态的“最后一公里”。 Spring Boot的坑，百分之九十都能在Stack Overflow上找到答案。你遇到什么问题，只要把异常类名贴到搜索框，就会出现一堆有人踩过的帖子。Go的生态虽然发展很快，但有些小众库就是你一个人在战斗。比如你想在Go里用分布式事务框架，翻来覆去就那几个，要么社区不活跃，要么业务覆盖不全。不是说Go不行，而是很多业务场景的解决方案还在“用起来不够爽”的阶段。
第四，运维习惯的兼容性。 如果你所在的公司运维体系是围绕Java构建的——比如有完善的Arthas调试环境、有稳定的JVM监控大盘、有现成的线程池规范——那就不太建议硬切换到Go。因为Go的metrics虽然丰富，但你要重新建设监控告警、日志采集、链路追踪这一整套东西。我统计过，在一次技术栈迁移中，光是打通基础设施和监控看板就花了团队40%的精力。这笔账很多人前期没算进去。
第五，业务变更的响应速度。 这个可能跟大众认知相反，但我自己的体会是：如果项目是典型的CRUD加审批流、加定时任务、加消息队列，Spring Boot的开发效率真的高过Go很多。别的不说，就一个spring-boot-starter-data-jpa，加上@Transactional注解，事务处理就完事了。在Go里，你得自己手写事务管理，要处理好上下文超时、要手动回滚，代码量至少多出一倍。业务需求经常变的时候，代码量越大，改起来越容易出错。所以我会说：如果你的系统充满了增删改查，没有高并发和高性能计算的硬指标，Spring Boot反而比Go更适合。
我为什么不劝人“放弃Spring Boot”
现在很多人一提起Go就说“高性能”、“云原生”，一提起Java就说是“老古董”。但实际上，大部分公司的业务形态根本到不了需要Go来发挥极致性能的地步。我的一个客户公司，他们的用户量号称一百万，实际日活不到十万，订单接口平均响应时间在200ms左右，但他们非要因为某次分享会听到了“Go支持百万并发”就全面迁移。结果呢？两个后端工程师整整写了三个月，出来的代码连原来Spring Boot稳定版本的一半功能都没有覆盖。
除非你是做基础中间件、高吞吐网关、或者对内存占用极其敏感的服务，否则Spring Boot的自动配置、成熟的生态、以及庞大的人才市场，能让你在招聘、排障、迭代上省掉很多不必要的麻烦。Java的GC经过这么多年的版本迭代，G1和ZGC在低延迟场景上已经没比Go的runtime差到哪去。正如一个在Java界创业的老朋友所说：“如果你因为性能换掉Java，那说明你还没有认真优化过你的系统。”
如果你是做技术选型，到底该怎么判断？
我总结出了一套傻瓜化判断法，不基于任何信仰，只基于现实：
- 如果你的核心诉求是快速搭建业务原型，或者你的系统是交易、订单、权限这类事务性很强的CRUD，且你的团队最熟悉Java——请安心用Spring Boot。不要被“Go更现代”这种话术带偏。
- 如果你的项目需要处理大量并发连接，比如IM网关、消息推送、流式日志，或者你确实有性能指标测试报告证明Java无法在同样资源下满足需求——那选Go。但请在选型前就把监控链路和pprof分析流程搭好，而不是等出了内存泄露再临时抱佛脚。
- 如果你的业务是复杂算法或者计算密集型，那Java和Go都不一定是最优选，也许C++或Rust更合适。但如果你为了隐藏自己的代码水平而选一个“偏门”语言，那最终只会害了团队。
我现在依然维护着Spring Boot的老项目，只是我更明白了它的边界在哪里。开发效率、故障恢复速度、生态完整度，这些才是后端框架长期价值的关键维度。框架就像伴侣，没有绝对最好的，只有在你当前场景中最合适的那个。不如先把自己手头的复杂业务处理好，而不是每到互联网大会开完，就想着推翻重来。