直接运行 composer outdated 是最轻量的检查方式，但它默认仅扫描 composer.json 中 require 和 require-dev 显式声明的包，漏掉间接依赖（如 psr/log）、dev 工具（如 phpunit/phpunit）及被 replace 隐蔽覆盖的包；需加 --all 才全面识别，其中带 ! 表示 BC-breaking、红色箭头提示主版本跃迁、黄色行代表补丁更新。
直接运行 composer outdated 是最可靠、最轻量的检查方式——它不改文件、不联网查 changelog，只比对本地 composer.lock 和 Packagist 上当前满足约束的最新兼容版本。
为什么默认 composer outdated 会漏掉大部分包
它默认只扫描你 composer.json 中 require 和 require-dev 下显式声明的包。以下三类关键包它完全不扫：
-
psr/log、symfony/polyfill-php81这类被其他包带进来的间接依赖（比如通过laravel/framework引入） -
phpunit/phpunit这类仅在require-dev里但没被显式列在outdated默认范围的工具 - 被
"replace": {"monolog/monolog": "*"}这类规则隐式覆盖的包，Composer 认为“已由主包接管”，跳过独立检查
所以，真想摸清全貌，必须加 --all： composer outdated --all
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
composer outdated --all 输出里那些符号和颜色什么意思
终端输出不是装饰，每个标记都对应实际风险：
- 带
!的行（如guzzlehttp/guzzle 7.4.5 → 7.5.0 !）：Composer 自动识别出该更新含 BC-breaking 更改，哪怕只是次版本升级，也得去翻 CHANGELOG - 红色箭头（如
v5.4.32 → v6.0.19）：约束允许主版本跃迁，但很可能破坏兼容性；JSON 输出中对应字段是"latest-status": "major" - 黄色行（如
v5.4.32 → v5.4.37）：补丁级更新，大概率安全，但仍有行为变更可能（比如日志字段名从context改成extra） - 不带
*却有新版本：说明你用了dev-main或dev-develop分支，Composer 不把它当稳定版比对，不是“没问题”，而是“没法比”
怎么安全地把检查结果转成可执行动作
outdated 只是看，不升级。真正动手前，先用 --dry-run 预览 Composer 实际打算怎么动：
- 查单个包影响：
composer update guzzlehttp/guzzle --dry-run -v，看是否连带降级或冲突 - 避免意外主版本升级：
composer outdated --minor-only先过滤，再对结果里的包逐个composer update vendor/package-name - CI/CD 中别靠人眼扫：
composer outdated --all --format=json | jq -r '.packages[] | select(.latest_status == "major")'，自动拦截高风险项 - 升级后类找不到？90% 是 autoload 没刷新：
composer dump-autoload -o必跑
真正容易被忽略的是：如果 composer.lock 本身没提交，或者本地缓存过期，outdated 读的就是旧元数据——它显示“无更新”，不代表真实环境安全。
