Composer自动识别过期与下架包风险-composer-PHP中文网

composer outdated --all 必须加，因为默认命令仅扫描 composer.json 中 require 和 require-dev 显式声明的包，忽略 symfony/http-foundation、psr/log 等间接依赖，即使其存在高危漏洞（如 cve-2024-37892）也不会显示；--all 才覆盖整个依赖树（受限于 composer.lock），确保不漏关键子依赖。

composer自动识别过期与下架包风险

composer outdated --all 为什么必须加，不加就漏关键包

默认 composer outdated 只扫 require 和 require-dev 里你亲手写的包，像 symfony/http-foundation、psr/log 这类被框架拉进来的间接依赖，它直接无视。哪怕它们有 CVE-2024-37892 这种高危补丁，也不会出现在输出里。

加 --all 才真正覆盖整个依赖树——但注意：它仍受限于 composer.lock。锁文件里没记录的包，再新也查不到；已被 "replace": {"monolog/monolog": "*"} 隐形替换掉的包，也会消失在列表中。

--direct 是默认行为，适合快速确认 Laravel/Symfony 等主包要不要升
--minor-only 或 --patch-only 能过滤掉主版本跳变（如 2.x → 3.x），避免被破坏性更新干扰判断
输出带 ! 的行（如 guzzlehttp/guzzle 7.4.5 → 7.5.0 !）表示已知 BC-breaking，必须查 CHANGELOG

下架包 detection：为什么 composer outdated 不报错，但 install 会崩

composer outdated 本身不联网校验包是否存在，只比对本地 composer.lock 和缓存元数据。一个包从 Packagist 下架后，outdated 仍可能显示“up to date”，因为锁文件里还存着旧 dist URL 和 hash。

真正暴露问题的是 composer install 或 composer update：这时 Composer 才去请求 dist URL，发现 404 或证书错误，才报 Could not find package vendor/package。

Workflow Decomposer

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

下载

短期缓解靠本地缓存：只要 ~/.composer/cache 里还有 zip 文件，install 就能过
长期方案得提前配置私有源，比如用 "type": "vcs" 指向内部 Git 仓库
若包已弃用（abandoned），composer show vendor/package 会标出 abandoned 字段，这是比下架更早的预警信号

安全漏洞不能只靠 outdated，audit 才是真雷达

composer outdated 只管版本号，不管漏洞。一个包停在 1.2.0 三年不动，可能早已被曝出多个 CVE；另一个包天天升到 1.2.9，但最新版反而引入了新漏洞——outdated 对这两种情况都无感。

composer audit 才是专门查漏洞的命令，它比对 FriendsOfPHP/security-advisories 数据库，不看版本号，只认已知风险模式。

composer audit --format=json 输出结构化结果，CI 中可提取 critical 字段做阻断
它不检查平台扩展（如 ext-mysql）、不扫描 dev 依赖（除非加 --dev），需按需调整
和 outdated 结合用才完整：先看哪些能升，再看哪些必须升（因安全）

容易被忽略的“假过期”陷阱

有时 outdated 显示某包有新版，但实际不能升——不是命令错了，而是约束或环境卡住了。

典型场景包括："minimum-stability": "dev" 把 dev-main 当成可升级目标，但该分支没 tag、不稳定；composer.lock 没提交，导致团队成员看到的“可升级范围”不一致；PHP 版本模拟（config.platform.php）让某些候选版本被静默过滤，还不提示。