生产环境应运行 composer install --no-dev，跳过 require-dev 中的包（如 PHPUnit），减少体积、提升性能并规避风险；需确保 dev 依赖正确归类、清理 vendor、验证未安装 dev 包。
在生产环境中运行 composer install --no-dev 是标准做法，它能跳过 require-dev 区块中声明的包（如 PHPUnit、PHPStan、debug 工具等），减少部署体积、提升启动速度，并避免意外加载开发专用代码带来的安全或性能风险。
确认 composer.json 中 dev 依赖已正确归类
确保所有仅用于开发的包都放在 require-dev 下，而非 require。例如：
"require": {
"php": "^8.1",
"laravel/framework": "^10.0"
},
"require-dev": {
"phpunit/phpunit": "^10.0",
"spatie/laravel-ignition": "^2.0",
"laravel/pint": "^1.0"
}
如果某个包被误写在 require 里，即使加了 --no-dev 也会被安装。上线前建议用 composer show --dev 检查当前加载的 dev 包列表，再核对配置。
部署时务必使用 --no-dev 且不带 --ignore-platform-reqs
执行命令时要明确指定 --no-dev，并避免混用 --ignore-platform-reqs（除非你完全清楚后果）：
-
推荐命令：
composer install --no-dev --optimize-autoloader --no-interaction -
--optimize-autoloader生成更高效的 classmap，适合生产环境 -
--no-interaction防止因交互式提示卡住自动化流程 -
不要加
--ignore-platform-reqs：它会跳过 PHP 版本、扩展等检查，容易导致运行时报错
确保 vendor 目录干净，不残留 dev 包缓存
如果之前在本地或 CI 中运行过 composer install（未加 --no-dev），vendor 里可能已有 dev 包。直接部署会导致冗余甚至冲突。稳妥做法是：
- 在部署机器上先清空
vendor/和composer.lock（或确保 lock 文件来自生产构建环境） - 用完整、未修改的
composer.lock文件重新执行composer install --no-dev ... - CI/CD 流程中建议在独立环境（如 Docker 构建阶段）执行安装，再复制 vendor 到运行镜像
验证是否生效：检查 vendor/autoload.php 和实际文件
安装完成后可快速验证 dev 包是否真的没装：
- 查看
vendor/autoload.php是否引入了 dev 包的 autoload 配置（通常不会，但可 grep 确认） - 执行
ls vendor/ | grep -E "(phpunit|pint|ignition)"，应无输出 - 在应用中尝试
class_exists('PHPUnit\Framework\TestCase')，应返回false
基本上就这些。关键不是命令本身多难，而是整个流程中配置、清理、验证三步缺一不可。
