升级又翻车之后，我把 Release Notes 分成了三级

先说一次翻车。Spring Boot 2.x 升 3.x，我扫了一眼 Release Notes，觉得没什么大变更，直接升。然后整个工程编译炸红——javax.* 全线变 jakarta.*，凡是碰过 Servlet API、校验注解、持久化注解的地方一个都跑不掉。那天下午我干了件事：全局替换包名，改到晚上。

其实这次事故完全可以避免。不是靠"认真读完几百条 Release Notes"——没人做得到——而是靠一个更省力的习惯：把变更按风险分级，注意力按级别分配。

S 级：不兼容变更，逐条对照自己的代码

Breaking Changes、废弃 API、行为变更、配置项更名。这类变更的处理方式不是"看一遍"，是检索式的：拿到废弃的类名、方法名，在工程里全局搜索。搜不到就跟你无关；搜到了，它就是你这次升级清单的第一优先级。

上面那次 jakarta 迁移，本质就是一条 S 级变更没做检索。同类还有 JDK 升级里的 removed API、依赖库大版本的配置项更名，全是一个处理套路。

A 级：新特性，只读相关的

新特性 80% 和你无关。筛选标准就一条：是否改变你当前模块的写法或性能。相关就细读，不相关记个标题完事。别被"XX 个新特性速览"这种文章带着全文精读，那是别人的重点不是你的。

C 级：Bug Fixes，默认不读

Bug Fixes 是给正在被这个 bug 折磨的人看的。你没被折磨就跳过——真遇到了，反过来在 Bug Fixes 里搜关键词，经常有惊喜。

三个配套习惯

1. 依赖树先行：mvn dependency:tree、gradle dependencies，.NET 侧是 dotnet list package --include-transitive——先看清这次升级的波及面，再拿 S 级清单逐条核对
2. 以英文原文为准：中文翻译常有滞后和错译，最危险的一对词是 deprecated（将来删）和 removed（这次就删），看错就是事故
3. 双语对照读长文档：英文长 Release Notes 我现在用浏览器翻译插件开对照模式，逐段并排，术语拿不准就瞄一眼原文——比纯机翻靠谱，比来回查词典快

一句话收尾

升级成本的大头，往往不是升级本身，而是读 Release Notes 的方式不对。分级、检索、对照，这三招比任何"升级攻略"都管用。

你们印象最深的一次升级翻车是什么？评论区聊聊。

工具备注：双语对照阅读我用 随心翻译（Chrome 插件，按量计费不用订阅，读文档一个月大概一块钱）。