生产环境报错大概率是composer“静默更新”所致：当composer.lock缺失、被忽略或与composer.json不一致，或php平台版本不匹配、dev依赖残留时，composer install会退化为update行为。
生产环境突然报错，但没动过代码、没跑过 composer update，大概率是 Composer 的“静默更新”机制在作祟——它根本不是自动升级，而是你漏掉了某个关键文件或配置，导致 composer install 实际退化为 composer update 行为。
composer install 为什么悄悄变成了 update
只要 composer.lock 缺失、被 .gitignore 拦截、或与 composer.json 语义不一致，composer install 就会放弃锁定逻辑，回退为全量依赖求解。这不是 bug，是设计行为。
-
composer.lock文件未提交到 Git：CI 构建时从空目录开始，自然没有 lock 文件 -
.gitignore里写了/vendor却误加了/composer.lock（常见手误） -
composer.json新增了"require": {"foo/bar": "^2.0"}，但没运行composer update更新 lock，install 时直接跳过该包，还可能报Package foo/bar is not installed - 团队成员本地改了
composer.json后直接git commit -am "fix"，忘了composer update和提交 lock
PHP 平台版本不匹配触发隐式重解析
即使 composer.lock 完好，只要服务器 PHP 版本和 lock 文件中记录的 platform 字段不一致，Composer 就会拒绝安装，并尝试重新求解——此时你看到的 Resolving dependencies... 日志，就是静默 fallback 的铁证。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 检查 lock 文件里的
platform.php值：jq -r '.platform.php' composer.lock - 对比当前 PHP 版本：
php -v | head -n1 | cut -d' ' -f2 - 小版本必须完全一致（如
8.1.10≠8.1.9），否则 Composer 2.0+ 默认中断安装 -
--ignore-platform-reqs是临时绕过手段，但上线前务必同步composer.json中的"config": {"platform": {"php": "8.1.10"}}
dev 依赖残留引发运行时冲突
--no-dev 只控制安装阶段是否加载 require-dev，它不清理已存在的 dev 包，也不阻止它们注册的全局函数或扩展在运行时生效。
- 上线后出现
Function already defined: dump()？说明symfony/var-dumper虽没装进vendor/，但它的 autoloader 仍被某处require或旧缓存加载了 -
vendor/composer/autoload_files.php里若残留 dev 包的引导文件路径，就会在autoload.php初始化时执行 - 验证方式：部署后运行
php -d display_errors=1 -d error_reporting=-1 artisan tinker，再输入dump(1)看是否报错 - 根治方法：确保 CI 流程中用
composer install --no-dev --optimize-autoloader --no-interaction，且vendor/目录完全重建（非增量更新）
如何确认故障是否由静默更新引起
别只看日志有没有报错，要抓三个硬信号：
- 执行完
composer install后，立刻检查ls -l vendor/composer/installed.json—— 如果文件大小为 0 或内容为空数组，说明安装过程异常中断或退化为 update - 对比线上
vendor/composer/installed.json和上一次稳定版本的 diff，重点看name+version字段变动，尤其注意symfony/*、psr/*、monolog/monolog这类高频变动包 - 运行
composer show --tree | head -20，观察顶层包下挂的子依赖版本是否与 lock 文件中记录的一致；若树中出现dev-main或9999999-dev，基本可断定 lock 失效
静默更新从来不是 Composer 在偷偷做事，而是你在某个环节松开了对 composer.lock、platform、--no-dev 三者的协同控制——漏掉任意一环，它就按最宽松的路径走，而生产环境恰恰不能容忍这种“宽松”。
