composer install能真正锁定依赖，因为它跳过版本解析，仅按composer.lock中记录的精确commit hash、版本和路径安装，不查源站、不运行求解器、不生成新lock；缺失lock或其与composer.json不一致时会退化为update。

composer install 为什么能真正锁定依赖

因为 composer install 默认跳过所有版本解析逻辑，只读取 composer.lock 中记录的精确 commit hash、包版本和安装路径，直接解压对应 zip 或 clone 指定 ref。它不查 packagist.org，不运行依赖求解器，也不生成新 lock 文件——这才是“锁定”的本质行为。

常见错误现象：部署时 composer install 却触发了 Resolving dependencies 日志，说明它已退化为隐式 composer update；根本原因通常是 composer.lock 缺失、被 .gitignore 忽略，或 composer.json 与 lock 语义不一致（比如新增了 require 但没更新 lock）。

关键点在于：锁不是靠配置项“开启”的，而是靠文件存在 + 命令选择 + 环境匹配三者共同维持的。缺一不可。

为什么加了 --no-dev 还会漂移

--no-dev 的作用很明确：跳过 require-dev 和 autoload-dev，不装 phpunit、laravel/pint 这类包，也不注册它们的自动加载规则。但它完全不干预主依赖的解析逻辑。

PHP 8.5.5

PHP 8.5.5 是 PHP 8.5 分支的维护更新版本。该版本延续了“小步快跑”的迭代逻辑，通过深度错误修复、底层性能微调以及安全加固，旨在为开发者提供一个更健壮、更高效的运行环境。该版本严格遵守语义化版本规范，不包含破坏性变更。

下载

• 误以为加了 --no-dev 就等于“锁死了”，结果服务器上 composer.lock 没提交，install 仍会 fallback 到 update 行为
• 某些包（如 symfony/var-dumper）在 dev 模式下注册全局函数（dump()），上线后残留可能引发 Function already defined
• --no-dev 不影响 platform 检查 —— 如果 PHP 版本不匹配，照样报错退出，不会静默降级

如何验证部署时真的锁住了

别只看有没有报错。执行完 composer install --no-dev --optimize-autoloader --no-interaction 后，立刻检查这些信号：

• 运行 ls -l vendor/composer/installed.json：文件存在且内容是非空 JSON 数组，说明没 fallback
• 检查日志是否出现 Resolving dependencies 或 Writing lock file —— 出现即表示 lock 失效，已退化为 update
• 对比本地和线上 vendor/ 目录下同一包的 composer.json 内容，确认版本号、dist.reference 和 dist.shasum 完全一致

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 可验证

最常被忽略的是 platform 和扩展一致性——很多团队在本地 PHP 8.2 开发，却往 PHP 8.1 的生产机部署，lock 文件里记录的包版本可能根本不存在于 8.1 的 Packagist 元数据中，结果就是安装中断，而不是降级兼容。