内容摘要：上周三凌晨两点，我盯着服务器日志里一条反复出现的404记录，来源IP指向我们自己的测试机。排查半小时才发现，是半年前一次改版时删掉的旧接口，前端某个角落还在悄悄调用。没人报错，用户也碰不到，但它就像墙

上周三凌晨两点，网站我盯着服务器日志里一条反复出现的自查自纠404记录，来源IP指向我们自己的报告测试机。排查半小时才发现，网站是自查自纠半年前一次改版时删掉的旧接口，前端某个角落还在悄悄调用。报告没人报错，网站用户也碰不到，自查自纠但它就像墙角发霉的报告斑点，不处理迟早扩散。网站这件事直接催生了这次网站自查。自查自纠

先说最要命的报告问题——死链。全站爬了一遍，网站揪出37条内部链接指向已删除页面。自查自纠大部分藏在帮助文档的报告“相关阅读”模块里，还有几条在用户个人中心的旧版入口。这些链接不会让网站崩溃，但搜索引擎爬虫撞上几次，整站权重就往下掉。我手动修了20条，剩下17条涉及历史数据迁移，暂时用301重定向兜住。这里有个细节：重定向目标页必须跟原内容相关，不能全甩到首页，否则等于告诉搜索引擎“我在敷衍”。

安全层面挖出两个隐患。一个是用户上传头像的接口，文件类型校验只看了扩展名。我试着把.php文件改成.jpg上传，居然成功了。虽然文件存在非Web目录，但万一哪天配置出错，这就是个后门。已经加了MIME类型和文件头双重验证。另一个是后台登录页没有频率限制，用Burp Suite跑了一百次请求，服务器照单全收。现在加了IP级限流，五分钟内超过十次失败就锁半小时。

性能方面倒是有意外发现。首页加载时间从1.8秒降到了1.2秒，什么都没改。查了监控才明白，是上周CDN服务商悄悄升级了边缘节点。这提醒我，外部依赖的变动也会影响自查结果，不能只看自己这一亩三分地。不过数据库慢查询日志里躺着一条SQL，在文章列表页执行了0.7秒。加了复合索引后降到0.05秒。有意思的是，这条SQL是两年前写的，当时数据量小，没暴露问题。

内容合规这块，我抽查了最近三个月用户发布的200条评论。有3条包含手机号，2条带外部引流链接。自动过滤规则漏掉了用谐音字绕过的案例，比如“威*信”。已经更新了敏感词库，但机器审核永远有滞后性，还是得靠人工抽查补位。另外发现三篇旧文章里的配图，版权来源标注模糊。联系了原作者，两篇拿到授权，一篇直接换成了自制图表。

移动端适配有个隐蔽bug。在iPhone 12 mini上，底部导航栏会跟系统手势条重叠，导致“我的”按钮点不到。模拟器测不出来，真机才复现。查了CSS，是用了固定定位加安全区域忽略。改成env(safe-area-inset-bottom)后正常。这种问题用户不会反馈，他们只会默默关掉页面。

自查过程中还翻出一堆“僵尸功能”。比如2019年上线的积分商城，入口藏得深，后台数据显示最近半年只有7次访问。产品经理确认已经废弃，但代码和数据库表还留着。删掉后，构建时间少了4秒。类似的无用CSS和JS文件清理出2.3MB，虽然对宽带用户不算什么，但能省一点是一点。

最后说个非技术问题。robots.txt里有一条Disallow规则写错了路径，把整个/user/目录屏蔽了。这导致用户个人主页在百度上完全搜不到。改过来之后，三天内索引量涨了15%。有时候自查不能只盯着代码，还得看看那些“以为没问题”的配置文件。

这次自查没用什么高级工具，就是爬虫加日志加手动点击。发现的问题都不算致命，但堆在一起，用户体验就像穿了件扎人的毛衣——说不出哪里不对，就是不舒服。修完这些，至少能睡个安稳觉。下次自查定在三个月后，到时候重点看API接口的版本兼容性。