接口响应慢大概率是缓存未启用、autoload未优化、OPcache未生效或冷启动/IO路径反复触发；需验证APP_DEBUG是否真关闭、生成路由与配置缓存、优化Composer自动加载、确保OPcache在CLI和FPM中均启用，并检查runtime目录权限及PHP-FPM进程池配置。
接口响应卡在 1–2 秒，人一多就排队打转，大概率不是代码写得烂，而是几个关键缓存没开、autoload 没压平、OPcache 没生效，或者冷启动/IO 路径被反复触发。
确认 APP_DEBUG 是否真关了
改了 .env 里的 APP_DEBUG=false 不代表生效——config/app.php 里 'debug' => true 会覆盖它；更隐蔽的是某处 define('APP_DEBUG', true) 硬编码，直接绕过所有配置。
- 用命令行验证真实值：
php -r "var_dump(config('app.debug'));"，输出必须是false - 检查
.env文件末尾有没有空格、BOM 或中文字符（尤其 Windows 编辑器保存时容易带） - 执行
php think clear清掉 runtime 下残留的调试态路由、模板、日志缓存，否则旧缓存还在偷偷加载
生成并验证路由与配置缓存
没启用路由缓存时，每次请求都要扫描 route/app.php、反射注解、拼接规则，IO + 反射开销极大。TP6/TP8 默认不生成，必须手动触发。
- 执行
php think route:cache，成功后会在runtime/route/route.php生成扁平化映射文件 - 执行
php think optimize:config，生成runtime/init.php，跳过 config/ 下全部 PHP 文件解析 - 注解路由特别吃资源，控制器方法超过 50 个时，优先改用数组定义路由；废弃控制器或测试类别留在
app/controller/目录下，它们也会被扫描
优化 Composer 自动加载行为
composer dump-autoload -o 不是万能的。它只加速已注册的 PSR-4 或 classmap 规则，而 ThinkPHP 的 extend/ 目录、未声明命名空间的 helper 函数、路径与命名空间不匹配的类，全都不在优化范围内。
立即学习“PHP免费学习笔记（深入）”；
- 把高频工具类抽成独立命名空间，确保目录结构与
composer.json中psr-4完全对应 - 对稳定不常变的 SDK 或工具库，显式加到
classmap："classmap": ["library/Utils/", "vendor/mycorp/sdk/src/"]，再跑dump-autoload -o - 禁用
extend/自动加载：在config/app.php加'extend_list' => []，改用 Composer 管理 - 慎用
Loader::addNamespace()——它是运行时字符串匹配，比 PSR-4 还慢，只适合极小范围兜底
检查 OPcache 和 PHP-FPM 配置是否真正生效
Ubuntu/CentOS 上装了 OPcache 不等于开了；CLI 场景（如 php think 命令）默认不启用，但 ThinkPHP 的缓存生成、路由扫描都走 CLI，没开就白搭。
- 确认
opcache.enable=1和opcache.enable_cli=1都设了，路径注意区分 FPM 与 CLI 的php.ini（比如/etc/php/8.1/fpm/php.ini和/etc/php/8.1/cli/php.ini） - 执行
php -i | grep opcache，看到opcache.enable => On才算真启用了 - PHP-FPM 进程池别用
static，推荐dynamic并设好pm.max_children（按单进程内存 × 并发预估），否则请求排队等 worker 是隐形瓶颈 - 函数计算场景要额外注意：冷启动时 OPcache 未预热、
runtime/目录挂载为临时卷导致缓存无法复用、单实例并发度没调高，都会让响应从 200ms 拉到 2s+
最容易被忽略的是：runtime/ 目录权限不一致（比如被 root 创建，PHP-FPM 用户无写权）、realpath_cache_size 过小导致频繁系统调用、以及 Docker 环境下 /tmp 被挂为 tmpfs 却没配够大小，这些都会让缓存写入失败或反复重建。
