根本原因是composer.lock未提交或被忽略；composer install只按lock文件安装版本，不读取composer.json的版本约束，导致生产环境未使用预期依赖。
生产环境依赖包更新后行为不一致，根本原因不是没更新，而是更新记录没同步——composer.lock 文件没提交或被忽略。
为什么 composer install 不等于“用了最新依赖”
很多人误以为在生产环境跑 composer install 就能拉到 composer.json 里写的最新版本，其实完全相反：composer install 只认 composer.lock，哪怕 composer.json 里写着 "monolog/monolog": "^3.0"，只要锁文件里记的是 2.10.2，它就装 2.10.2。
这正是多环境一致性的基础，但也成了陷阱源头：
- 本地执行了
composer update monolog/monolog，但忘了git add composer.lock -
.gitignore里误加了composer.lock（极常见） - CI/CD 流水线用
composer install --no-interaction，却没校验锁文件是否存在或是否过期
如何验证当前环境的依赖记录是否真实可信
别只看 vendor/ 目录有没有某个包，要看这个包的版本是不是你“以为”的那个版本——且该版本是否被锁文件明确记录。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
执行以下检查：
- 运行
composer show monolog/monolog，确认输出的版本号与composer.lock中monolog/monolog条目下的version字段一致 - 对比
git status输出：如果composer.lock显示为 modified，说明本地已更新但未提交 - 在 CI/CD 脚本开头加一行：
test -f composer.lock || { echo "ERROR: composer.lock missing"; exit 1; }，防止漏锁文件导致 fallback 到解析composer.json
更新依赖时必须同步 commit 的三个硬性条件
只有同时满足这三条，才能说这次更新“可追溯、可复现、可回滚”：
-
composer update命令必须带具体包名（如composer update guzzlehttp/guzzle），禁止无参数全量更新，避免意外升级其他间接依赖 - 更新后立即执行
git diff composer.lock，确认变更仅涉及目标包及其直系依赖，没有波及无关项 -
git commit的 message 必须包含更新动机，例如：chore(deps): update guzzlehttp/guzzle from 7.5.0 to 7.8.1 for CVE-2026-1234 fix，而非笼统的 “update deps”
最常被跳过的环节是第二条：不检查 composer.lock 的 diff 就直接 commit，结果把一堆不该动的依赖版本也锁死了。一旦出问题，连“还原到上一个锁文件”都救不了——因为那个“上一个”本身就不干净。
