Composer锁定依赖需同时满足：composer.json写三位完整版本号（如"2.9.1"）、composer.lock提交至Git、部署时运行composer install——三者缺一不可；否则版本仍可能漂移。
中文镜像环境下，Composer 锁定核心依赖包版本和官方源没本质区别——真正起作用的从来不是镜像地址，而是 composer.json 写法、composer.lock 是否提交、以及是否统一用 composer install。但镜像会放大某些错误操作的影响，比如缓存延迟导致“明明锁了却装了新 patch”。
为什么中文镜像会让版本锁定更难察觉漂移
国内主流镜像（如阿里云、腾讯云、华为云）会对 packagist.org 的元数据做缓存，通常 TTL 为数小时。这意味着：
- 你本地
composer.json写了"monolog/monolog": "2.9.1"，但镜像缓存里已收录2.9.2的 metadata，且未同步2.9.1的完整 dist 包信息 →composer install可能 fallback 到解析行为，悄悄装上2.9.2 - 镜像不保证 commit hash 与原始源完全一致，尤其对
dev-分支类引用；若composer.lock里记录的是"source": {"reference": "abc1234"}，而镜像返回的 zip 包 SHA256 不匹配，Composer 会报错退出，而非静默替换 - 部分镜像（尤其是自建私有镜像）未严格同步
dist和source两种分发方式，导致composer install在 fallback 时选错路径，装出非预期版本
写死版本号必须满足三个硬性条件
仅改 composer.json 不够，必须同时满足：
-
"monolog/monolog": "2.9.1"—— 不能带空格、不能是"2.9.1 "或"v2.9.1"，否则 Composer 解析时可能忽略或误判 - 执行
composer update monolog/monolog（不是全量update），确保composer.lock中该包的"version"字段严格等于"2.9.1"，且"source": {"reference": "..."}是确定 commit hash，不是"dev-main"或"dev-develop" - 把更新后的
composer.lock提交到 Git，且确认未被.gitignore过滤（常见错误：误加composer.lock到全局 ignore 规则）
CI/CD 中验证锁定是否生效的实操检查点
别只信日志里有没有 Resolving dependencies，要直接查结果：
- 在 CI 脚本开头加：
ls -l composer.lock && git log -1 --format=%H -- composer.lock—— 确保 lock 文件存在且来自当前 commit - 安装后立刻运行：
composer show monolog/monolog | grep versions，输出必须是versions : * 2.9.1（注意星号后紧接空格再跟版本号，无额外字符） - 检查
vendor/composer/installed.json中对应包的version字段，必须与 lock 文件中一致；若出现"version": "2.9.1.0"或带+git后缀，说明实际装的是 snapshot 版本，不是你写的精确版 - 禁用 vendor 缓存：
composer install --no-cache，避免 GitHub Actions 或 Jenkins 复用上个分支缓存的过期 lock
中文环境协作中最容易被忽略的破坏点
不是镜像本身有问题，而是人操作链断了：
- 同事 A 在 PHP 8.2 环境下生成
composer.lock，同事 B 用 PHP 7.4composer install—— Composer 2.9+ 会因 platform 不匹配拒绝安装，或退化为重新求解，装出低版本兼容包（如psr/log降级到1.x） - CI 脚本里写了
composer install --no-dev，但没校验composer.lock是否存在；一旦 lock 缺失，它就等价于composer update --no-dev，所有包都漂移 - 团队用了
config.platform.php，但没写小版本号，比如只写"8.2"，而服务器是8.2.12，镜像源可能返回不同兼容集
真正稳住版本的，不是换镜像或加配置开关，而是让每次 composer install 都能拿到同一份 composer.lock，且所有机器的 PHP 版本、扩展、平台约束都对得上。镜像只是通道，不是保险柜。
