最可靠的方法是写死版本号，即在composer.json中使用精确版本如”monolog/monolog”: “2.9.1”，配合提交composer.lock并部署时使用–locked参数，三者缺一不可。
直接写死版本号是最可靠的方法
Composer 没有 --exclude 或 disable-update 这类原生命令，所谓“禁止更新”，本质是让它**没有可选的新版本**。最稳的方式就是在 composer.json 的 require 里把包版本写成不含 ^、~、* 的精确值。
- ✅ 正确写法：
"monolog/monolog": "2.9.1"—— 执行composer update monolog/monolog会提示Nothing to install or update - ❌ 错误写法：
"monolog/monolog": "^2.9"或"~2.9.0"—— 看似“固定大版本”，实则允许升级到2.10.0、2.9.5等，不是锁定 - ⚠️ 注意：改完后必须运行
composer update monolog/monolog（哪怕只针对这一个包），否则composer.lock里可能还存着旧的浮动解析结果，导致下次install仍不生效
用 replace 阻止包被间接引入
当你用私有 fork、patch 版本或自研替代品替换了某个包，并希望 Composer 彻底跳过它（包括其他依赖声明需要它时），replace 是语义上最干净的方案。
- 在
composer.json根级加："replace": { "monolog/monolog": "*" } - 效果：其他依赖若 require
monolog/monolog，Composer 会认为“已满足”，不再安装或升级原包 - ⚠️ 风险：这不是屏蔽，而是承诺“我已提供兼容实现”。如果实际没装、没加载、类名不一致，运行时直接报
class not found - ? 适用场景：你维护一个 patch 分支并发布为
your-vendor/monolog-patched，同时用replace声明它“代替”官方包
靠 composer.lock 和 --locked 守住生产环境
开发中写死版本是起点，但真正防止意外变更的是 composer.lock 文件 + 严格部署流程。
- 务必把
composer.lock提交进 git —— 它才是所有环境一致性的唯一依据 - CI/CD 或生产部署脚本里，必须用：
composer install --locked --no-dev --no-interaction -
--locked是硬性开关：它会校验composer.lock是否存在且与composer.json兼容，不满足就直接失败，绝不会生成新 lock - ⚠️ 常见坑：CI 中执行了
composer update、或分支切换后残留旧composer.json导致 lock 被重建；docker 构建中用了共享缓存也可能干扰
临时跳过更新？别信“排除”，要靠“只列要更的”
很多人搜 composer update --exclude，但这个参数根本不存在。想在一次 update 中保留某些包，唯一安全做法是显式列出你想更新的包。
- 比如只想更新 laravel 相关，其他不动：
composer update laravel/framework illuminate/database - 先用
composer outdated看哪些可升，再手动拼出要更新的列表，漏掉不想动的即可 - ⚠️ 别用
composer update --with-all-dependencies后再幻想“跳过某几个”——它会强制刷新整个依赖树，锁定的包也保不住 - ? 小技巧：CI 中可加一步检查：
git status --porcelain composer.lock，非空就中断构建，防 lock 被悄悄改掉
真正起效的永远是那三样：精确版本号写进 composer.json、composer.lock 提交进仓库、部署时强制用 --locked。任何想靠配置项“禁止”或命令行“排除”的思路，都会在团队协作或 CI 中露出破绽。