生产环境部署必须加--no-dev，否则composer默认安装phpunit等dev包；它不识别app_env，只依据composer.lock和是否传参决定，未加参数即全量安装。
生产环境部署必须加 --no-dev
不加就一定会装 phpunit、php-cs-fixer、symfony/debug-bundle 这类包——不是“可能”，是 Composer 默认行为。它根本不看 APP_ENV=production 或服务器类型，只认两件事：composer.lock 里有没有 packages-dev，以及你有没有传 --no-dev。没传，它就全装。
CI/CD 和 Docker 构建里加了也未必生效
常见失效场景：Docker 缓存复用了上一轮带 dev 包的 vendor/ 层；CI 脚本没清 vendor 就直接跑 composer install --no-dev；composer.lock 本身是开发机生成的、已含 dev 依赖。结果就是命令看似成功，镜像里却悄悄混进 phpstan/phpstan 或 laravel/tinker。
- 每次构建前先
rm -rf vendor/，别信缓存 - CI 中加检查：
grep -q '"require-dev"' composer.lock && echo "lock is dirty" || echo "safe" - Dockerfile 里写成：
RUN rm -rf vendor/ && composer install --no-dev --prefer-dist --optimize-autoloader --no-scripts
--no-dev 不等于删 autoload-dev 映射
--no-dev 只跳过安装，不删自动加载规则。比如 "Tests\": "tests/" 还在 vendor/autoload.php 里，哪怕 phpunit 根本没下载，class_exists('Tests\FooTest') 仍可能返回 true（只要文件物理存在）。更危险的是：代码里硬写了 new Tests\FooTest()，上线就报错。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 若要彻底禁用测试类加载，得配合
composer dump-autoload --no-dev - 但注意：这不会删掉
autoload-dev配置本身，只是不把它们写进生成的 classmap - 真正安全的做法是——别在运行时代码里引用
Tests\下的类
--no-dev 和 --production 是一回事，但别输 --prod
--production 是 --no-dev 的别名，Composer 2.0+ 文档明确写了这点。但 --prod 这个缩写根本不存在，输进去会报 Unrecognized option: --prod。参数语义上，--no-dev 更直白，推荐日常和脚本中统一使用。
-
--no-dev：语义清晰，CI/CD 脚本首选 -
--production：兼容旧脚本可用，但没必要刻意替换 -
--prod：无效，会中断流程，别手滑
最常被忽略的一点：--no-dev 解决的是“装什么”，不是“用什么”。就算 vendor 里没 phpunit，只要你的控制器里调了 dump($data)，而 symfony/var-dumper 在 require-dev 里，线上照样崩——它已经不是开发依赖，而是运行时依赖了。
