LiMhy 更新手记，这次从一条自动封禁记录查起

这轮更新，是从后台一个让我有些疑惑的地方查起的。

实时拦截列表里已经出现了“自动封禁”，可我再去看封禁记录，好像又没看到对应的 IP。到底是还没达到阈值，还是系统只记下了这件事，后面的动作没有执行？

既然安全是 LiMhy 博客系统一直想做好的部分，这个疑问就得查清楚。顺着处置流程往下看，再把其他模块一起过一遍，最后做成了这次更新。这里把大家用得到、也值得知道的变化聊一聊。

安全中心先补上了处置结果和界面显示之间的缺口。审查中确实查到，部分请求已经达到了封禁条件，却因为走了不同的处理分支，没有把封禁结果保存下来。现在这几条路径统一了处理，封禁动作与浏览器验证页分别处理，避免请求类型影响应该执行的处置。

后台显示也跟着调整。历史上触发过封禁，和此刻仍然处于封禁中，得让站长看得出区别。封禁到期以后，旧事件会留下，当前状态则按实际情况展示。以后再看一条拦截记录，就不用只凭“自动封禁”几个字猜它现在是什么状态。

同一条访问记录，在列表和详情里出现不同的风险分，也一起修了。信誉中心、决策中心和详情画像现在共用评分逻辑。设备封禁的开关和有效期重新统一，地域判断也补了可信来源校验。安全健康检查则会检查实际存储是否可用，减少配置开着、页面显示正常，底下却没有正常工作的情况。

这些调整都落在很具体的地方。我希望站长看到一条处置结果时，能顺着记录查到依据，也能确认它是否生效。

接着是访问环境。以前全站统计里能看到设备信息，到了评论管理或威胁分析窗口，又得换个地方找。我自己看后台时也觉得，这些信息放在当前记录旁边才方便。

这次把访问环境组件补到了评论管理、信誉中心，以及仪表盘的威胁情报与活动分析详情里。看评论和查看异常访问时，可以一并了解浏览器、设备类别和相关环境线索，不用来回切页面。

识别时优先使用浏览器提供的 Client Hints，信息不够再回退到 User-Agent，并展示识别来源与可信度。浏览器内核、WebView、无头浏览器等线索，也有了对应的识别和呈现。

不过，这些字段来自访问端，可能缺失，也可能被修改。一个设备名称、一项浏览器特征，都不足以认定访问者的身份。界面保留了这个分寸，也做了脱敏处理，避免把整段原始请求信息直接堆给站长。

F12 探针也按这个思路重新梳理了一遍。之前我就觉得它的判断不够精准，这次把快捷键、持续的视口变化和关联信号分别记录，后台标明信号强弱及来源。旧记录无法确定的地方，也会按未知情况展示。

这里有一点需要说清楚。网页能观察到的变化有限，按过某个快捷键，并不能证明开发者工具已经打开。即使打开了，也不能据此判断对方在攻击网站。

因此，F12 客户端观察信号只作为查看记录时的参考，不增加风险分。采集关闭后就停止采集，事件提交和重试也加了边界，服务端收到数据还要校验和确认存储。这个模块能提供多少信息，就如实显示多少。

另外，后台访问日志终于可以少一点站长自己的足迹了。

我之前翻日志，里面大半都是自己的访问。现在，系统确认管理员处于有效登录状态后，普通访问会跳过这类日志记录。判断依据包含登录凭证的校验，并非看到同一个 IP 就直接忽略。因此，同一网络下的其他访客、退出登录后的访问，以及无效登录凭证，仍然按正常规则记录。

独立的安全事件会继续保留，已有历史日志也不会被清空。这样平时看访客记录能清楚一些，需要追查安全问题时也还有依据。

安全之外，这轮也处理了几处每天会碰到的小地方。

默认头像换成了之前为系统设计的六张专属图片。没有可用头像时，会根据身份信息稳定分配其中一张，同一身份不会每次刷新就换个样子。已有头像仍然优先使用，加载失败再回退到本地图片。评论、回复和相关资料展示共用了这套逻辑，整站看起来也统一一些。

封禁原因时间线里，长内容把卡片撑坏、证据区域互相挤压的问题也修了，手机上的换行和排版一起调整。安全记录本身已经够复杂，页面至少应该让人顺顺当当地看完。

后台的更新日志功能页这次移除了。这个页面我不打算继续单独提供给使用系统的朋友，少一个重复维护的入口。前台的日志与反馈仍然保留，大家原来使用的那部分没有取消。

随后做的全系统代码审查，又查出了 16 项需要修复的问题。这些问题已经完成修复并更新到线上，范围包含安全处置，也涉及评论隐私、文章解析和备份恢复。

其中有一项很值得单独提醒。此前自动备份在关闭邮件通知时，存在只记下完成时间、没有实际保存备份文件的情况。这次把备份和通知分开，先保存并校验文件，再记录成功。备份恢复的格式校验和执行流程也补了一轮。对站长来说，“显示备份成功”背后有没有一份能用的文件，是必须认真对待的事。

公开资料中的评论可见范围也收紧了，私密或受密码保护内容下的评论，不应从公开资料入口被带出来。待审核评论修改历史网址的边界、密码重置流程之间的相互影响，以及邮件发送失败时的重试限额，都做了对应修复。普通文本被误当成表格后可能卡住的 Markdown 解析问题，还有精选评论的分页问题，也在这一轮处理了。

修完以后，后台又出现过一次“节点发生波动”。这次有真实错误日志可以对照，最后查到的是旧版 SQLite 的兼容问题，以及降级读取大量历史记录时的内存消耗。相关查询改用了兼容处理，读取记录时也限制了范围，避免一次把过多历史数据装进内存。

这部分修复随后重新做了后台登录验证，信誉中心、决策中心的列表、筛选和详情都走了一遍，验收期间没有新增崩溃日志。本轮回归也覆盖了 PHP 8.1、8.3、8.4，以及实际旧版 SQLite 的运行组合。不同主机仍会有环境差异，大家更新后如果遇到异常，保留报错和运行环境信息，会更方便继续定位。

感谢遇见！昨天全站统计