autoload是生产环境必需的类加载路径，autoload-dev仅用于开发测试且上线时必须剥离；配错会导致部署臃肿、类冲突或安全风险。
autoload 是生产环境必须加载的类路径，autoload-dev 是开发测试专用、上线时应完全剥离的辅助代码。 配错或混用会导致部署包臃肿、类冲突、甚至安全风险。
autoload 和 autoload-dev 的实际作用边界
autoload 下配置的类（比如 App → src/）是应用启动和运行所依赖的骨架代码：控制器、模型、服务、中间件等。只要 PHP 进程跑起来，这些类就可能被加载。
autoload-dev 下配置的（比如 Tests → tests/，PhpCsFixerFixer → tools/php-cs-fixer/src/Fixer/）只在本地执行 phpunit、phpcs、phpstan 或调试时才需要。它们不参与 HTTP 请求生命周期。
- 运行
composer install --no-dev时，autoload-dev的映射根本不会写入vendor/autoload.php - 即使你手动 require 了
vendor/autoload.php，autoload-dev中的类在生产环境也无法被自动加载（除非你额外 require 了对应文件） - 误把测试工具类放进
autoload，可能导致生产环境意外加载phpunit依赖，引发 Fatal error 或暴露调试接口
为什么改了 composer.json 后类还是找不到？
因为 Composer 不会监听文件变化——它只信任 vendor/autoload.php 里已生成的映射表。你改完 autoload 或 autoload-dev 字段后，必须显式执行：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
composer dump-autoload
这个命令会重写 vendor/composer/autoload_psr4.php 等底层文件。常见疏漏：
- 只改了
composer.json却忘了运行该命令 - 在 CI/CD 流水线中用了
composer install --no-dev，但本地开发又依赖autoload-dev里的类，结果测试跑不通 - 路径末尾少了斜杠：
"App\": "src"❌ 应为"App\": "src/"✅（注意命名空间结尾的双反斜杠和路径结尾的单斜杠都不可省）
dump-autoload -o 和 -a 参数对 autoload-dev 有影响吗？
没有直接影响。-o（optimize）和 -a（optimize-class-map）只扫描当前项目 + vendor/ 下所有 PHP 文件，生成完整类名到路径的映射表，用于加速加载。它们不区分 autoload 和 autoload-dev 的配置来源。
但要注意：
-
composer install --no-dev后再跑composer dump-autoload -o，生成的 classmap 里不会包含autoload-dev路径下的类 - 如果你在
autoload-dev里配了非 PSR-4 结构的类（比如扁平目录下放一堆*Test.php），仅靠 PSR-4 映射找不到，就得靠-a扫描生成 classmap 才能加载成功 -
-o在生产环境推荐启用；-a更适合处理遗留代码或工具类，但会略微增加vendor/autoload.php初始化耗时
最易被忽略的一点：autoload-dev 不是“可有可无的配置项”，而是部署安全的开关。哪怕只是多加载一个 var_dump() 辅助类，也可能让生产日志泄露敏感结构。别让它出现在 composer install --no-dev 后的最终产物里。
