上周帮朋友看一个刚上线的网站企业站，首页打开要8秒。程序他跟我说服务器是检测4核8G，带宽5M，网站配置不差。程序我让他把网站程序目录发过来，检测扫了一眼就发现问题：一个简单的网站企业展示站，装了三个缓存插件、程序两个安全插件，检测还有一个“全能优化大师”。网站光这些插件加载的程序PHP文件就超过200个。程序检测的检测第一步，从来不是网站看代码写得好不好，而是程序看有没有必要的东西堆在一起互相拖累。

很多人以为网站慢就是检测服务器不行。其实程序层面的问题更隐蔽。比如WordPress站点，wp_options表里塞了几百条autoload数据，每次请求都要全量加载。我见过一个站，光是autoload的option就有1.2MB，每次页面请求光读这些数据就耗掉300毫秒。这不是服务器能解决的，得从程序里把没用的option清理掉。检测工具能帮你定位，但清理动作得手动做，因为没人知道哪些option是插件卸载后留下的垃圾。

PHP版本也是个重灾区。现在还有不少站在跑PHP 5.6，甚至5.3。这些版本早就停止安全更新了，性能也比PHP 7.x差一大截。同一个WordPress站，从PHP 5.6换到7.4，页面生成时间能从400毫秒降到120毫秒左右。这个提升不需要改任何代码，只需要在面板里切换版本。但很多人不敢换，怕插件不兼容。我的做法是先本地测一遍，确认没问题再上生产环境。检测程序兼容性有个笨办法但很管用：把error_reporting开到E_ALL，跑一遍全站主要页面，看错误日志里有没有弃用警告。

数据库查询是另一个大头。有个做外贸的客户，产品页每次加载要执行47条SQL查询。我看了下，其中32条是在循环里查同一张表的关联数据。这种N+1查询问题在自研程序里特别常见。检测的时候可以用SHOW PROCESSLIST看实时查询，或者开慢查询日志，把long_query_time设成0.1秒，跑一天下来就能抓到所有拖后腿的语句。改起来也不复杂，把循环里的查询提到循环外面，用IN一次性查出来再在PHP里组装。

前端资源加载顺序经常被忽略。CSS放底部、JS没加defer、图片没压缩，这些都会让页面渲染变慢。但程序检测能做的有限，得配合浏览器开发者工具看瀑布图。我习惯用Chrome的Lighthouse跑一遍，重点看FCP和LCP两个指标。如果FCP超过2秒，基本可以确定是服务端响应太慢或者阻塞渲染的资源太多。这时候再回头查PHP执行时间和数据库查询，方向就清晰了。

安全检测是另一条线。常见的问题包括：display_errors没关，报错信息直接暴露路径；上传目录有执行权限，传个PHP文件就能拿shell；phpinfo()测试文件忘了删。这些用简单脚本就能扫出来。我写过一个bash脚本，遍历网站根目录，找phpinfo、test、info.php这类文件名，再检查上传目录有没有.php文件。十分钟能扫完几百个站。比装那些花哨的安全插件实在得多。

程序检测不是一劳永逸的事。网站改版、加功能、换服务器，都可能引入新问题。我的习惯是每次上线前跑一遍基础检测：PHP错误日志、慢查询日志、关键页面响应时间、上传目录权限。四个指标正常，基本就不会出大问题。工具用顺手了，十分钟就能过一遍。比出了问题再救火轻松得多。

(责任编辑：焦点)