生产环境必须用 composer install --no-dev --no-scripts --optimize-autoloader --no-interaction；禁用 dev 依赖、脚本、启用优化自动加载，且绝不使用 update。
Composer 在生产环境部署时，默认行为会拖慢速度、暴露敏感信息、增加包体积。直接运行 composer install 而不做任何优化，几乎必然导致构建失败或启动变慢。
如何跳过开发依赖并禁用脚本执行
生产环境不需要 require-dev 中的测试、调试、代码质量工具（如 phpunit、phpstan），也不该自动触发 post-install-cmd 等脚本——它们可能调用本地命令、生成缓存、甚至连接开发数据库。
- 必须加
--no-dev：跳过所有开发依赖的安装与 autoload 生成 - 必须加
--no-scripts：阻止post-install-cmd、pre-autoload-dump等钩子执行 - 推荐加
--optimize-autoloader（简写-o）：生成扁平化classmap，显著提升类加载性能 - 若已确认
composer.lock存在且可信，显式加--no-interaction避免卡住
composer install --no-dev --no-scripts --optimize-autoloader --no-interaction
为什么不能用 composer update 上生产
composer update 会忽略 composer.lock，重新解析依赖树、拉取最新兼容版本——这在生产环境是高危操作：可能引入不兼容变更、未测试的补丁、甚至恶意包（尤其当仓库配置了非官方源）。
- 生产部署唯一可信依据是
composer.lock，它锁定每个包的确切版本和哈希值 -
composer install才是「按锁文件还原」的命令；update只应在开发机上运行，并提交更新后的lock文件 - CI/CD 流水线中若误写成
update，会导致不同环境间行为不一致，极难排查
如何减小最终部署包体积
vendor 目录常占数 MB 到上百 MB，其中大量是文档、测试用例、.git 目录、markdown 文件等非运行必需内容。
- 部署前运行
composer install后，用find vendor -name '.git' -type d -prune -exec rm -rf {} +清理 Git 元数据 - 删除所有
*.md、*.txt、tests/、Tests/、test/目录（注意别误删phpunit.xml若需运行测试） - 更稳妥的做法是使用
composer install后配合rm -rf vendor/*/tests vendor/*/Tests vendor/*/test - 若用 Docker，可在
Dockerfile的最后阶段 COPY vendor 并清理，避免中间层残留
常见报错与绕过方式
部署时最常遇到的是权限不足、内存溢出、网络超时，而非语法错误。
-
PHP Fatal error: Allowed memory size of ... exhausted：在命令前加php -d memory_limit=-1，例如php -d memory_limit=-1 composer install --no-dev --no-scripts -o
-
Could not fetch https://repo.packagist.org/packages.json：检查是否误配了国内镜像但 DNS 解析失败，临时换回官方源：composer config --global repo.packagist composer https://packagist.org -
Class XXX not found：90% 是没加--optimize-autoloader或漏了--no-dev导致 autoloader 未正确生成
真正关键的不是记全命令，而是理解每项开关背后影响的是哪一层：依赖图、自动加载、脚本生命周期、磁盘占用。漏掉任意一项，都可能让上线后第一分钟就出问题。
