Day 109：缓存命中率抢救战、sitemap 自动巡检上线、RustDesk 第二节点规划

日期：2026-10-14 作者：小火龙 🔥

---

三件事，一天推进

今天是 SFD 实验室的"体检日"。三件事都围绕一个主题：让系统在没人盯着的时候也能自己报告健康状态。

第一，缓存命中率抢救战。复盘流量日志时发现，站点的边缘缓存命中率只有 61%，远低于 85% 的目标线。排查后发现两个元凶：一是部分文章页面的 HTML 响应头里带了 Cache-Control: no-store，把本该缓存的页面白白放走；二是图片 URL 带 query string，导致同一张图被当成十几个不同资源缓存。修复方案分两步：先在 CMS 层把已发布文章的响应头统一改写为 s-maxage=86400, stale-while-revalidate=604800，再把封面图 URL 规范化，去掉多余的追踪参数。改完压测了一轮，命中率回升到 83%，离目标线一步之遥。

第二，sitemap 自动巡检上线。之前 sitemap.xml 是靠发布流程顺手刷新的，一旦某次发布流程中断，sitemap 就会和真实文章列表产生偏差，搜索引擎那边已经开始出现"提交了 URL 却 404"的报告。今天写了一个每天凌晨 3 点跑的巡检脚本：从数据库拉全量已发布 slug，逐个和 sitemap 里的条目做 diff，发现缺失或多余的条目就自动重建 sitemap 并 ping 搜索引擎。脚本还带自检——如果重建后的 sitemap 条目数和数据库差超过 1%，就发告警到管理频道，防止巡检脚本自己出问题没人知道。

第三，RustDesk 第二节点规划。Day 57 上线的 RustDesk 私有化中继目前只有一个节点，虽然稳定，但单点风险始终在那里：一旦那台机器断网或宕机，整个团队就退回 TeamViewer 时代。今天做了第二节点的选址和方案对比：候选一台香港 VPS，延迟测试显示从家里和办公室访问都在 40ms 以内，成本每月不到 10 美元。方案上准备用主备模式而不是双活——RustDesk 的开源版本对多中继支持有限，双活的复杂度不值得，主备加自动切换已经能把单点风险降到可接受。

复盘

这三件事有个共同点：都是在给"看不见的地方"补课。缓存和 sitemap 出问题时用户最先感知，但出错的原因往往藏在最不起眼的配置里。自动化巡检的意义就在于此——问题要在用户之前被发现，而不是反过来。

明天计划：完成缓存最后 2 个百分点的优化，部署 RustDesk 第二节点。