Composer怎么检查项目过期依赖 Composer技术债务管理-composer-PHP中文网

composer outdated 默认只显示主依赖，不检查子依赖；需加 --all 查所有依赖，--direct 限顶层，且须确保 composer.lock 最新，否则比对失效。

composer怎么检查项目过期依赖 composer技术债务管理

composer outdated 为什么显示不出过期包？

默认情况下 composer outdated 只显示「主依赖」（即 require 中直接声明的包），不会递归检查子依赖的过期情况。如果你改过 composer.json 但没运行 composer update，它还会基于 lock 文件旧版本比对，导致误报“无更新”。

加 --all 参数才能看到所有依赖（含 transitive 依赖）：composer outdated --all
加 --direct 强制只看顶层依赖（排除间接引入的包）
确保 composer.lock 是最新状态——先 composer update --dry-run 看差异，再决定是否真实更新
某些包被 conflict 或 replace 规则屏蔽，outdated 不会提示，需手动查其 GitHub release 页面

如何识别“技术债务型”过期依赖？

不是所有标红的过期包都该立刻升级。关键看三件事：是否 EOL、是否有 CVE、是否阻塞新功能。Composer 本身不判断这些，得靠人+工具交叉验证。

EOL 检查：访问 https://packagist.org/packages/{vendor/name}，看右上角 “Abandoned” 标签或维护状态；Laravel 的 illuminate/support v8 已停止安全更新，但 outdated 可能仍显示 “v8.83.23 → v9.52.16” 而不标注风险
CVE 关联：用 composer audit（Composer 2.5+ 内置），它会调 Packagist 的安全告警数据库；若返回 No security vulnerabilities found，不代表绝对安全——有些漏洞未录入或需手工订阅 symfony/security-advisories
PHP 版本兼容性：composer outdated --format=json 输出含 required-php 字段，对比你当前 php -v，避免升级后 Class not found

composer update 升级失败时怎么定位根本原因？

常见错误如 Conclusion: don't install vendor/package v3.0.0，本质是依赖图冲突，不是某个包本身有问题。

Workflow Decomposer

工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。

下载

先跑 composer why-not vendor/package:v3.0.0，它会列出所有阻止该版本安装的约束条件（比如另一个包硬依赖 vendor/package:^2.0）
用 composer depends vendor/package 查谁在引用它，缩小影响范围
临时降级目标包版本（如从 ^3.0 改为 ^2.9），再 composer update vendor/package 单独试，避开全量解析
注意 minimum-stability 设置：如果项目设了 "minimum-stability": "stable"，而目标包只有 RC 版本，outdated 会忽略它，update 也不会拉取

自动化监控过期依赖的最小可行方案

CI 中跑 composer outdated --direct --minor-only 是性价比最高的方式：只关注主依赖的小版本更新（安全补丁/兼容性改进），跳过大版本（避免破坏性变更）。

GitHub Actions 示例片段：

run: |
    composer outdated --direct --minor-only --no-dev --format=json | jq -e 'length == 0' || { echo "Outdated direct dependencies found"; exit 1; }

把 composer show --tree 定期存档，diff 历史输出可发现意外引入的深层依赖膨胀
慎用 composer require --update-with-dependencies：它会强制升级整个子树，可能引入未测试的组合，生产环境应始终走 composer update --with-all-dependencies + 显式指定包名

依赖过期本身不可怕，可怕的是没人知道哪些过期包正在处理支付回调、JWT 解析或日志脱敏——这些地方一旦出问题，debug 成本远高于定期 outdated 扫描。