页面加载 1 秒到 300 毫秒：一次 PHP 站点优化全记录

300 毫秒不是靠某个开关调出来的，而是「先量后调 + 三层削峰」的结果：把单页数据库查询从 60 多次压到个位数、把重复计算交给缓存、把重活挪到定时任务，最后再收拾静态资源。

第一步：先量，别猜

结论：优化前必须先分清时间花在 PHP 还是花在带宽，否则很容易把时间浪费在错误的地方。

打开浏览器开发者工具的 Network 面板，看第一份 HTML 文档的 TTFB（Time To Wait，服务器返回第一个字节的耗时）。TTFB 800ms 说明是后端问题；TTFB 只有 100ms 但页面 1 秒才转完，那是图片、字体、JS 的锅，改 PHP 没用。

我这次的情况是 TTFB 稳定在 780-850ms。接着在服务器上临时打点计时（或看慢查询日志），拆成三段：PHP 执行、数据库查询、模板渲染。结果数据库占了七成，问题定位完成。

第二步：把数据库查询砍到个位数

结论：PHP 站点的性能天花板通常不是 CPU，而是每页几十次 SQL 查询，先解决 N+1 再谈别的。

典型症状是列表页每条帖子都单独查一次作者信息、附件数、点赞数——20 条帖子就是 60 次查询。修法有三种：

• 一次性把关联数据查回来，用 `WHERE id IN (...)` 批量取，循环里只做内存匹配；
• 给查询条件加索引，尤其 `WHERE board_id = ? AND status = ? ORDER BY id DESC` 这类组合，缺索引会直接全表扫；
• 高频且允许轻微延迟的统计值做缓存，比如版块今日发帖数，没必要每次实时数。

这一段做完，查询数从 60+ 降到 8 次以内，TTFB 直接掉到 320ms 左右。

第三步：缓存要选对位置

结论：缓存的价值在于「同一份数据在多个页面被反复算」，而不是无差别地缓存一切。

本系统提供了 `Cache::remember` 这个公共设施，把「算一次、用多次」的公共数据丢进去最划算：站点统计、排行榜、版块树、热门帖列表。判断标准很简单——这份数据是不是每个访客看到的都一样？是不是允许 60 秒的延迟？两个都满足就可以缓存。

需要提醒的是，这套系统本身是保存即生效、无需清缓存的设计，后台改了设置立刻生效。所以你加的业务缓存要自己设定合理过期时间（比如 60-300 秒），不要设成永久，否则改数据后前端不刷新会让人怀疑人生。真要立刻生效，后台「系统工具→缓存清理」走一次即可。

第四步：把重活挪到定时任务

结论：凡是「用户不需要立刻看到」的计算，都应该从请求链路里搬走。

典型的重活包括：GEO 健康体检、站点统计汇总、失效数据清理、批量推送。这些如果塞在用户请求里做，等于每个访客都替你的后台工作买一次单。

本系统的 `Cron::register` 是懒触发机制，零配置——不需要你去服务器 crontab 里加一行，有请求进来时顺带判断该不该执行。把重活挂上去之后，前台页面只剩「取现成结果」这一个动作。

第五步：插件与钩子的取舍

结论：插件钩子体系本身很轻，但装得多了一定会拖慢首字节，该关就关。

这套系统是运行时钩子加载，一共 156 个钩子，插件放在 `content/plugins` 目录、保存即生效，不需要编译也不需要命令行。好处是开发迭代快，代价是每个请求都要跑一遍已启用插件的钩子检查。我这次关掉了三个没在用的插件（访客统计、抽奖、广告位），TTFB 又降了约 40ms。

顺手说一句：这套系统本身不依赖任何编译缓存，装在共享主机上也能跑；如果你在服务器 PHP 层开了 opcache，那属于主机侧优化，和系统本身无关，开不开都能正常运行。

第六步：剩下的 300ms 交给静态资源

结论：后端压到 150ms 之后，决定最终观感的就是图片体积和资源缓存。

三个动作见效最快：一是后台「系统设置→上传」里把允许的扩展名和体积上限配好，同时确认 PHP 的 `upload_max_filesize`、`post_max_size` 足够大（宝塔默认 2M，手机照片轻易超过，建议调到 30M+）——上传失败的三大原因就是白名单、PHP 上限、目录不可写，页面会直接提示具体是哪一条；二是大图和大附件走云存储或 CDN，后台有云存储设置项；三是开启 PWA，让静态资源在客户端本地缓存。

另外，全站是单模板响应式，一套视图同时适配手机和桌面，这意味着你不用维护两套前端，但也要注意别在共用模板里塞大体积的第三方脚本，那是唯一会同时拖慢两端的地方。

收个尾

从 1 秒到 300ms 的路径其实很朴素：先用 TTFB 定位方向，再把数据库查询从 60 次砍到 8 次，用 `Cache::remember` 接住重复计算，用 `Cron::register` 把重活挪出请求链路，关掉不用的插件钩子，最后收拾图片和静态资源。每一步都能单独量化，也都能单独回滚——这比一次性大改要安全得多。