用phpcms做站的检查人，十有八九都干过同一件事：打开后台，检查找到“模块”菜单，检查点进“文章”或者“内容”，检查然后盯着那个“检查”按钮发呆。检查这按钮到底查什么？检查点了会不会把好好的数据搞崩？我见过一个运维，手一抖点了全站检查，检查结果前台直接白屏，检查数据库里三张表被锁了十分钟。检查

phpcms的检查“检查”功能，藏在后台“内容”模块下的检查“内容维护”里，不同版本位置略有差异。检查它本质上干三件事：查数据表字段和模型定义是检查否对得上、查附件路径在服务器上是检查否真实存在、查栏目缓存和实际数据有没有脱节。检查听起来挺合理，但实际用起来，坑比功能多。

先说什么情况下该点这个按钮。最常见的是搬家之后。你把数据库从A服务器导到B服务器，附件目录也拷过去了，但后台文章列表死活显示不出来，或者点编辑报“模型字段不存在”。这时候去点“检查”，它会把模型表里缺失的字段补上——注意，是补上，不是修复。如果原表结构已经乱了，它补出来的字段类型可能跟你原来设的不一样。我遇到过一回，原来content字段是mediumtext，检查后变成了text，文章超过64KB的部分直接被截断，而且没有任何提示。

再说附件检查。phpcms会把数据库里记录的附件路径逐个去服务器上file_exists一下。这个操作在附件少的时候没问题，几万条附件记录的话，光文件系统调用就能把PHP进程卡死。更麻烦的是，如果服务器开了open_basedir限制，检查脚本会报一堆“路径不在允许范围内”的警告，但实际上附件是好的。这种误报多了，很多人就干脆不看检查结果了。

栏目缓存检查相对安全，它对比的是cache目录下的栏目缓存文件和数据库里的栏目表。不一致就重新生成缓存。但有个细节：phpcms的缓存文件是按站点ID和栏目ID命名的，如果你在多站点模式下操作，检查功能只处理当前站点的缓存，其他站点的缓存它不管。有人以为点一次全站检查就万事大吉，结果其他站点的栏目还是旧的。

真正危险的是“修复”动作。检查完会列出一堆问题，底下有个“修复”按钮。这个修复不是事务性的，它是一条一条SQL去执行。如果中途某个字段因为重复或者类型冲突执行失败，脚本不会回滚，前面已经改掉的字段就留在那了。我见过最惨的情况是，一个站有二十多个模型，检查后点了修复，结果三个模型的表被改得面目全非，最后只能从备份恢复。

那这个功能到底怎么用才安全？我的习惯是：先备份数据库，只备份要检查的那几个表也行。然后不要在全站模式下点检查，进到具体的模型管理里，单独检查单个模型。附件检查如果附件量大，直接跳过，用rsync或者自己写脚本去核对文件列表更靠谱。至于修复，能手动改SQL就手动改，phpcms的自动修复只适合那种字段完全丢失、表结构简单的情况。

还有个冷门点：phpcms的检查功能对自定义字段支持不好。如果你在模型里加了自定义字段，但没在模型表里建对应的列，检查能发现，但修复时它按默认的varchar(255)去建，不管你原来设的是int还是decimal。所以自定义字段多的站，检查完一定要去phpmyadmin里看一眼字段类型对不对。

说到底，phpcms这个检查功能是个半成品。它想帮你省事，但省事的代价是你要懂它到底在干什么。不懂就点，跟闭着眼睛改数据库没区别。我现在的做法是，新站上线前跑一遍检查，确认模型和表结构一致，之后除非搬家或者改过模型，否则再也不碰它。毕竟，一个能正常运行的站，最好的状态就是别乱动。