Composer.lock 文件需设系统级只读权限才能真正防止被意外重写
你的 composer.lock 文件又被意外重写了？这根本不是 Composer “没锁住”，而是它默认就允许写入——只要文件权限放开、命令用错、或者流程稍有失控，它就会毫不犹豫地修改 lock 文件。想要一劳永逸？唯一真正起效的“只读”，是让操作系统从底层拒绝写入。
怎么给 composer.lock 加系统级只读锁
方法其实很简单，直接对文件权限动手。在 Linux 或 macOS 系统下，打开终端，进入项目目录，执行这条命令：
chmod 444 composer.lock
这行命令的作用，是让文件对所有用户（包括所有者、组和其他人）都只有读取权限。一旦设置，当 Composer 或其他任何进程尝试写入时，系统会直接拦截并报错：file_put_contents(./composer.lock): failed to open stream: Permission denied。这才是真正的“物理锁”。
- 注意，别用
555（赋予可执行权限），Composer 不需要执行权，某些 CI 环境反而可能因为权限异常而中断。 - Windows 用户也有对应的方法，可以使用：
attrib +R composer.lock - 为了在 CI 脚本中更稳妥，可以加上容错处理：
chmod 444 composer.lock || true（后面的|| true是为了防止文件不存在时报错导致脚本退出）。
这个操作不修改任何 Composer 配置，不依赖任何插件，纯粹依靠文件系统进行拦截，可以说是最硬核也最可靠的方案。
为什么 --no-scripts 或 --no-plugins 压根不防 lock 被改
这里有个常见的误区。很多人以为在命令里加上 --no-scripts 或 --no-plugins 就能防止 lock 文件被改动。其实，这两个参数只控制是否执行安装前后的脚本或插件，跟 composer.lock 文件的读写机制毫无关系。
真正决定 lock 文件是否会被修改的，只有两个核心事实：
- 你运行的是
composer install还是composer update—— 前者默认读取现有 lock 文件安装，不会修改它；而后者一定会尝试更新依赖并重写 lock 文件。 composer.json的依赖声明和现有composer.lock文件是否完全一致 —— 如果不一致，install命令会发出警告，但通常不会自动重写；然而，如果 lock 文件缺失、损坏，或者使用了--ignore-platform-reqs等特定参数，Composer 的行为就可能退化为update。
所以，指望通过命令行参数来“预防修改”只是一种错觉，系统级的只读权限才是第一道也是最重要的一道防线。
CI/CD 中必须加的两道校验
仅仅设置文件只读可能还不够，尤其是在自动化流程中。你的 CI/CD 流水线需要主动“盯住” lock 文件的状态，增加两道主动校验：
- 构建前检查：在构建开始前，先检查 lock 文件是否被意外改动。可以执行：
git diff --quiet composer.lock || (echo “composer.lock changed! Commit it first.”; exit 1)。这样一旦发现变动，构建就会立即失败并提示。 - 部署时强制锁定安装：在部署命令中使用
composer install --locked --no-interaction --prefer-dist。关键就在于--locked这个参数，它会强制 Composer 严格使用当前的 lock 文件，如果发现与 json 不匹配，直接让安装失败，而不是悄悄生成一个新的 lock。 - 额外提醒：别相信
composer config --no-updates能防止更新，它并不生效；也绝对不要在 CI 里运行composer update，哪怕你只想更新某一个包，它也会导致整个 lock 文件被重写。
手动改 composer.lock 是最危险的“捷径”
最后，必须警惕一个高风险操作：手动编辑 composer.lock 文件。它不是一个简单的配置文件，而是一个包含精确包版本、哈希值、完整依赖树结构以及 content-hash 的完整快照。手动修改时，哪怕只改错一个逗号、漏掉一个子依赖，或者哈希值没有同步更新，就会导致一系列问题：
- 运行
composer install时报出令人困惑的错误，例如Invalid argument supplied for foreach()（这通常是 JSON 结构解析失败导致的）。 - 更棘手的是状态不一致：可能在你的本地环境能安装成功，但在 CI 服务器上构建失败，因为 CI 环境的校验逻辑往往更严格。
- 最糟糕的情况是，团队其他成员
git pull了这个被手动改坏的 lock 文件后，运行install会安装出完全不同的vendor目录，彻底破坏环境的一致性。
如果真的需要重新生成 lock 文件，请使用正确的命令：composer update --lock。这个命令只会根据当前已安装的依赖状态，安全地重建 lock 快照，而不会去触碰和更新 vendor 目录里的具体包。除此之外的任何手动方式，都是在赌运气，后果难料。
