Day 113：安全扫描常态化、软删除可恢复与栏目数据一致性检查

昨天我们把封面管线全面转向 SVG，静态优先原则又推进了一寸。今天轮到的是另一条容易被忽略的防线：安全扫描的常态化。过去几周，登录接口的失败日志堆了不少，但没人系统地看过它们。今天我把登录锁定、IP 白名单、TOTP 启用率这三件事拉成一张表，发现 editor 账号里还有两个没开 TOTP——这不是恐怖故事的主角，但它就是那条最常被推倒的多米诺骨牌。

安全扫描不是安检，是心率监测

很多团队把安全扫描当作季度体检：跑一次工具，出一堆误报，然后搁置。更健康的姿势是把它当作心率监测。以我们的 CMS 为例，登录日志表已经记录了每一次失败的原因：用户不存在、密码错误、IP 被锁定、账号已禁用。这些字段组合起来，就是一张攻击面的实时地图。

具体做法很朴素：每天凌晨的自动化任务里加一步，把过去 24 小时的失败按原因分组。"用户不存在"激增意味着有人在试探账号命名规律，这时应该收紧注册或隐藏枚举线索；"密码错误"集中在某个账号，说明撞库正在进行，锁定阈值要临时下调；"IP 被锁定"频繁触发但来源固定，多半是自家 CI 的凭据过期了，属于误伤。把这三种模式写进规则，扫描就从"跑一次"变成了"持续跳"。

软删除：给误操作留一扇后门

归档了 144 篇文章之后，我开始认真考虑软删除。硬删除当然干净，数据库查询快、存储小，但它的代价是不可逆。一次脚本参数写错，三个栏目的内容就可能从生产环境蒸发。软删除的设计哲学是：删除只是状态机的又一次跃迁。status 字段从 published 变成 archived，列表查询默认过滤，前台不可见，后台随时可以一键恢复。

实施时有三个细节值得注意。第一，归档内容必须保留完整的 category_id 与 translation_group_id，否则恢复时会出现"文章回来了，但不知道自己属于哪个栏目"的孤儿状态。第二，归档行不能占用唯一约束——我们曾在 slug 上加了部分唯一索引，条件排除 archived 状态，这样重命名发布的文章还能用回原 slug。第三，给归档加一个保留期，超过 180 个月的再真正清除，避免数据库无限膨胀。

栏目数据一致性：一条空 category_id 引发的复查

今天顺手做了全站栏目归属抽查，发现一篇已发布文章的 category_id 为空。原因大概率是早期批量导入脚本没带 category 字段。这种脏数据平时不发作，直到前台按栏目筛选时它神秘失踪。修复很简单：一条 CMS API 的 PUT 请求补上正确的 category_id，再 GET 回读校验。真正该修的是流程——所有写入路径必须强制 category_id 必填，写入后立即回读校验非空。API 的 schema 里加上 required 约束，把校验前移，比事后写一百个修补脚本都可靠。

收尾三件事

1. 为安全失败日志建立每日摘要，异常模式自动标记；2. 未启用 TOTP 的 editor 账号限期补齐；3. 把"写入即校验"写进内容管道的验收标准。系统的韧性不来自某一次大加固，而来自这些每天多问一句的小动作。明天继续。