生产环境部署时必须加 --no-dev：ci/cd 打包、docker 构建、手动上线等所有生产部署场景均强制要求，否则会引入测试依赖、增大镜像体积、暴露安全风险；仅本地开发、ci 测试阶段不可加。
必须在生产环境部署时用，且只在部署阶段用——开发、测试、CI 构建中间步骤都不能省略它。
什么时候该加 --no-dev？
不是“可选优化”，而是生产环境 composer install 的强制前置条件。只要目标机器不跑测试、不写代码、不调试，就必须加。
- CI/CD 流水线打包镜像时：
composer install --no-dev --optimize-autoloader --classmap-authoritative --no-interaction --prefer-dist - Docker 构建阶段：RUN 命令里漏掉
--no-dev，镜像里就会多出 phpunit、symfony/debug-bundle 等 100MB+ 的无用文件 - 手动上线部署脚本：哪怕只是 scp 解压后执行一次
composer install，没加就等于把测试入口直接暴露给公网
什么时候不该加 --no-dev？
本地开发、CI 中的单元测试阶段、或需要运行 phpunit / phpstan / larastan 的环节，一定不能加。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 本地
composer install默认不加，是为了保证Tests类能被自动加载、服务提供者能注册成功 - CI 中跑测试前，必须先确保
require-dev包已安装，否则Class not found: TestsTestCase是必然结果 - 误在
composer update时加--no-dev，会导致composer.lock里删掉所有 dev 包版本记录，下次 CI 跑测试直接失败
--no-dev 不生效的常见假象
命令写了，但实际没起作用，往往是因为环境或上下文干扰。
-
COMPOSER_NO_DEV=1环境变量在 Composer 2.2+ 已废弃，CI 脚本里设了也白设 - 用了
composer dump-autoload -o替代composer install --no-dev：前者不跳过 dev 包安装，也不清理 autoload-dev 规则，classmap 里照样塞满Tests映射 - 先跑了
composer install（没加 --no-dev），再补composer install --no-dev：后者不会自动删掉之前装的 dev 包，得先rm -rf vendor再重装 - CI 中用了缓存 vendor/ 目录：缓存没区分 --no-dev 场景，导致旧的含 dev 包的 vendor 被复用
验证 --no-dev 是否真正生效
别信日志，看三处真实痕迹：
- 执行后检查
vendor/目录下是否还存在phpunit/phpunit、symfony/debug-bundle等包路径 - 打开
vendor/composer/autoload_static.php，搜索Tests\或Factories\，确认没有相关命名空间映射 - 部署后立刻运行：
php -r "require 'vendor/autoload.php'; var_dump(class_exists('Tests\Helper'));"，应返回bool(false)
最常被忽略的一点：--no-dev 只管“不装”，不管“不残留”。即使参数生效，vendor/ 里仍可能留着 vendor/bin/phpunit、vendor/*/tests/、vendor/composer/installed.json —— 这些必须靠后续清理步骤手动剔除，否则安全和体积问题照旧。
