composer outdated 显示的包与 composer.json 不一致，是因为它基于 composer.lock 快照比对 Packagist 最新版本，而非实时解析 composer.json 约束；若未运行 composer update/install，锁文件滞后会导致结果不准。

composer outdated 显示的包为什么和 composer.json 不一致

因为 composer outdated 默认只检查已安装到 vendor/ 的包，且按当前 composer.lock 解析依赖树——它不重新解析 composer.json 的约束，而是基于锁文件“快照”比对 Packagist 上的最新可用版本。如果你刚改了 composer.json 但没运行 composer update 或 composer install，锁文件没更新，结果就滞后。

常见错误现象：composer outdated 完全不显示某个你刚加进 composer.json 的包；或显示某包“无更新”，但其实你在 composer.json 里写的约束（比如 "monolog/monolog": "^2.0"）理论上允许升级到 2.10.0，却卡在 2.3.5。

• 先确认锁文件是否最新：运行 composer install（尤其 CI 环境常跳过这步）
• 想强制按 composer.json 重算（忽略 lock）：加 --outdated 不够，得用 composer show --outdated --direct 配合 composer update --dry-run
• 注意 --direct 参数只显示根依赖（即你手动写进 composer.json 的），不显示子依赖；默认不加则全量显示，容易淹没重点

composer outdated 怎么只看安全更新

Composer 本身不内置“仅安全更新”过滤，composer outdated 输出里也不会标红或打标。所谓“安全更新”实际由 Symfony Security Checker 或更现代的 composer audit 提供，不是 outdated 的职责。

使用场景：上线前快速扫一遍有没有已知漏洞的包版本，而不是泛泛看哪些能升。

• 必须用 composer audit（Composer 2.5+ 内置）：它调用 packagist.org 的安全告警数据库，输出带 CVE 编号的明确风险
• composer outdated 加 --minor 或 --patch 只控制版本号段，和安全性无关；--format=json 也不能提取安全信息
• CI 中别只跑 outdated 就认为“没高危漏洞”——漏掉 audit 是常见疏忽

composer outdated 输出里 version 列显示 “dev-main” 或 “dev-develop” 怎么办

这表示该包当前安装的是开发分支的源码（比如通过 "package-name": "dev-main" 指定），而非稳定版本号。Composer 无法比对这种分支引用和 Packagist 上的正式版，所以会标为 up to date 或直接跳过提示，但其实可能已有新 tag。

Academic Composer Upload

辅助学术写作，包括查找资料、生成大纲、引用扩写及润色风格，同时确保引用规范。

下载

参数差异：--all 会强制列出所有包（包括 dev 分支），而默认行为可能隐藏它们；--direct 对 dev 分支同样有效，但依然不会告诉你“main 分支最近一次 commit 是什么”。

• 想确认是否真有新版 tag：手动查 composer show package-name，看 versions 行是否包含 dev-main 和其他 v3.x.x 标签
• 想切到稳定版：删掉 composer.json 里的 dev-main，换成具体版本约束（如 ^3.2），再 composer update package-name
• CI 脚本中遇到 dev-* 版本，outdated 结果不可信，应禁止提交或加人工审核

为什么 composer outdated 在 GitHub Actions 里总显示 “No packages found”

根本原因是没装依赖——composer outdated 依赖 vendor/ 目录和 composer.lock，而很多 Action 模板（尤其是用 actions/checkout 后直接跑 outdated）跳过了 composer install 步骤。

性能影响：本地跑 outdated 很快，但若 CI 每次都从空 vendor 开始，它会先触发隐式 install，反而变慢且结果不准。

• 确保 workflow 中 composer install 在 outdated 之前执行（且 cache vendor/ 和 ~/.composer/cache）
• 避免用 composer create-project 或 require --no-install 后直接跑 outdated——vendor 为空时它真的找不到任何包
• 加 --strict 参数会让命令在无包时返回非零退出码，方便 CI 判断失败，但不解决根本问题

事情说清了就结束。最常被忽略的一点：你看到的“可更新列表”，本质是 lock 文件 + 当前网络状态下的静态快照；它不预测兼容性，也不校验 PHP 版本适配——outdated 说能升，update 时仍可能因平台配置或冲突失败。