ThinkPHP部署后访问缓慢的根源在于调试模式未真正关闭、缓存未生成、Redis连接超时及模板/插件加载低效；需验证config('app.debug')为false，执行php think optimize:config、route:cache和composer dump-autoload -o，设置Redis timeout≤0.1秒，并禁用cache_lite与auto_load。
确认调试模式是否真正关闭
APP_DEBUG = true 是性能杀手——它会让框架每次请求都重载配置、校验路由、记录完整日志、不缓存模板、加载Trace面板。哪怕只在某个容器或分支里漏关，响应时间就可能从 80ms 拉到 450ms 以上。
别只改 .env：检查 config/app.php 中 'debug' => true 是否被硬编码覆盖；也别依赖肉眼判断，用命令验证真实值：
- php -r "var_dump(config('app.debug'));" —— 输出必须是 false
- 运行 php think clear 清空 runtime/ 下所有缓存，否则旧的调试态模板、路由仍会被加载
- 顺手检查 app_trace 和 show_error_msg 是否也为 false
生成并强制使用静态缓存文件
没启用缓存时，每次请求都要重新解析 config/ 下十几个 PHP 配置文件、扫描全部控制器找路由、遍历注解、反复判断类是否存在——全是 IO+CPU 双重开销。
必须手动触发以下三步（TP5/TP6/TP8 均适用）：
立即学习“PHP免费学习笔记（深入）”；
- php think optimize:config（TP5）或 php think optimize:config（TP6+）→ 生成 runtime/init.php，跳过 config/ 目录
- php think route:cache → 生成 runtime/route/route.php，固化路由映射，不再反射扫描
- composer dump-autoload -o → 生成 vendor/composer/autoload_classmap.php，让类加载变成数组查表，而非实时遍历目录
生成后，检查对应文件是否存在且非空；再确认 config/route.php 中 'route_check' => false 已设，禁用运行时校验。
检查 Redis 连接是否拖垮主线程
缓存驱动设为 Redis，但服务连不上？ThinkPHP 默认不会报错，而是默默等待超时（默认 0.5 秒），之后降级到 File 缓存——这个等待卡在 PHP 主线程，所有并发请求全被堵住。
- 先用 telnet your-redis-host 6379 或 redis-cli -h host -p port ping 确认网络与服务可达
- 在 config/cache.php 的 redis 配置块中，显式加一行：'timeout' => 0.1，把等待上限压到 100ms 内
- 确保 'type' => 'redis'，同时把 file 驱动彻底禁用，避免高并发下 inode 锁争抢
模板与插件加载常被忽略的细节
模板多、挂载在 NFS 或 Docker 卷上？template.cache_lite 开启后，每次渲染前都会读取原始模板的 filemtime，IO 延迟飙升。直接关掉更稳：
- config/template.php 中设 'cache_lite' => false
- 同时确保 'auto_rule' => true，让编译缓存（runtime/template/xxx.php）正常生效
插件也容易成为隐性瓶颈：默认开启 auto_load，每次请求都遍历 addons/ 目录、读取每个插件的 addon.php ——哪怕当前页面完全不用它。
- config/addon.php 中设 'auto_load' => false
- 清空 runtime/addons/ 目录，否则旧缓存仍生效
- 插件内钩子注册要按需，比如只在后台控制器才注册 app_init，避免前端接口也被拖慢
