如何通过Composer Dependabot实现依赖升级，告别手动维护的繁琐？

本文共计795个文字，预计阅读时间需要4分钟。

Dependabot 可以自动升级 composer.json 中的版本号，但绝不会被 composer.lock 文件中的版本号所覆盖——这不是缺陷，而是设计。你必须在 CI 中明确运行 composer update --lock --no-install 来同步 lock 文件，否则所有 composer install 都会失败。

Dependabot 提的 PR 为什么总报 “Your lock file does not contain a compatible set of packages”

这不是 Dependabot 出错了，而是它和你的 CI 流程没对齐。Dependabot 只做一件事：读取你当前 composer.json 里的约束（比如 "guzzlehttp/guzzle": "^7.2"），查 Packagist 上满足该约束的最新版本（比如 ^7.8），然后生成一个仅修改这行的 PR。

• composer.lock 完全不动，Dependabot 不执行任何命令，也不解析依赖树
• 你的 CI 如果直接跑 composer install，就会发现 lock 文件里还是旧哈希，和新 composer.json 对不上
• 错误信息中的 “compatible set of packages” 指的就是这个不匹配状态

CI 中必须加 composer update --lock --no-install

这一步不能省，也不能挪到 merge 后再做——必须放在 Dependabot PR 的 CI 流程里，且要确保能写回 composer.lock 并提交。

• 用 composer update --lock --no-install，而不是 composer update：前者只更新 lock 文件，不下载包、不生成 autoload，安全轻量
• 加 git diff --quiet composer.lock || (git add composer.lock && git commit -m "chore: update composer.lock") 自动提交变更
• GitHub Actions 中监听 pull_request_target 事件，否则无法读取 secrets 或 checkout 主分支代码来校验
• 顺序建议：composer validate → composer update --lock --no-install → 提交 lock 变更

dependabot.yml 配置常见踩坑点

配置文件名、路径、字段名错一个字都不生效，而且 Dependabot 对 PHP 项目有硬性限制。

• 文件必须叫 .github/dependabot.yml，.github/dependabot.yaml 或放错目录（如 .github/workflows/）都不行
• package-ecosystem 必须设为 "composer"，不是 "php" 或 "packagist"
• directory: "/" 是默认值，但如果你的 composer.json 不在根目录（比如 monorepo），得明确写 directories: ["/backend", "/shared"]，directories: ["/packages/*"] 这种通配写法无效
• 私有包或自定义 Packagist 源需额外配置 registries，否则 Dependabot 解析失败，直接跳过该依赖

最易被忽略的是：Dependabot 从不验证约束是否真能命中新版本——它只按 semver 规则比对字符串。如果你写了 "monolog/monolog": "2.8.*"，它永远不会升到 3.x，哪怕 3.0 其实兼容；这种“安全但保守”的行为，需要你定期用 composer outdated --direct 主动检查主版本跳变和约束失效。