Hyperf 3.0 注解处理极快，因弃用运行时 PHPDoc 解析，改用 PHP 8 原生 Attribute——词法分析阶段即完成元数据提取，启动时仅数组索引与实例化，无文件 IO 和反射扫描，实测启动耗时从 1200–1600ms 降至 350–450ms。
Hyperf 3.0 的注解处理比 2.2 快得多，不是“略快”，而是启动阶段几乎不花时间——因为 AnnotationScanner 在 v3.0 里基本不干活了。
为什么 v3.0 启动快：编译期处理取代运行时扫描
v2.2 每次启动都要用 BetterReflection 或子进程全量解析 PHPDoc，读文件、正则匹配、AST 构建、缓存写入，耗时集中在 runtime/container/proxy/*.cache 生成；v3.0 直接调用 ReflectionClass::getAttributes()，PHP 解析器在词法分析阶段就完成了元数据提取，框架只做数组索引和实例化。
- v2.2 启动时若
runtime/container/proxy/缺失，会触发不可控的全量扫描，100 个控制器可能多耗 800ms+ - v3.0 即使清空
runtime/container/，只要SCAN_CACHEABLE=true，容器定义直接从config/autoload/*.php加载，无 IO 开销 - 实测相同项目（200+ 控制器），v2.2 启动耗时约 1200–1600ms，v3.0 稳定在 350–450ms，其中注解相关逻辑占比从 ~60% 降到
性能差异最明显的三个场景
不是所有地方都提速，关键看是否触碰反射和缓存链路：
- 首次启动（无缓存）：v2.2 要扫所有类并写 .cache 文件；v3.0 仅加载已注册的 config 数组，快 3 倍以上
-
修改注解后重启：v2.2 必须删
runtime/container/proxy/才生效，否则旧缓存残留；v3.0 改完代码即生效（SCAN_CACHEABLE=false时也只多一次getAttributes()调用） - CI/CD 构建环境：v2.2 在无 opcache 的容器里反复扫描，容易超时；v3.0 依赖 opcache 但不依赖其注解缓存机制，构建更稳定
别被“快”骗了：你得关掉旧扫描逻辑
v3.0 的性能优势不会自动生效。如果还留着 config/autoload/annotations.php 里的 Doctrine 配置、或手动调用了 AnnotationScanner::scan()，反而会引入冗余反射调用，甚至报 Class "DoctrineCommonAnnotationsAnnotationRegistry" not found。
- 确认
config/autoload/annotations.php中没有'loader' => 'doctrine'或'ignore_annotations' => ['@Inject']这类 v2.x 风格配置 - 检查是否有自定义 Command 或中间件仍试图调用
Doctrine\Common\Annotations\Reader - 用
strace -e trace=stat,openat php bin/hyperf.php start 2>&1 | grep -i 'annotation\|attribute'验证：v3.0 启动时不应出现对vendor/doctrine/annotations/的任何访问
真正影响上线速度的，往往不是单次请求的微秒级差异，而是启动时要不要等那几百毫秒的扫描——尤其在 K8s 滚动更新、Serverless 冷启、CI 并行测试这些场景下，v3.0 的 Attributes 是确定性优化，不是锦上添花。
