APP_DEBUG=true会拖垮生产响应速度：启用全量调试导致异常堆栈输出、请求头注入、模型关系强制加载等，每请求多执行数十次反射和遍历；需确保.env中APP_DEBUG=false，server:monitor显示Debug Mode为disabled，并注意Docker和反向代理环境变量透传。
APP_DEBUG=true 会拖垮生产响应速度
Hyperf 在 APP_DEBUG=true 时默认启用全量调试能力：异常堆栈完整输出、请求头注入 X-Debug-Info、自动加载未序列化的模型关系、控制器返回模型对象时强制触发访问器和隐藏属性计算。这些行为在开发中方便，但每个请求都会多执行几十次反射调用和数组遍历。
- 检查
.env或config/autoload/constants.php，确认APP_DEBUG值为false（字符串或布尔值都行，但不能是未定义） - 运行
php bin/hyperf.php server:monitor，看「Debug Mode」字段是否显示disabled - 若用 Docker，确保环境变量透传正确：
docker run -e APP_DEBUG=false ...，别只改了本地.env - 注意 Nginx/Apache 反向代理后，
$_SERVER['APP_DEBUG']可能被覆盖，优先用getenv('APP_DEBUG')检查实际值
SCAN_CACHEABLE=false 导致每次启动都重扫注解
Hyperf 启动时若未启用注解缓存，会用 ReflectionClass 遍历所有类并解析 #[Controller]、#[Inject] 等元数据——这个过程无法跳过，且 CPU 密集。开启 SCAN_CACHEABLE=true 后，只要 runtime/container/annotation/ 下有预生成文件，就直接 include，耗时从秒级降到毫秒级。
- 必须同时满足三个条件：配置中
'scan' => ['enable' => true]（默认已开）、SCAN_CACHEABLE=true（环境变量或constants.php中设置）、runtime/container/目录可写且已有缓存文件 - 首次部署必须手动运行
php bin/hyperf.php di:init-proxy，否则SCAN_CACHEABLE=true也无效——它只跳过扫描，不负责生成缓存 - 检查
runtime/container/annotation/是否存在 PHP 文件，空目录或只有.gitkeep表示缓存未生成成功 - Docker 场景下，
runtime/目录需挂载为 volume 且保持写权限，否则容器重启后缓存丢失
AOP 切面未收敛导致代理类爆炸式增长
Hyperf 的 AOP 是通过动态生成 Proxy 类实现的。如果 config/autoload/annotations.php 中 scan.paths 过宽（比如包含整个 vendor/），或切面 $classes 配置用了 * 模糊匹配，会导致框架为成百上千个类生成代理——不仅启动慢，还会显著增加内存占用和类加载开销。
- 把
scan.paths显式限定为业务代码目录，例如['app/Controller', 'app/Service', 'app/Model']，删掉vendor/和tests/ - 切面类中避免使用
$classes = ['*']或$annotations = ['*']，精确到具体类名或注解类 - 禁用
auto_binding：在config/autoload/annotations.php中设'auto_binding' => false，防止框架自动绑定所有带#[Aspect]的类 - 检查
runtime/container/proxy/下文件数量，超过 200 个就要警惕——正常业务项目通常在 20–80 个之间
真正卡住响应的，往往不是某一行代码慢，而是启动阶段没做对几件事：缓存没生效、调试没关、扫描路径失控。这些点一旦漏掉一个，压测时 QPS 就可能掉一半，而且现象隐蔽——日志里看不出错，CPU 却持续跑满。
