保障核心配置不可变：利用Composer冻结特定包版本防止误升级破坏系统

保障核心配置不可变：利用Composer冻结特定包版本防止误升级破坏系统

在依赖管理这件事上，一个核心共识是：直接写死版本号才是真锁定，其他方式都只是临时绕行或表面控制。

composer.json 里怎么写才算真正冻结一个包

关键在于格式。真正有效的锁定，必须使用纯数字、无任何前缀后缀的精确写法，例如："monolog/monolog": "2.9.1"。任何带有 ^、~、* 或 dev-main as 2.9.1 的写法，本质上都留了后门——它们会在下次执行 composer update 时被重新解析，升级风险随之而来。

• "2.9" 这种写法不推荐：虽然某些Composer版本会自动补全为 "2.9.0"，但行为并不一致，别去赌这个可能性。
• "2.9.*" 是通配符，它允许安装 2.9.999，这显然不是锁定。
• 修改完 composer.json 后，必须立刻执行 composer update monolog/monolog，否则 composer.lock 文件里记录的依然是旧版本或范围值。
• 如果目标包是某个依赖的依赖（没有直接出现在项目的 require 里），仅仅修改根项目的 require 是无效的。这时需要借助 replace 或 conflict 来干预整个依赖关系图。

为什么只靠 composer.lock 不够安全

这里有个常见的误解：把 composer.lock 当作契约。实际上，它只是一份快照。这份快照仅在执行 composer install 时生效。一旦它被删除、被覆盖，或者在CI流水线中根本没有被拉取到（例如GitHub Actions默认只checkout代码），那么 composer install 就会退化成依据 composer.json 重新解析依赖。此时，如果 composer.json 里写的是 "^2.8"，那么装上 2.12.0 也就不足为奇了。

• 必须将 composer.lock 提交到Git仓库中，绝不能把它放进 .gitignore。
• 在CI/CD构建环节，务必使用 composer install --no-dev --no-interaction，绝对不要使用 update。
• 上线前增加一道校验工序：执行 composer install --locked。这个命令会严格比对 composer.lock 中记录的每个包是否仍然满足 composer.json 中的约束，一旦不满足，构建将直接失败。
• 需要注意的是，某些插件（如 hirak/prestissimo）或新版Composer（2.5+）在执行 --lock 相关操作时可能会校验hash或修正字段格式，导致代码库出现无关的diff变更。

临时跳过某个包更新的命令是否可靠

命令 composer update --ignore=monolog/monolog 听起来很美好，但它只在Composer 2.2+版本中生效。更重要的是，它并不改变底层的依赖解析逻辑——如果被忽略的包被其他依赖强制要求使用新版本，它仍然可能被间接升级。因此，这算不上“绝对冻结”。

• 低版本的Composer不支持 --ignore 选项，强行使用会报错 Unrecognized option "--ignore"。
• 如果只想更新其他包，最稳妥的方式是显式列出所有需要更新的包名：composer update lara vel/framework symfony/console，而不列出需要冻结的包。
• 在执行更新前，可以先使用 composer update --dry-run 预览哪些包会被升级，确认无误后再执行真实操作。
• 不要相信 composer config --no-updates 这类伪配置，它实际上并不起作用。

replace 和 conflict 是最后防线

当某个包与当前项目存在已知的兼容性冲突，或者你使用了定制化的分支需要从依赖树中“逻辑移除”原始包时，replace 和 conflict 提供了更底层的控制手段。

• "replace": {"monolog/monolog": "*"}：这声明了你的项目已经提供了同名包的全部功能，Composer将不再安装它（同时也不会检查它的依赖）。
• "conflict": {"monolog/monolog": ">=3.0.0"}：这明确禁止安装指定版本范围内的包，update 时如果解析出该版本，Composer会直接报错退出。
• 这两个字段都需要写在 composer.json 的根级别，而不是 require 部分下面。
• replace 不会影响自动加载，但你必须确保自己提供的代码能够真正替代原包的行为，否则运行时可能会遇到 Class not found 错误。

真正锁定依赖需三步：一是在composer.json中用纯数字版本号如"monolog/monolog": "2.9.1"；二是将composer.lock提交至Git；三是在CI中使用composer install --locked校验。

说到底，实现真正锁定的关键动作只有这三个：写死版本号、提交 composer.lock、在CI中使用 --locked 校验。漏掉其中任意一环，所谓的“冻结”很可能就只是一种心理安慰。