技能 · 编程

依赖升级：先读 changelog 再小步升

升级依赖前先读变更日志里的破坏性改动，按小版本逐步升，每步跑测试并保留回滚点，避免一次跳多个大版本。

编程高阶后端开发运维

适用边界：适合有测试覆盖、依赖较多的长期项目；临近交付的冻结期不建议做大版本升级，风险高于收益，应排到发布之后再做。

怎么做

先列出待升级依赖和当前版本，标出跨大版本和仅补丁更新的两类。
先读变更日志里的破坏性改动一节，逐条对照项目实际用到的接口。
按补丁、次版本、大版本的顺序分批升级，每一批单独提交并跑测试。
每批升级后记录构建时间和包体积变化，出现异常就回滚到上一个提交。

交付前检查

破坏性改动逐条确认过，没有漏掉被重命名或删除的接口。
每批升级都能单独回滚，提交历史清晰可查。
升级后关键功能和构建产物都验证过，不只是装上了。

可复制提示词

你是依赖维护负责人。输入：【依赖清单与版本】=____；【项目用到的相关接口】=____；【测试覆盖情况】=____。请制定升级计划：分批顺序、每批要读的变更日志条目、需要改的代码点、验证清单、回滚方式。要求按补丁到次版本到大版本推进，不跳过破坏性改动确认。不要假设依赖行为不变，最后指出风险最高的一次升级。