必须提交 composer.lock 并统一平台约束、自动化校验，否则环境看似一致实则随时崩溃；因未提交 lock 时 install 会退化为 update，PHP 版本或扩展差异导致依赖解析结果漂移，CI 若误用 update 更会彻底破坏一致性。
只靠 composer install 不够，必须配合 composer.lock 提交 + 统一平台约束 + 自动化校验，否则环境“看似一致”，实则随时崩。
为什么 composer install 在不同机器上会装出不同版本？
根本不是 Composer 本身“不靠谱”，而是有人偷偷改了环境或依赖声明，却没同步 composer.lock。常见触发点：
-
composer.json里写了"monolog/monolog": "^2.0"，但没提交更新后的composer.lock→ 每个人install时都会按当前 Packagist 最新版本解析，今天装 2.10.0，明天可能就变成 2.11.1 - 本地 PHP 是 8.2，CI 用的是 8.1，而
composer.json里只写了"php": "^8.1"→ Composer 会静默降级选择兼容的包版本（比如跳过某个只支持 8.2+ 的扩展），lock文件内容实际已漂移 - 有人在 CI 脚本里写了
composer update --no-interaction，还自以为“自动化”了 → 它会忽略lock，重算整个依赖树，线上跑的代码和本地开发根本不是同一套
如何让 composer.lock 真正锁死，不被意外改动？
不能靠口头提醒，得靠机制卡死。关键动作要落在配置和钩子上：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 在
composer.json的config段加"lock": true：启用后，只要composer.json和composer.lock的 hash 对不上（比如你加了新require却没update），composer install就直接报错退出，不给“侥幸安装”的机会 - Git 预提交钩子检查：
git status --porcelain | grep -q '^[AM] composer.json'成立时，再检查composer.lock是否有未暂存变更，有则拒绝提交 -
.gitattributes里加一行：composer.lock -diff -merge，让 Git 不显示它的 diff，也不尝试自动合并 —— 因为lock文件是完整图谱序列化结果，手动合并毫无意义
CI/CD 流水线里怎么验证 composer.lock 没过期？
别等上线才发现问题。构建第一步就该做机器可判的校验：
- 先运行
composer install --no-interaction --prefer-dist - 紧接着执行：
git status --porcelain composer.lock - 如果输出非空（即
lock被改了），立刻失败并提示：“composer.json已变更，请运行composer update并提交新composer.lock” - 这条命令必须放在所有测试、打包步骤之前 —— 它不是锦上添花，而是构建可信的前提
Docker 环境下还要注意什么？
容器能封装 PHP 版本和扩展，但容易忽略两个隐性变量：
-
platform配置必须带小版本，例如"php": "8.1.10"，而不是"^8.1"或"8.1"。否则 Docker 构建时若用了php:8.1.15-cli镜像，Composer 可能因平台检测差异重新生成lock - 禁用
platform-check："platform-check": false。默认开启时，Composer 会读取运行时环境的真实扩展列表来决定哪些包可用 —— 这会让同一份lock在不同容器里“解释”出不同结果 - CI 中固定 Composer 版本，比如用
composer:v2.5.8镜像。Composer 2.2 和 2.5 对某些依赖冲突的解析策略不同，会导致lock内容不一致
真正难控的不是谁手抖点了 update，而是同一份 composer.lock 在不同 PHP 补丁版本、不同 Composer 解析器、不同扩展启用状态下，被“合法地”还原成不一样的依赖树 —— 这些细节不写进 CI 脚本、不固化进 Dockerfile，光靠人盯，迟早出事。
