composer install --no-dev 是唯一可靠方式，它跳过 require-dev 包的安装、不生成 autoload-dev 映射；--optimize-autoloader 仅优化加载，不能替代 --no-dev。
composer install --no-dev 是唯一可靠方式
加 --no-dev 才真正跳过 require-dev 里的包，不下载、不安装、不生成 autoload 映射。别信 --optimize-autoloader（即 -o）能代替它——那只是加速加载，phpunit、php-cs-fixer 照装不误。
常见错误现象：
-
Class 'PHPUnitFrameworkTestCase' not found→ 实际是装了 phpunit 却没加载成功，说明它被误装进生产环境 -
vendor/bin/psalm或vendor/bin/pint存在 → 这些本不该出现在线上服务器
注意：--production 和 --no-dev 完全等价，但 --prod 是无效参数，会报 Unrecognized option "--prod"。
为什么 --no-dev 有时“没用”？lock 文件可能已污染
--no-dev 不是万能开关，它依赖 composer.lock 里没有 packages-dev 记录。如果上次 composer update 没带 --no-dev，lock 文件就存了 dev 包信息，此时再跑 install --no-dev 会直接报错：dev dependencies not found。
实操建议：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 上线前，在干净环境（删掉
vendor/和composer.lock）执行：composer update --no-dev --lock，再提交 lock 文件 - CI/CD 脚本中加清理步骤：
git clean -xffd vendor/，再跑composer install --no-dev - 检查 lock 是否干净：
grep -q '"require-dev"' composer.lock && echo "warning" || echo "clean"
Docker 构建时 --no-dev 容易被缓存绕过
Docker 的 layer 缓存可能导致 RUN composer install --no-dev 复用旧的 vendor 层——里面其实混着 symfony/var-dumper 或 roave/security-advisories。
必须确保构建流程不复用污染层：
-
COPY composer.json composer.lock ./后立刻执行安装，中间不要加其他COPY - 推荐组合：
composer install --no-dev --optimize-autoloader --classmap-authoritative --no-scripts - 加
--no-scripts防止开发用的 post-install-cmd（比如 npm run build）在线上意外触发
autoload-dev 不随 --no-dev 自动清除
--no-dev 只控制「安装」，不删 autoload-dev 注册的路径。比如 "Tests\": "tests/" 还在 vendor/autoload.php 里，哪怕 tests/ 目录下没任何类，class_exists('TestsFooTest') 仍可能返回 true。
真正干净的做法：
- 把测试路径从
autoload移到autoload-dev，并确保它只在开发环境生效 - 上线后手动运行：
composer dump-autoload --no-dev，强制重生成 autoload，剔除 dev 路径 - 若项目用了
"psr-4": {"App\Tests\": "tests/"}，上线前得确认控制器或服务里没硬编码调用测试类
最常被忽略的一点：即使 --no-dev 成功执行，只要 autoload-dev 还在 composer.json 里，它的映射就还在 autoloader 中——这和是否安装包无关，只和 dump-autoload 时是否传参有关。
