单独执行 composer dump-autoload -o 在 PHP 7.4+ 和 Composer 2.x 下是假优化：它不重建 classmap，仅刷新轻量映射，且生成的全量 autoload_classmap.php 每次请求需反序列化数 MB 数据，实际仅用不到 5% 类；真优化命令是 composer install --no-dev --optimize-autoloader，它强制全量扫描并生成精简 classmap。
单独执行 composer dump-autoload -o 在现代 PHP 环境（PHP 7.4+、Composer 2.x）中不仅不减少 IO 开销，反而可能增加冷启动时的文件加载压力——它生成的 autoload_classmap.php 是一个全量反序列化数组，每次请求都得完整载入数 MB 数据，而实际只用到其中不到 5% 的类。
为什么 dump-autoload -o 在生产环境是假优化
这个命令不会重建 classmap，只是“刷新”已有映射；它不扫描 vendor 或项目源码，也不清理 dev 目录内容。真正触发 classmap 全量重建的，只有 composer install 或 composer update 阶段。
- 执行后检查
vendor/composer/autoload_classmap.php：若文件不存在、为空或只有几十行，说明根本没生效 - 即使文件存在，若
composer.json中未显式声明"classmap"字段，Composer 2.x 会跳过 classmap 扫描逻辑，-o只是空转 -
dump-autoload -o不受"optimize-autoloader": true配置影响——该配置只对install命令起作用
真正在生产环境减少 IO 的命令是 composer install --no-dev --optimize-autoloader
这条命令强制 Composer 重新解析所有 require 包（排除 require-dev），并基于当前 autoload 配置生成精简、准确的 classmap。它才是 CI/CD 部署脚本里必须写死的那条。
-
--no-dev确保autoload-dev中的路径（如"tests/": ["tests/"]）不被扫进主 classmap，避免体积膨胀和误加载 -
--optimize-autoloader触发 classmap 全量扫描 +autoload_static.php更新，且默认启用--classmap-authoritative行为（在 Composer 2.2+） - 生成的
autoload_classmap.php内容应远超千行，且只包含生产必需类；对比开发机输出，体积应小 30% 以上
--classmap-authoritative 不是加速开关，而是加载策略开关
加了它不代表变快，只代表“查不到就立刻报错，不 fallback”。它的价值在于消除运行时 file_exists() 和路径拼接开销，但前提是 classmap 必须完整覆盖所有运行时用到的类。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
立即学习“PHP免费学习笔记（深入）”；
- 报
Class not found？不是参数错了，是 classmap 漏类：常见于命名空间末尾少反斜杠（"App": "app/"→ 应为"App\": "app/"）、新增类文件但命名空间与目录结构不严格匹配（如namespace AppConsoleCommands;缺） -
"files"类型自动加载（如全局函数文件）不受该参数影响，仍会正常加载；但它不会进入 classmap，所以不能靠它“兜底” - 开了它之后，
class_exists('SomeClass', false)可能返回false（因未注册），而不再是触发 autoload —— 这会影响部分框架或工具的探测逻辑
OPcache 和 APCu 不是可选插件，是 classmap 生效的前提
没有 OPcache，autoload_classmap.php 每次请求都要重新解析；没有 APCu，--apcu 参数无效；两者都缺，classmap 优化等于白做。
- 确认 OPcache 启用：
php -i | grep opcache.enable输出应为opcache.enable => On，且opcache.revalidate_freq=0（否则每次请求仍 stat 文件） - 验证
vendor/autoload.php是否被缓存：执行php -r "require 'vendor/autoload.php';" && print_r(opcache_get_status()['scripts']['vendor/autoload.php']); -
--apcu仅在 APCu 扩展已启用、且apcu.enable_cli=1时才生效；部署后建议调用apcu_clear_cache('user')避免旧 classmap 缓存残留
最常被忽略的一点：classmap 性能收益只在高并发 Web 请求（PHP-FPM）中显著，在 CLI 场景（如 php artisan tinker）下几乎不可测；开发环境盲目开启 --classmap-authoritative，反而会让临时类、测试类、tinker 中的动态定义直接失败，掩盖真实问题。
