Composer怎么关闭自更新 Composer怎么停留在固定版本【维护】

composer 本身没有“关闭自更新”开关

Composer 不会像某些 CLI 工具那样主动联网检查并升级自己。所谓“自更新”，其实是用户手动执行 composer self-update 触发的——它不是后台静默行为，也没有定时任务或自动拉取机制。因此，不存在需要“关闭”的运行时自更新功能。

但你真正想防的，其实是「意外升级 Composer 本体」，比如 CI 脚本里误写了 composer self-update，或团队成员本地手抖执行了。这时候靠“关开关”没用，得靠流程和约束。

• CI/CD 中永远不要出现 composer self-update；改用预装固定版本的 docker 镜像（如 composer:2.6.6）更稳妥
• 本地开发可加 shell 别名拦截：在 ~/.bashrc 或 ~/.zshrc 里写 alias composer='composer --no-plugins'（虽不阻止 self-update，但能禁掉可能篡改行为的插件）
• 检查当前版本是否锁定：运行 composer --version，输出应为类似 Composer version 2.6.6，而非带 -snapshot 或 +git 后缀的开发版

如何让项目依赖不随 composer update 升级

这才是多数人实际卡住的地方：明明没动 composer.json，一跑 composer update，某个关键包（比如 laravel/framework）还是被升了——因为它的版本约束是浮动的。

• 把 "laravel/framework": "^10.0" 改成 "laravel/framework": "10.32.1"，去掉所有 ^、~、*
• 改完立刻执行 composer update laravel/framework，让 composer.lock 记下这个精确版本
• 务必提交 composer.lock 到 Git；否则别人 composer install 时，Composer 会按 composer.json 里的浮动规则重新解析，锁就失效了
• 验证是否真锁住了：再跑一次 composer update laravel/framework，如果输出 Nothing to install or update，说明成功

--locked 是生产环境最硬的保险栓

部署时哪怕 composer.json 被改错、composer.lock 版本不匹配，--locked 也能直接拦停，避免线上装错依赖。

• 上线命令必须是 composer install --locked --no-dev --no-interaction
• 它要求：composer.lock 必须存在，且里面每个包的版本都得满足 composer.json 的约束（哪怕你写的是 "^2.0"，lock 里是 "2.9.1" 也行；但如果 lock 里是 "3.0.0"，而 json 写着 "^2.0"，就会报错退出）
• 注意：--locked 和 --dry-run 冲突，不能一起用；也不能配合 --with 等参数
• CI 中可加校验：执行 git status --porcelain composer.lock，非零退出就中断构建，防止 lock 被悄悄改写

别信 platform 或 replace 能“禁止更新”

有人试过在 composer.json 里配 "config": {"platform": {"some/package": "1.0.0"}}，以为能骗过 Composer 不去管它——结果发现只是跳过安装，不影响其他包依赖它时触发升级逻辑；replace 更危险，它承诺“我已提供该包”，但没代码实现的话，运行时直接 class not found。

• platform 只适用于你确定系统级已装好扩展（如 ext-redis），或某包完全由你私有仓库托管且绝不走 Composer 安装流程
• replace 的正确用法是 fork 后发布新包名（如 myorg/monolog），再用 "replace": {"monolog/monolog": "*"} 声明替代，同时确保你 fork 的代码兼容原接口
• 想锁定，唯一靠谱路径还是：精确版本号 + 提交 lock 文件 + 部署用 --locked

最容易被忽略的点是：很多人改了 composer.json 的版本号，却忘了运行一次 composer update vendor/package 来刷新 composer.lock。lock 文件不更新，所有“锁定”都是纸面功夫。