镜像不影响版本锁定逻辑，锁死生效取决于composer.json精确版本号、composer.lock提交至git及部署时执行composer install；改镜像后update无反应是因复用本地元数据缓存，须先composer update --refresh再--no-cache强制下载。
中文镜像本身不改变 Composer 的版本锁定逻辑，锁死是否生效，只取决于 composer.json 写法、composer.lock 是否提交、以及执行的是 install 还是 update —— 镜像只是加速下载通道，不是版本控制开关。
为什么改了镜像源，composer update vendor/package 还是没反应
根本不是镜像问题，而是 Composer 默认复用本地缓存的 packages.json 元数据（通常 15 分钟内不过期）。哪怕阿里云镜像站已同步 v3.6.0，你本地仍按旧元数据算，压根不发请求。
- 现象：终端只输出
Nothing to install or update，没有Downloading行 - 验证方式：运行
curl -I https://mirrors.aliyun.com/composer/packages.json，看Last-Modified时间是否比你上次更新更晚 - 正确解法必须两步连做：
composer update --refresh（清元数据）→composer update vendor/package --no-cache（强制走网络下 ZIP） - 别信
composer clear-cache：它清的是整个缓存目录，但下次update会立刻重建并复用旧packages.json，问题照旧
composer.json 里写 "2.9.1" 就真锁死了？
不一定。只有同时满足三个条件才算真正锁死：纯数字三位完整版本号 + composer.lock 提交到 Git + 部署时用 composer install。
- 错误写法：
"monolog/monolog": "^2.9"、"2.9.*"、"2.9"（缺补丁号）、甚至带空格的"2.9.1 "—— 这些都允许自动升级 - 验证是否生效：
composer show monolog/monolog输出的versions行必须严格等于你写的字符串，且无v前缀或+git后缀 - 改完
composer.json后必须立刻执行composer update monolog/monolog，否则composer.lock不更新，等于白改 - 项目级
"repositories"字段（哪怕内容是{}）会彻底屏蔽全局镜像配置，导致你以为走镜像，实际直连 packagist.org
CI/CD 中镜像配置“看似生效”实则失效的静默陷阱
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
删 composer.lock ≠ 强制更新，反而大概率引发线上行为突变
删掉 composer.lock 后直接跑 composer install 会报错：Lock file does not exist. Run composer update to create it. 因为 install 的设计前提就是 lock 存在。
- 真正触发重算依赖的是
composer update—— 它读composer.json约束，调用 SAT 求解器，生成新lock - 删
lock后跑composer install是非法操作，等价于执行了一次composer update，所有包都会漂移 - 想修复
lock与composer.json不一致，应优先用composer update --lock：它不碰vendor/，不查远程，只根据当前约束和已安装包重写合法lock - 团队协作中，90% 的“依赖不一致”不是 Git 合并出错，而是有人本地执行了
composer update、删了composer.lock重生成、或 CI 脚本偷偷用了composer update
最易被忽略的点：镜像源只是下载通道，它不参与版本决策；而 composer.lock 是快照，不是缓存——一旦被绕过或破坏，所有环境一致性就失去了根基。所谓“锁死”，本质是让每个环节都拒绝任何隐式变更，而不是靠某个命令或配置来“开启锁定模式”。
