答案是composer outdated在镜像环境下常不显示新版本，因其比对的是本地缓存的过期packages.json（15分钟不过期）而非实时镜像数据，需用composer update --refresh（≥2.5）强制刷新元数据或手动清理对应repo缓存子目录。
中文镜像环境下，composer outdated 仍是唯一靠谱的更新检查方式，但结果常被镜像延迟、本地元数据缓存和版本约束三重干扰——不是命令没用，而是你看到的“无更新”可能只是缓存假象。
为什么 composer outdated 在镜像下经常不显示新版本
镜像同步有 2–10 分钟延迟，而 Composer 默认复用本地缓存的 packages.json（15 分钟内不过期），导致 outdated 比对的是过期元数据，不是真实最新版。
- 直接访问镜像地址验证：比如打开
https://mirrors.aliyun.com/composer/p/provider-2024-07.json，搜索你的包名，确认版本是否存在 -
composer outdated不加参数时只看语义化约束内的更新，如果你写的是"monolog/monolog": "2.8.0"（精确锁定），它永远不报更新 - 镜像源配置被项目级
repositories覆盖：运行composer config --list | grep repositories，若输出不是你设的镜像 URL，说明配置未生效
强制刷新镜像元数据的正确操作
composer clear-cache 只清 ZIP 包，对 packages.json 缓存无效；真正起效的是丢弃元数据缓存并重拉。
- Composer ≥ 2.5：直接运行
composer update --refresh，它只刷新远程元数据，不碰已下载的 dist 包，轻量且精准 - Composer ≤ 2.4：手动删缓存目录下的对应子路径，例如
rm -rf $(composer config --global cache-dir)/repo/https---mirrors-aliyun-com-composer - 验证是否生效：执行
composer config -g repo.packagist.url确认输出为镜像地址，再跑一次composer outdated --no-cache
composer outdated 参数组合怎么选才不漏关键更新
默认行为容易掩盖安全更新或间接依赖变动，必须按需加参数，否则 CI 或人工检查会误判。
- 盯安全漏洞：
composer outdated --security-only（需 Composer 2.2+），带!标记的行必须处理 - 只看自己写的包：
composer outdated --direct，跳过symfony/polyfill这类传递依赖干扰 - 查所有可升版本（含需改
composer.json的）：composer outdated --all，能发现^2.0卡住的 3.x 新版 - 脚本解析用：
composer outdated --direct --format=json，配合jq提取.version != .latest的条目
检查结果可信的前提是锁文件真实反映当前状态
composer outdated 基于 composer.lock 和远程元数据比对，如果 lock 文件陈旧或 vendor 损坏，结果就不可信。
- CI 中必须先执行
composer install（或composer install --no-interaction），确保 lock 文件已加载、vendor 结构完整 - 本地检查前，确认
composer show -l vendor/package输出的版本号与vendor/package/composer.json一致，避免 symlink 或 path repo 导致误判 - 如果
outdated显示有更新但composer update vendor/package无变化，立刻检查该包在composer.json中的约束写法，常见坑是用了9.5.*却期待 9.6
镜像只是通道，不是策略控制器；真正决定“能不能升”“该不该升”的，始终是 composer.json 的约束、composer.lock 的状态和你手动触发的元数据刷新动作——别等镜像自动同步，要主动推它一把。
