Composer 生产部署怎么做？锁文件、平台要求与依赖安装
PHP 应用依赖能否稳定部署，关键在于代码、锁文件和运行环境是否对应。本文适用于 Composer 2 管理的可信项目，以及仍受维护的 PHP 环境。部署应在独立发布目录完成，不要直接在正在运行的业务目录里反复更新依赖。
把锁文件作为发布输入
composer.json 描述允许的依赖范围，composer.lock 记录已经解析出的具体版本。生产部署通常应携带经过测试的锁文件，并使用 install 还原对应依赖。缺少锁文件时，应先在开发或构建流程中解决，而不是让每台生产机自行选择不同版本。
update 会重新解析依赖并可能改变锁文件，不适合作为每次上线时顺手执行的步骤。依赖升级应有自己的审查和测试，再作为新版本发布。Composer 基本使用说明
还要确认锁文件与代码属于同一次发布，不能从旧分支拿一个锁文件拼到新代码上。将发布标识、锁文件校验值和运行版本记录下来，出现问题时更容易重建当时环境。
在受控目录安装生产依赖
以下命令在已准备好的新发布目录中，由有权写入该目录的部署账号逐条执行：
composer validate --strict
composer install --no-dev --prefer-dist --optimize-autoloader
composer check-platform-reqs --no-dev
校验失败时先处理配置与锁文件问题，不要跳过后直接上线。--no-dev 适用于运行时不需要开发依赖的交付方式；若构建前端、生成代码或编译资源需要开发工具，应在构建阶段完成，再交付所需产物。
优化自动加载有助于明确生产安装方式，但不能自动解决代码引用错误。安装参数与平台检查的具体含义可查Composer 命令手册。
平台检查不能靠忽略要求通过
确认 Composer 使用的 PHP 与应用生产环境兼容，尤其是 PHP 版本和扩展。CLI 检查通过而 FPM 使用另一套解释器时，网站仍可能失败。应把两者分别记录并验证，而不是只保存一次终端输出。
不要用忽略平台要求的参数来掩盖缺少扩展或版本不兼容。它可能让安装继续，却把失败推迟到用户请求发生时。锁文件里的平台模拟设置也不代表生产机器真的具备对应能力，实际平台检查仍然需要执行。
如果项目有私有依赖，凭据应由受控部署机制提供。不要把访问令牌写进公开仓库、命令历史或对外日志，也不要为了下载方便永久关闭 HTTPS 校验。
安装脚本与插件属于代码执行
Composer 安装可以触发项目脚本和被允许的插件。因此只在来源可信、已经审查的项目上执行，并使用权限受限的部署账号，不要习惯性以 root 身份安装所有依赖。
脚本可能连接数据库、清缓存或执行其他应用动作，正式部署前应读清项目的安装流程。测试新发布目录时，避免意外调用生产支付、邮件或重复任务。若禁用脚本用于诊断，还要明确之后哪些必要生成步骤尚未完成，不能把不完整目录当作发布成功。
验证应用，再切换发布目录
依赖安装完成后，检查入口文件、自动加载、应用配置和关键只读页面，再在隔离或受控环境验证必要业务流程。安装命令退出成功，只能说明该阶段结束，不能证明网站整体可用。
切换发布时保留上一版本目录、锁文件和依赖产物。若新代码失败且没有不兼容的数据变化，可以按既定发布方式恢复旧版本；若已执行数据库迁移，则先检查兼容性与回退方案。不要通过在生产目录连续运行 update 来修复一个本应可重复还原的发布。