--no-dev是生产环境部署强制前提，否则vendor体积膨胀、安全隐患加剧、autoload性能下降；它跳过require-dev包安装及autoload-dev映射，导致测试类等未加载而引发Class not found。
--no-dev 不是“可选优化”，而是生产环境部署的强制前提；不加它，vendor 目录体积、安全隐患、autoload 性能三者全崩。
为什么 --no-dev 会导致 Class not found？
常见错误不是参数没生效，而是误以为 --no-dev 只删包——它实际会跳过整个 autoload-dev 块，连带把测试类、假数据工厂、调试服务提供者等注册规则一并剔除。一旦代码里写了 new TestsHelpersStub() 或在 AppServiceProvider::boot() 中绑定了只存在于 dev 包里的接口实现，就会直接报错。
- 检查
composer.json是否含"autoload-dev": {"psr-4": {"Tests\": "tests/"}}—— 如果有，且没加--no-dev，这些路径会进autoload_classmap.php，白占内存 - 运行
composer install --no-dev后，确认vendor/composer/autoload_static.php里没有Tests\开头的映射项 - 若仍报错，用
grep -r "Tests\\Helper" vendor/composer/看是否残留了未清理的 autoload 规则
--no-dev 和 autoload_classmap.php 的真实关系
--no-dev 不生成 classmap，但它决定 classmap 里“能塞什么”。所有被 require-dev 引入的包（如 phpunit、larastan）及其依赖，其 autoload 配置全部失效，自然也不会被扫描进 autoload_classmap.php。所以 classmap 文件体积变小，反序列化更快，更重要的是：它不再为根本不会部署的类预留空间。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 对比命令：
composer install --optimize-autoloadervscomposer install --no-dev --optimize-autoloader，后者生成的autoload_classmap.php通常小 30%～60% - classmap 越大，PHP 每次请求 require 它时解析开销越高；而实际单次请求用到的类往往不到总量的 5%
- 别信
"optimize-autoloader": true写在composer.json里就万事大吉——它只是默认开关，不触发任何实际动作
CI/CD 流水线里漏掉 --no-dev 的典型后果
本地开发能跑通，线上炸锅，90% 是因为 CI 脚本用了 composer install 而非 composer install --no-dev。这不是兼容性问题，是物理层面的缺失：dev 包根本没装，它的类文件压根不存在于 vendor/ 里。
- 现象：Laravel 报
Class AppProvidersTestHelperServiceProvider not found，但该类明明在app/Providers/下——其实是这个服务提供者只在某个require-dev包中注册，而那个包没装 - 验证方式：部署后立刻执行
ls -la vendor/phpunit，如果目录存在，说明--no-dev没生效 - CI 脚本里别依赖
COMPOSER_NO_DEV=1环境变量——它在 Composer 2.2+ 已被弃用，且容易被其他插件覆盖
真正要盯住的不是“有没有加参数”，而是 vendor/ 目录里有没有不该出现的东西。哪怕命令写对了，如果前一次部署残留了 vendor/bin/phpunit 或 vendor/symfony/debug-bundle，风险仍在。精简不是一步操作，而是每次部署都必须重校验的物理状态。
