生产环境必须用 composer install --no-dev --optimize-autoloader，而非 dump-autoload -o；后者在 php 7.4+ 和 composer 2.x 中默认不重建 autoload_classmap.php，仅刷新轻量映射，且在标准 psr-4 项目中无效甚至拖慢冷启动。

dump-autoload -o 在高并发场景下反而拖慢冷启动

别指望 composer dump-autoload -o 提升线上性能——它在 PHP 7.4+ 和 Composer 2.x 中默认不生成 vendor/composer/autoload_classmap.php，即使加了 -o，只要项目没显式配置 "classmap" 字段，该文件就为空或根本不存在。实测发现，执行后 memory_get_peak_usage() 在 autoload 阶段翻倍，strace 显示 stat() 调用没减少，但请求响应时间上升。

原因很直接：autoload_classmap.php 是一个全量数组，动辄几 MB；每次 PHP 请求都要完整 require 或反序列化它，而实际只用到其中不到 5% 的类。OPcache 对这种大体积、结构动态的数组缓存效率极低，冷启动时加载开销远超 PSR-4 动态查找收益。

• 检查是否生效：运行 ls -lh vendor/composer/autoload_classmap.php，大小为 0 或报 “No such file” → 没触发 classmap 重建
• 误配风险：若 composer.json 里写了 "tests/": ["tests/"] 这类路径进 autoload（而非 autoload-dev），-o 会把它扫进 classmap，徒增体积和错误概率
• 本地开发禁用：开了 -o 后，php artisan tinker 或临时类定义可能直接报 Class not found，掩盖真实命名空间拼写问题

真正起效的是 install --optimize-autoloader，不是 dump-autoload

composer install --optimize-autoloader（或简写 composer install -o）才是生产部署中必须跑的命令。它强制 Composer 重新解析所有 autoload 配置项（PSR-4、classmap、files），跳过 vendor 缓存逻辑，生成精简且准确的 autoload_classmap.php，并确保映射与当前代码严格一致。

关键点不在“有没有 -o”，而在“谁来触发重建”。dump-autoload -o 只刷新 autoload_static.php 和 PSR-4 映射表；只有 install 流程才会真正扫描源码、提取类名、写入 classmap。

• CI/CD 必须固化：composer install --no-dev --optimize-autoloader —— --no-dev 防止测试路径污染 classmap
• 验证是否生效：打开 vendor/composer/autoload_real.php，搜索 addClassMap；若该行被调用，说明 classmap 已加载
• 配置依赖：如果项目没声明 "classmap": ["src/"] 或使用 "files" 加载方式，install -o 也不会生成 classmap，得先清理 composer.json

--classmap-authoritative 不是提速开关，是断电式加载

--classmap-authoritative 的作用不是让 autoload 更快，而是让它更“绝”。开启后，自动加载器查不到 classmap 就直接报 Class not found，不再 fallback 到 PSR-4 拼路径、file_exists() 或目录遍历。这确实能省掉大量 stat()，但代价是零容错。

Discussion Composer

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

下载

它只在所有条件严苛满足时才安全：

• 所有命名空间末尾带反斜杠："App\": "app/"，不能写成 "App": "app/"
• 没有 "files" 类型加载（如全局 helper 函数），否则这些函数仍可加载，但容易误判问题根源
• 项目中无动态插件机制或运行时生成类的需求（比如某些 CMS 的模块热加载）
• 部署时已确保 --no-dev，避免 autoload-dev 规则泄漏进主 autoload

本地开发千万别开——IDE 补全、phpunit 临时类、tinker 交互式调试全会崩。

性能瓶颈往往藏在 composer.json 配置本身

比纠结参数更重要的是清理 autoload 配置。一个写错的前缀或一条冗余路径，会让 Composer 白扫几千个文件。

• 删掉无用条目："docs/": ["docs/"]、"resources/": ["resources/"]、"tests/": ["tests/"] 全部移出 autoload 块
• 避免宽泛前缀：""（空字符串）匹配所有命名空间，会触发全目录递归扫描；改用精确前缀如 "Legacy\": "legacy/src/"
• 检查重复注册：同一命名空间同时出现在 psr-4 和 classmap 中，Composer 会叠加处理，增加匹配耗时
• 第三方包“带毒”：运行 composer show --tree，找那些在 require-dev 里却声明了 autoload 的包（如旧版 phpunit 插件），它们的测试类可能被意外扫入主 autoload

autoload 性能从来不是靠加参数堆出来的，而是靠删、靠准、靠隔离。最常被忽略的一点：composer.json 里哪怕多写一个斜杠、少写一个反斜杠，都会让 classmap 扫描失败，而错误表现却是“类找不到”，不是“配置无效”。