是，必须加classmap且仅限app/目录；需在composer.json中显式声明"classmap": ["app/"]，再执行composer install --no-dev --optimize-autoloader --classmap-authoritative，否则autoload_classmap.php不生成或无效，启动时仍反复stat文件。
Hyperf生产环境启动慢，是不是该加 classmap？
不是“加不加”的问题，而是必须加——但只加 app/，别乱塞。Hyperf 默认用 PSR-4 加载控制器、服务、命令等，开发时灵活，但生产环境下每次 new 类都要拼路径 + stat 文件，冷启动卡顿就出在这儿。composer.json 里 "autoload": { "psr-4": { "App\": "app/" } } 是基础，但光靠它不够。
真正起效的是显式声明 "classmap": ["app/"]，让 Composer 把 app/ 下所有类硬编码进 vendor/composer/autoload_classmap.php。注意：config/ 和 runtime/container/ 可选，仅当你启用了配置预加载或容器预编译时才加；加了但没用上，反而拖慢 dump-autoload 扫描速度。
-
app/是必须项：漏掉它，AppHttpControllersHomeController这类核心类就不会进 classmap，优化等于白做 - 别把
vendor/目录塞进 classmap：Composer 已为每个包建好映射，重复扫描只会让dump-autoload -o变慢 - 检查生成结果：运行后打开
vendor/composer/autoload_classmap.php，搜索App\，确认有真实类名和对应路径，而非空数组
composer dump-autoload -o 在 Hyperf 里为什么没反应？
因为默认不生成 classmap 文件，只刷新 PSR-4 映射表。Hyperf 启动慢的根因是运行时反复调用 file_exists() 查找类文件，而 dump-autoload 不加 -o 就不会触发全量扫描，autoload_classmap.php 仍是空的或只有几 KB。
正确做法是：先确保 composer.json 里有 "classmap": ["app/"]，再执行 composer dump-autoload -o（不是 install 或 update）。如果仍无效，大概率是以下之一：
- 没加
-o参数：composer dump-autoload默认行为完全不碰 classmap - 路径写错：比如写成
"app"缺少末尾斜杠，Composer 会跳过整个目录 - 用了 symlink 或未提交的临时路径：
composer dump-autoload -vvv会提示 “skipping”，但不报错 - CI/CD 中漏掉了
-o：很多流水线脚本只跑composer install --no-dev，没加--optimize-autoloader
Hyperf 部署时该用 install 还是 dump-autoload？
生产部署必须用 composer install --no-dev --optimize-autoloader --classmap-authoritative，而不是分步跑 dump-autoload -o。原因很实际：install 阶段才会真正写入 autoload_classmap.php，而 dump-autoload -o 在 Composer 2.9.6 下默认只刷新 autoload_static.php，不重建 classmap。
--classmap-authoritative 是关键开关：它告诉 Autoloader “只信这张表，别再 runtime 扫目录了”。没有它，即使 autoload_classmap.php 存在，Hyperf 启动时仍会 fallback 到 PSR-4 查找逻辑，strace -e trace=openat php bin/hyperf.php start 里还能看到大量 .php 文件被 open。
-
--no-dev必须加：否则tests/、examples/下的类会被扫进 classmap，体积暴涨（常达 2–5 MB），PHP-FPM 每次请求都要反序列化无用数据 - 别信镜像源能提速 autoload：阿里云、腾讯云镜像只加速包下载，不影响 classmap 生成逻辑
- 验证是否生效：删掉一个已映射的控制器文件，再启动 Hyperf —— 如果报
Class not found，说明--classmap-authoritative生效了；如果还能启动，说明 fallback 还开着
APCu 缓存 classmap 后还是慢，问题出在哪？
classmap 本身是 O(1) 数组查找，瓶颈不在 PHP 层。APCu 缓存没提速，通常是因为缓存根本没命中，或者被错误配置绕过了。
Hyperf 默认不启用 APCu autoloader 缓存，得手动加参数或代码干预。最稳妥的方式是在部署时用 composer install --apcu-autoloader，它会把 autoloader 实例（含 classmap）存进 APCu 共享内存。但前提是：
-
apc.enabled = 1且apc.stat = 0：否则每次 require 都会 stat 文件，废掉 classmap 优势 -
apc.shm_size足够大：classmap 数组过大（比如超 5000 个类）可能触发 APCu 逐出，建议设为128M - Hyperf 启动前没调用
ClassLoader::addPsr4()或动态注册 autoload 规则：这些操作会让权威模式退化，回到 runtime 查找
真正容易被忽略的是：APCu 缓存的是 autoloader 实例，不是 autoload_classmap.php 文件本身。如果项目里存在多个 require 'vendor/autoload.php' 调用，或框架在子进程中重新加载 autoload，APCu 缓存可能无法复用。
