composer install在CI中“假装成功”是因为它只校验composer.lock是否存在且可解析，不验证锁内版本是否仍满足composer.json当前约束；需用composer update --dry-run检测兼容性，退出码非0即表示约束失效。
为什么 composer install 在 CI 里会“假装成功”
CI 流程中执行 composer install 后没报错，但实际依赖版本可能已偏离 composer.json 中的约束（比如用了 ^2.0 却装了 2.99.0，而该版本其实已被标记为 abandoned 或存在已知安全漏洞）。根本原因在于：默认行为只校验 composer.lock 是否存在且可解析，不验证其中每个包是否仍满足 composer.json 的当前约束条件。
真正要检测的是「锁文件是否仍由当前 composer.json 合法生成」——这得靠 composer update --dry-run。
-
--dry-run不改任何文件，只模拟更新并报告冲突 - 只要输出中出现
Would update或Root package requires类错误，就说明约束已失效 - 注意：必须搭配
--no-interaction --no-progress --ansi避免 CI 卡住或输出干扰
如何用 composer update --dry-run 做可靠验证
直接在 CI 脚本中运行以下命令即可捕获不一致：
composer update --dry-run --no-interaction --no-progress --ansi --quiet
关键点：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 必须保留
--quiet：否则大量Lock file operations日志会淹没真实错误 - 退出码为
0表示完全兼容；非0表示约束冲突（如某包在composer.json中要求"monolog/monolog": "^1.0"，但 lock 里是2.10.0） - 若项目使用
platform-check（如指定 PHP 版本），需额外加--with-all-dependencies确保平台约束也被检查
绕过 composer.lock 被意外修改的风险
CI 中常见误操作：开发者提交了过期的 composer.lock，或 CI 自动执行了 composer install 后又写回仓库。这类情况会导致 --dry-run 验证失效（因为锁文件本身已是“合法但过时”的状态）。
防御措施：
- CI 开始前强制重置 lock：
git checkout -- composer.lock（前提是 lock 文件已提交） - 或更严格：删掉 lock 再验证：
rm -f composer.lock && composer update --dry-run ... - 配合 Git 检查：用
git status --porcelain composer.lock确认 CI 运行期间 lock 未被修改
PHP 版本与平台配置对验证结果的影响
composer update --dry-run 的结果高度依赖当前运行环境的 PHP 版本和 config.platform 设置。例如：
- 本地开发用 PHP 8.2，CI 用 PHP 8.1，而某依赖声明
"php": "^8.2"→ CI 上--dry-run会失败 -
config.platform.php设为"8.1"可屏蔽此差异，但会掩盖真实兼容性问题 - 推荐做法：CI 使用与生产一致的 PHP 版本，并**不设置**
platform，让验证反映真实部署约束
复杂点在于：你得确保 CI 的 PHP 版本、扩展（如 ext-mbstring）、甚至 COMPOSER_NO_INTERACTION 环境变量都和上线环境一致——否则验证通过也不代表能跑通。
