lock文件过期不是错误而是提示，表明composer.lock与composer.json依赖声明不一致；需用install复现环境、update升级依赖，且必须提交更新后的lock文件。
Git拉取后composer install失败，提示lock过期
直接运行 composer install 会失败，因为 Composer 拒绝用不匹配的 composer.lock 还原依赖——它只校验 lock 文件是否覆盖当前 composer.json 的全部声明。这不是网络问题，而是协作中常见的“只提了 composer.json 没提 composer.lock”导致的。
常见诱因包括：
• Git 合并时漏掉 composer.lock 提交
• Windows 和 Linux 协作者共用项目，换行符差异让 Git 标记为 modified，但实际内容未损坏
• CI 脚本误删 composer.lock 但没重建
- 先跑
composer validate：若输出The lock file is not up to date with the latest changes in composer.json，说明是“过期”，不是损坏 - 如果刚
git pull了别人代码，且远程分支已提交新composer.lock，优先执行git checkout -- composer.lock拉回最新版，再composer install - 如果本地
composer.json确实被改过（比如加了新包），又不想升级任何依赖，就用composer update --lock—— 它只重写 lock，不碰vendor/，也不查远程
CI环境里镜像配置不生效，始终直连packagist.org
GitHub Actions 或 GitLab CI 默认不继承你本地的全局镜像配置，composer config -g 写的设置在 CI 中根本不存在。你以为配好了，其实每次都是从头走默认源。
必须在 workflow 中显式执行镜像设置命令，且注意 Composer ≥ 2.2 的键名变更：
- 用
composer config -g repositories.packagist.org.type composer和composer config -g repositories.packagist.org.url https://mirrors.aliyun.com/composer/两行设置（缺一不可） -
url值末尾必须带/，否则请求路径变成/p2/xxx.json，返回 404 或 SSL 错误 - CI 中建议加
--no-interaction和--no-cache参数，避免缓存干扰：composer install --no-interaction --no-cache - 验证是否真走镜像：在 CI 日志里 grep
https://mirrors.aliyun.com/composer/，或用curl -I https://mirrors.aliyun.com/composer/packages.json看是否返回HTTP/2 200
项目级repositories字段悄悄屏蔽了全局镜像
只要项目根目录 composer.json 里有 "repositories" 字段，哪怕内容是空数组 {} 或只写了 {"packagist.org": false}，全局镜像配置就彻底失效——Composer 会完全忽略 config -g 设置。
这是最常被忽略的静默覆盖行为，排查方法很直接：
- 执行
grep -A 5 '"repositories"' ./composer.json，看是否存在该字段 - 临时清空：
composer config --unset repositories（注意不加-g） - 清完必须删掉
vendor/和composer.lock，否则旧 lock 文件仍按原始源解析 - 如果项目确实需要自定义源（比如私有包），应把镜像配置也写进这个字段里，而不是依赖全局设置
版本不更新，不是缓存问题，而是lock文件在强制锁定
composer clear-cache 对版本升级完全无效。缓存只影响下载过程，不参与版本决策。composer install 完全忽略缓存，只按 composer.lock 里记录的精确版本号还原 vendor/。
想让新版本进项目，必须触发 lock 文件更新：
- 改
composer.json里的约束（比如把"monolog/monolog": "^2.0"改成"^3.0"），再跑composer update monolog/monolog - 或者直接删
composer.lock再composer install，但会重算整棵树，容易引入意外冲突 -
composer update没反应？先确认约束有没有变——Composer 不会主动升级，只响应你写的范围变化 - 加
-v参数运行：composer update -v，看输出是否出现Nothing to install or update
真正难搞的不是配置，是锁文件和依赖约束之间的隐性耦合：一个包的版本变动可能牵扯十几个子依赖的兼容性，而 Composer 默认只报“0 installs, 0 updates”，不告诉你卡在哪一层。
