composer require --dev仅将包写入require-dev字段，不控制安装；生产环境必须显式执行composer install --no-dev才能跳过安装及autoload注册，否则dev包仍会进入vendor和autoloader导致报错。

composer require --dev 只改 composer.json 字段，不控制安装行为

加不加 --dev，只决定包写进 composer.json 的 require 还是 require-dev 字段，跟“是否在生产环境生效”完全无关。很多人以为 composer require --dev phpunit/phpunit 装完，线上就自动不加载——其实只要没加 --no-dev，它照样被装进 vendor/、照样进 autoloader、照样报错。

常见错误现象：

• composer require --dev phpunit/phpunit 后，Docker 构建只跑 composer install，结果镜像里多出 20MB 的 phpunit/ 和一堆 sebastian/ 目录
• 本地测试能跑通，CI 流水线却报 Class not found: PHPUnit\Framework\TestCase，其实是漏了 --dev 参数，根本没装进去
• 误写成 composer require-dev phpunit/phpunit（少空格、多连字符），Composer 当作普通包名处理，直接塞进 require，上线必炸

生产部署必须显式用 --no-dev，否则等于没分

composer install 默认行为就是装 require + require-dev 全部内容。它不看 APP_ENV=prod，不读主机名，也不查当前目录是不是 /var/www/html——只认命令参数。

正确做法是：

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

• Dockerfile 中固定写：RUN composer install --no-dev --optimize-autoloader --classmap-authoritative
• GitHub Actions / GitLab CI 构建生产镜像时，composer install 命令必须带 --no-dev，且缓存 key 要包含该标志，避免缓存复用导致 dev 包漏删或误留
• CI 测试阶段用完整安装：composer install && ./vendor/bin/phpunit；但构建产物那步，必须切回 --no-dev

autoload-dev 不是给 PHPUnit 用的，是给你自己的 tests/ 目录用的

autoload-dev 配置的作用，是在你本地执行了完整 composer install（即装了 require-dev）的前提下，把 tests/、stubs/ 这类路径也加进自动加载规则。它不是让 PHPUnit 自己能加载，而是让你写 use App\Tests\FooTest 时不报错。

关键点：

• 如果生产环境只跑 --no-dev，autoload-dev 里的 PSR-4 映射压根不会写入 vendor/autoload.php
• 如果你的测试类用了 mockery/mockery，除了把它放 require-dev，还得确保 autoload-dev 包含了 tests/ 目录，否则 new Mockery\LegacyMockInterface() 仍会找不到类
• composer dump-autoload --classmap-authoritative 在 --no-dev 下更关键：它会让 autoloader 完全跳过文件扫描，直接暴露那些“只在 dev autoloader 里注册、却被生产代码 new 出来的类”

验证 --no-dev 是否真生效，别只信配置

上线后最直接的验证方式，是进容器或部署目录看实际结果：

• 检查 vendor/ 目录：ls vendor/ | grep phpunit —— 输出非空说明 --no-dev 没起作用
• 检查 classmap：grep -n "PHPUnit" vendor/composer/autoload_classmap.php —— 有匹配说明 dev 包参与了 autoloader 构建
• 运行时验证：php -r "var_dump(class_exists('PHPUnit\Framework\TestCase'));" —— 生产环境必须返回 bool(false)
• 额外注意：vendor/autoload.php 是否被手动修改过？比如有人 hack 式追加了 dev 路径，这种操作在 --no-dev 下直接失效

真正容易被忽略的是：require-dev 的边界不是“我用不用”，而是“业务代码会不会在运行时 new 或 use 它”。哪怕只是临时在控制器里写了 dump()，而 symfony/var-dumper 又在 require-dev 里，上线后 --no-dev 就会立刻报错。