hyperf启动class not found报错90%源于自动加载未生效，真正加速需组合使用composer install --no-dev --optimize-autoloader、--classmap-authoritative及opcache配置，缺一不可。
Hyperf 启动时的 Class not found 报错，90% 不是类丢了，而是自动加载没生效；dump-autoload 命令本身不提速，它只是刷新映射——真正影响启动速度的是是否生成 classmap、是否启用 authoritative 模式、以及 OPcache 是否配合到位。
dump-autoload 本身不改变运行时查找逻辑
执行 composer dump-autoload 只会重写 vendor/composer/autoload_psr4.php 和 autoload_static.php，但不会跳过文件系统查找。Hyperf 在 new 一个类时，仍要按 PSR-4 规则拼路径、调 file_exists()、做多次 stat() 系统调用——尤其在高并发下，这些 I/O 开销会被放大。
常见错误现象：dump-autoload 执行后报错消失，但启动时间没变，甚至更慢。这不是命令失效，而是你没触发真正的优化路径。
- 不加
-o：只更新命名空间映射，不生成autoload_classmap.php，类加载仍走动态拼接 - 加了
-o但冷启动更慢：说明生成了大体积autoload_classmap.php（比如 >2MB），PHP 每次都要反序列化整个数组，开销盖过了查找收益 - Hyperf 的
runtime/container/目录若没进 classmap，容器预编译就白做了——必须显式加入"classmap"配置再跑 install
Hyperf 生产环境真正有效的加速组合
Hyperf 是常驻内存的 Swoole 应用，启动阶段的类加载只发生一次，但这次加载决定了后续所有协程的类可用性。所以重点不是“每次请求都快”，而是“首次 require autoload.php 时尽可能少 IO、少判断”。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
正确做法是部署时用完整命令重建 classmap：
-
composer install --no-dev --optimize-autoloader：这是唯一能真正生成/更新autoload_classmap.php的方式；dump-autoload -o在 Composer 2.x 中已不重建 classmap，只是冗余刷新 - 确保
composer.json的"autoload"包含关键路径："app/"（必需）、"config/"、"runtime/container/"（可选但推荐） - 加
--classmap-authoritative后，Hyperf 会彻底跳过 fallback 查找——漏一个类就直接Class not found，不是 bug，是它在严格执行“只认 classmap”
容易被忽略的三个硬依赖点
即使 composer install -o -a 跑成功了，Hyperf 启动仍慢或报错，大概率卡在这三处：
-
opcache.revalidate_freq=0没配：OPcache 会每秒检查autoload_classmap.php时间戳，classmap 优化完全失效 -
namespace AppServices;写成namespace appservices;或namespace AppServices（缺末尾反斜杠）：PSR-4 扫描直接跳过该目录，类不会进 classmap - 手动调了
Loader::addNamespace('App', 'src/app/')这类逻辑：它会覆盖 Composer 的 PSR-4 映射，且不受--classmap-authoritative约束，导致加载路径混乱
Hyperf 启动加速不是靠多跑几次 dump-autoload，而是让 classmap 覆盖全部业务类 + 关闭 fallback + 锁死 OPcache 检查。漏掉任意一环，优化就变成幻觉。
