启用 -o（--optimize）后，composer 将类映射“拍平”为静态 classmap 数组，直接查数组跳过文件扫描，加载耗时从 10+ms 降至 0.2–0.5ms；但开发中新增/改名/删除类需手动重运行 dump-autoload -o 否则不生效，ci/cd 和生产环境必须启用，本地开发建议关闭。
dump-autoload -o 生成的不是普通 autoloader
加 -o（即 --optimize）后，Composer 不再依赖 PSR-4/PSR-0 的路径映射动态查找类，而是把所有类名到文件路径的映射“拍平”成一个巨大的 classmap 数组，直接写进 vendor/composer/autoload_classmap.php。这意味着 class_exists() 或 new SomeClass 时，PHP 直接查数组，跳过目录遍历和文件 stat，实测加载耗时从 10+ms 降到 0.2–0.5ms。
哪些场景下 -o 反而拖慢启动速度
优化后的 classmap 是静态快照，不感知开发中新增/改名/删掉的类。常见踩坑点：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 你在
app/Models/下新建了User.php，但没跑composer dump-autoload -o，类根本不会被加载——连Class not found都不会报，因为 autoloader 根本没注册它 - 你用
composer install时没带--optimize-autoloader（或-o），但项目里又写了require vendor/autoload.php，结果加载的是未优化版，白配了autoload-classmap - 某些 IDE 或调试工具（如 PHPStan、Psalm）依赖动态 autoload 机制扫描类，开启
-o后可能漏检新类
CI/CD 和生产环境必须用 -o，但本地开发建议关掉
生产环境类文件基本固定，-o 安全且收益明确；本地开发则频繁改类，推荐：
- 开发时只用
composer dump-autoload（无-o），靠 PSR-4 动态映射保证即时生效 - CI 流水线里，在
composer install后显式加--optimize-autoloader --no-dev - 如果用了 Laravel Mix 或其他构建工具，注意它们有时会触发 Composer 自动重载，导致
-o被悄悄覆盖
验证 classmap 是否生效的最快方法
别看文档或猜，直接检查生成文件和实际行为：
- 运行
composer dump-autoload -o后，打开vendor/composer/autoload_classmap.php，确认文件存在且内容是长数组（不是空或只有注释） - 在代码里加一句
var_dump(class_exists('App\Models\User'));，然后用php -d xdebug.mode=off your-script.php测执行时间，对比开/关-o的差异 - 如果
composer show --platform显示ext-opcache已启用，classmap 还能被 opcache 缓存，进一步减少磁盘 I/O
composer.json 里的 autoload 配置，也得手动再跑一次 dump-autoload -o，否则旧映射继续生效。
