生产环境必须禁用Composer动态解析，否则install会退化为隐式update，导致版本漂移、行为突变及安全漏洞；核心防护是确保composer.lock存在且语义一致、加--no-interaction --no-plugins参数、设COMPOSER_ALLOW_PLUGINS=0环境变量，并通过installed.json和日志验证是否真锁定。
生产环境必须禁用 Composer 的动态依赖解析能力，否则 composer install 会退化为隐式 composer update，导致版本漂移、行为突变甚至安全漏洞引入——这不是配置建议，而是部署红线。
为什么 --no-dev 不足以阻止动态解析
很多人误以为加了 --no-dev 就万事大吉，但实际风险藏在更底层：
-
composer.lock缺失或未提交时，composer install会自动 fallback 到版本解析逻辑，重新生成 lock 文件并拉取最新兼容版本（哪怕只是补丁级） - PHP 版本变更后，原有
composer.lock中的 platform 检查可能失效，触发重新解析（Composer 2.0+ 默认校验php平台约束） - 某些 CI 脚本用
composer install --ignore-platform-reqs绕过检查，等于主动关闭安全闸门
如何强制锁定解析行为
核心是让 Composer 在运行时彻底放弃“查版本→选版本→下载”的整套流程，只做“按 hash 解压 + 按 classmap 加载”两件事：
- 部署前确保
composer.lock已提交且与composer.json语义一致：运行composer validate --strict验证结构，再用git ls-files composer.lock | xargs git check-attr --stdin diff确认未被 git 忽略 - 部署命令必须显式带上
--no-interaction --no-plugins --no-scripts：其中--no-plugins是关键，它禁用所有插件（包括allow-plugins白名单外的），避免插件偷偷触发额外解析 - 设环境变量
COMPOSER_ALLOW_PLUGINS=0（Composer 2.2+）或COMPOSER_NO_PLUGIN=1（旧版），双重保险防止插件绕过命令行参数
验证是否真锁住了
执行完 composer install 后，立刻检查几个信号点，别只看有没有报错：
- 运行
ls -l vendor/composer/installed.json：如果文件存在且内容包含完整包列表（非空数组），说明没 fallback；若为空或报 “No lock file found”，说明已被降级为 update 行为 - 检查
vendor/autoload.php开头是否有if (!defined('COMPOSER_RUNTIME')) { die('...');类似平台检测逻辑（Composer 2.0+ 特征），没有则可能用了降级版 autoloader - 在部署日志里搜索
Resolving dependencies或Writing lock file：出现任一即表示解析被激活，必须回溯 CI 脚本或 Dockerfile
最常被忽略的是 PHP 版本变更后的 lock 失效问题——哪怕 composer.lock 文件本身没动，只要服务器 PHP 从 8.1 升到 8.2，某些包的 platform 约束就可能不匹配，触发静默重解析。上线前务必用目标环境 PHP 版本跑一次 composer install --dry-run 预检。
