不提交 composer.lock，团队环境就不可能一致；根本原因是缺失 lock 时 install 会退化为 update，按当前 packagist 状态、php 版本及扩展动态解析依赖，导致版本漂移。
不提交 composer.lock，团队环境就不可能一致——这不是风险提示，是确定性结论。
为什么 composer install 在不同机器上装出的包版本不同
根本原因不是 Composer 不可靠，而是 composer.lock 没被提交，或被意外忽略、删除、覆盖。一旦缺失 lock 文件，composer install 会退化为 composer update 行为：按当前 Packagist 状态 + 本地 PHP 版本 + 扩展可用性，重新解析整个依赖树。
- 今天装
monolog/monolog是 2.10.0，明天 CI 重跑可能变成 2.11.1（只要它发布了） - 本地 PHP 8.2 装了某个只支持 8.2+ 的包，CI 用 8.1 就静默跳过，
vendor/缺失关键类 -
composer.json里写了"php": "^8.1"，但没锁死具体小版本，lock 文件中 platform 字段实际记录的是 8.1.10 —— 某台机器是 8.1.5，composer install就会降级选择另一套兼容包
如何让 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却没运行composer 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 --dry-run：如果报错Your requirements could not be resolved to an installable set of packages，说明composer.json已被修改但composer.lock没同步更新 - CI 脚本开头加
ls -la composer.lock：防止因缓存或镜像同步延迟导致误用旧 lock - 强制指定平台版本：
composer install --platform=php:8.1.10：确保解析行为与 lock 文件生成时一致，绕过运行时 PHP 版本干扰
团队必须统一 composer 和 php 版本
只锁 Composer 大版本（如 2.5.x）不够，PHP 小版本差异一样会导致 lock 解析漂移：
-
composer.json中"config": {"platform": {"php": "8.1.10"}}是硬声明，但仅对当前 Composer 版本生效；若某台机器 PHP 是 8.1.5，而 lock 记录的是 8.1.10 下解析出的包（比如某包要求"php": "^8.1.10"），composer install会跳过它 - 项目根目录加
.composer-version文件，内容只写2.5.8；预提交钩子中用composer --version | grep -q "$(cat .composer-version)"校验 - CI 第一行必须显式执行
composer self-update 2.5.8，不能依赖系统预装版本；所有机器应通过包管理器或二进制分发渠道统一部署 PHP + Composer 组合
最隐蔽的坑不在命令记错，而在 composer.lock 被当成“生成物”对待——它和 composer.json 是平级源码，改它要走评审、测试、合入流程。漏一次提交，或某人手抖执行了 composer update，后面花半天排查“为什么本地能跑线上报错”，远比花三分钟确认 lock 是否已提交代价高得多。
