安全升级依赖
目标：将单个依赖（或一个紧密耦合的组）升级到更新的版本，并事先理解其破坏性变更，而不是事后才发现。
计划
- 锁定当前状态。 找到已安装版本（锁定文件，而非仅清单文件）和目标版本。如果用户说“最新”，请使用包管理器查找该版本（例如
npm view <pkg> version,pip index versions <pkg>,cargo search等），并说明版本号。 - 在干净的代码树上记录基线。 执行安装、构建、测试、代码检查、类型检查。记录所有预先存在的失败，以免错误地归咎于升级。
- 阅读真实的发布说明。 打开从当前版本到目标版本之间每个版本的更新日志、发布说明或迁移指南。提取：破坏性变更、已移除或重命名的 API、新的最低运行时版本、已更改的默认值、弃用项。为每一项引用来源链接。如果找不到发布说明，请说明，并将此次升级视为更高风险。
- 映射影响范围。 使用
rg在代码库中搜索每个被移除、重命名或更改的 API。在编辑之前列出受影响的文件。
执行
- 仅升级此依赖项（以及必需的同伴依赖）。不要运行“全部更新”。
- 使用项目的包管理器更新清单文件和锁定文件，而不是手动修改。
- 根据发布说明的要求进行代码更改，从最小的改动开始。当新形式与旧形式等效时，替换已弃用的用法。
- 再次运行安装、构建、测试、代码检查和类型检查。与基线对比。
- 对于主版本升级，如果可行，还需要运行应用程序或主要示例路径，并检查打包大小、启动警告和弃用警告。
- 如果升级需要提升最低运行版本或同伴依赖版本，请先停止并询问，然后再更改。
报告
升级: <包名> <旧版本> -> <目标版本>
来源: <更新日志链接>
应用的破坏性变更: <列表，包含文件引用>
所做更改: <摘要>
验证: <命令，基线 vs 之后>
警告或后续操作: <弃用项、跳过的项目、风险>
回滚: 恢复 <文件>，或 `git revert <提交>`
规则
- 切勿在同一次更改中同时进行升级和重构。
- 切勿跳过失败的测试或放宽版本范围来掩盖问题。
- 安全修复：仅当你在官方公告或发布说明中看到该升级所解决的安全公告时，才说明是哪个公告。
- 如果传递依赖导致冲突，请展示冲突输出并提供选项，而不是盲目覆盖。