composer outdated 默认只显示语义化版本允许范围内的更新，如装 ^2.5.0 则仅报 2.x 新版；无输出常因版本写死或使用 dev 分支，可用 --all、--direct、-f json 等参数调整行为。
composer outdated 能看到哪些包要更新
直接运行 composer outdated 就能列出所有已安装但有新版本的包，它默认只显示「语义化版本允许范围内」的更新（比如你装的是 ^2.5.0，它只报 2.x 的新 patch/minor 版，不报 3.0）。这不是“全量扫描”，而是基于当前 composer.lock 和 composer.json 的约束做比对。
常见错误现象：composer outdated 什么都没输出，不是没更新，很可能是你的 require 写死了版本（如 "monolog/monolog": "2.8.0"），或者用了 dev-main 这类不稳定分支——Composer 默认跳过 dev 分支的更新检查。
- 加
--all参数可强制检查所有包，包括 dev 分支和超出当前约束的版本（比如 3.x） - 加
--direct只看composer.json里直接声明的包，排除依赖树里的间接依赖 - 加
-f json输出结构化 JSON，适合脚本解析
composer update 后版本没变？检查约束写法
执行 composer update vendor/package 却没升级，大概率是 composer.json 里该包的版本约束太窄。比如写成 "phpunit/phpunit": "9.5.10"（精确版本）或 "9.5.*"（只允许 9.5.x），那即使 9.6 已发布，也不会动。
使用场景：你想稳住测试环境用 9.5，但又想偶尔看看 9.6 是否兼容，就别锁死，改用 ^9.5 或 ~9.5.0。
-
^9.5允许升级到9.5.0 → 9.999.999，但不会到10.0 -
~9.5.0等价于>=9.5.0 ，更保守 - 改完约束后必须运行
composer update vendor/package，不能只靠composer install
composer show -l 查看本地已安装版本详情
composer show -l 是确认“当前到底装了啥”的最快方式，它只读 composer.lock，不联网、不解析依赖树，结果最真实。比 composer list 或翻 vendor/autoload.php 靠谱得多。
性能影响：零延迟，适合 CI 脚本中快速断言某个包版本是否符合预期。
- 查单个包：
composer show -l monolog/monolog - 输出含完整版本号、安装路径、License、源类型（dist / source）
- 注意：如果包是通过
pathrepo 本地加载的，这里会显示source类型，而非 dist zip
为什么 composer outdated 显示有更新，但 composer update 报错？
典型错误信息：Root composer.json requires package ^2.0, found package[1.9.0] but it does not match the constraint.。这说明你本地 lock 文件里存的版本（1.9.0）和 composer.json 要求的约束（^2.0）冲突——可能之前手动改过 composer.lock，或多人协作时没提交最新 lock。
根本原因不是网络或权限，而是 Composer 的版本解析逻辑严格依赖 lock 文件与 json 的一致性。
- 先运行
composer validate检查 json 格式和约束合法性 - 再运行
composer update --dry-run预演，看具体哪条依赖卡住 - 如果确定要强刷，用
composer update --with-all-dependencies解开嵌套约束（慎用，可能连带升级一堆间接依赖）
真正容易被忽略的是：lock 文件不是“缓存”，它是依赖解析的权威快照。任何绕过它的操作（比如手动删 vendor 再 install）都可能让环境行为不可复现。
