composer install能真正锁定依赖，因为它跳过版本解析，仅按composer.lock中记录的精确版本、哈希和路径安装，不查源站、不运行求解器；缺失lock文件或其与composer.json不一致时会退化为update。
composer install 为什么能真正锁定依赖
因为 composer install 默认跳过所有版本解析逻辑，只读 composer.lock 中记录的精确 commit hash、包版本和安装路径，直接解压对应 zip 或 clone 指定 ref。它不查 packagist.org，不运行依赖求解器，也不生成新 lock —— 这才是“锁定”的本质行为。
常见错误现象：部署时 composer install 却触发了 Resolving dependencies 日志，说明它已退化为隐式 update；根本原因通常是 composer.lock 缺失、被 .gitignore 忽略，或 composer.json 与 lock 语义不一致（比如新增了 require 但没更新 lock）。
关键点在于：锁不是靠配置项“开启”的，而是靠文件存在 + 命令选择 + 环境匹配三者共同维持的。缺一不可。
--no-dev 不是保险丝，只是开关之一
--no-dev 的作用很明确：跳过 require-dev 和 autoload-dev，不装 phpunit、laravel/pint 这类包，也不注册它们的自动加载规则。但它完全不干预主依赖的解析逻辑。
容易踩的坑：
- 误以为加了
--no-dev就等于“锁死了”，结果服务器上composer.lock没提交，install仍会 fallback 到 update 行为 - 某些包（如
symfony/var-dumper）在 dev 模式下注册全局函数（dump()），上线后残留可能引发Function already defined -
--no-dev不影响 platform 检查 —— 如果 PHP 版本不匹配，照样报错退出，不会静默降级
PHP 版本变更会让 composer.lock 失效
Composer 2.0+ 默认校验 platform 配置（如 "php": "8.1.10"）。当生产服务器从 PHP 8.1 升级到 8.2，即使 composer.lock 文件本身没动，composer install 也会因平台约束不满足而拒绝执行，或触发重新解析（尤其加了 --ignore-platform-reqs 时）。
必须同步检查的三项：
-
composer.json中config.platform.php是否显式声明了目标 PHP 版本（推荐写死，如"8.2.12"） - 服务器实际 PHP 版本是否与 lock 文件里
platform字段完全一致（小版本也要对得上） - 所有声明的扩展（如
"ext-gd": "*"）是否已在服务器上启用，php -m可验证
如何验证部署时真的锁住了
别只看有没有报错。执行完 composer install --no-dev --optimize-autoloader --no-interaction 后，立刻检查这些信号：
- 运行
ls -l vendor/composer/installed.json：文件存在且内容是非空 JSON 数组，说明没 fallback；若为空或报No lock file found，说明已被降级 - 检查
vendor/autoload.php开头是否有类似if (!defined('COMPOSER_RUNTIME')) { die(''); }的平台检测逻辑（Composer 2.0+ 特征） - 翻部署日志，搜索
Resolving dependencies或Writing lock file：出现任一即表示解析被激活，必须回溯 CI 脚本或 Dockerfile - 设环境变量
COMPOSER_ALLOW_PLUGINS=0（Composer 2.2+）或COMPOSER_NO_PLUGIN=1（旧版），防插件绕过命令行参数
最常被忽略的是 PHP 版本变更后的 lock 失效问题——文件还在，内容也对，但 platform 不匹配，Composer 就会悄悄放弃锁定逻辑。这不是 bug，是设计使然。
