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 文件不更新，所有“锁定”都是纸面功夫。
