依赖长期不升级会积累安全与兼容风险，但每天几十个无人审查的机器人 PR 同样无效。自动化应减少决策成本，并为高风险升级保留人工判断。
按风险分组
补丁版本和开发工具可按周合并成组；运行时框架、数据库驱动和基础镜像单独处理；重大版本必须附迁移说明与负责人。
{
"schedule": ["before 6am on monday"],
"rangeStrategy": "pin",
"packageRules": [
{"matchUpdateTypes": ["patch"], "groupName": "weekly patches"}
]
}固定包管理器版本，并在 CI 中执行 frozen lockfile 安装，确保 manifest 与锁文件一致。
建立合并门槛
- 单元、集成和契约测试全部通过
- 生成 SBOM 并重新执行漏洞扫描
- 检查许可证和已知 breaking changes
- 自动合并仅限低风险范围且有撤销路径
发布后验证
依赖升级仍是生产变更，应走金丝雀或分批发布。观察错误率、资源消耗、启动时间和下游兼容性。
收尾清单
每月处理被长期忽略的升级和失败 PR。衡量依赖年龄、修复高危漏洞的时间和回退率，而不是机器人创建了多少请求。