composer.lock 不能简单 chmod 444，因 Composer install/update 会重写该文件，只读权限将导致“Permission denied”错误；应使用 git update-index --assume-unchanged 防误提交，部署时用 composer install --no-interaction 且确保锁文件已提交。
composer.lock 文件为什么不能简单 chmod 444
因为 Composer 在执行 install 或 update 时，会尝试重写 composer.lock；如果文件是只读的，它会直接报错退出，错误信息类似：file_put_contents(composer.lock): Failed to open stream: Permission denied。这不是“防护”，是阻断正常流程。
真正有效的只读防护：用 git update-index --assume-unchanged
前提是项目已用 Git 管理，且 composer.lock 已提交——这是最轻量、最可靠的方式，既不干扰 Composer 运行，又能防止误改被提交。
-
git update-index --assume-unchanged composer.lock：告诉 Git 忽略该文件的本地修改（包括内容变更、权限变更） - 后续
git status不再显示composer.lock的改动，git add -A也不会把它加进去 - 需要临时编辑时，运行
git update-index --no-assume-unchanged composer.lock恢复跟踪 - 该设置仅对当前工作区生效，不污染仓库或影响他人
CI/CD 或部署环境里怎么防写入
这类环境通常不需要运行 composer update，只应执行 composer install --no-interaction --prefer-dist，此时根本不需要写 composer.lock —— 它只是读取依据。
- 部署前确保
composer.lock已提交且内容稳定 - CI 脚本里避免出现
composer update，哪怕加了--dry-run也可能触发锁文件校验逻辑 - 如果用容器部署，可在
Dockerfile中设RUN chmod 444 /app/composer.lock，只要后续步骤不调用update就完全安全 - 注意：某些旧版 Composer（install 时仍会尝试 touch 锁文件，建议升级到 2.x
别碰 .gitattributes 或 umask 来硬锁
有人想用 .gitattributes 设 composer.lock merge=ours，或改系统 umask 让新建文件默认只读——这些都偏离目标，还可能引发 Git 合并冲突、权限继承异常等更难排查的问题。
-
merge=ours只影响合并策略，不阻止本地编辑或git add -
umask是全局进程级设置，会影响所有文件创建行为，CI 环境里尤其危险 - Composer 本身不提供“锁文件只读模式”配置项，官方也不建议干预其文件操作流程
真正的防护不在文件权限上，而在流程控制：谁有权限跑 update、什么时候允许改锁、Git 是否能拦住误提交——这些比 chmod 实在得多。
