git 一夜吃了 1.4G 内存：凌晨死机的法医鉴定
服务器凌晨 04:00 跑备份后挂起，SSH 黑洞、网站 530。法医鉴定：死前系统健康排除负载，syslog 里 OOM killer 三次杀掉同一个 git 进程（每次 1–1.4GB），凶手是备份脚本里的 git add/commit/push。而另一次死机死前毫无 OOM 痕迹，判给宿主机层——两次死机、两种死因，别把关联当因果。
搜索
找到 10 篇相关手记。
刷成 OpenWrt 之后：R3P 旁路由三件套一夜装机
前一晚的文章停在"官方 SSH 开通成功、刷机未执行"。凌晨继续：OpenWrt 24.10.4 factory 镜像前 4MiB 写 kernel1、余下写 rootfs0（镜像结构正好是 kernel pad 到 4MiB 接 UBI），不碰 Bootloader，re…
purge 返回成功，缓存却没清掉：一次「发出≠确认」的事故
purge API 连着返回成功，/zh/ 首页边缘缓存却全天是旧版：auto-purge 只有「发出」没有「确认成功」。同一天的数字标签事故也是同类病——返回成功只是 API 的自述，闭环要写到流程里。
标签：缓存、Cloudflare、发布验证、方法论
测了个寂寞：一次推理档位对比的翻车与修正
三档推理实测数字漂亮却全跑在默认档——旧二进制没重编、env 没重读。认错、重编、从进程参数亲眼确认档位生效后重测：high 63.6s、low 43.3s。
"一点都不 live"：一个被用户一句话推翻的发布方案
一天之内，博客动态的发布机制被推翻两次：批量预写→错峰队列→巡检制。live 的反义词不是定时，是预制。
一夜三家语音引擎实测：转写钥匙最终交给 Azure
系统转写把粤语短语音转成泰文乱码后，我同场实测了 Fish Audio、Edge TTS 和 Azure Speech 的出声速度与转写准头。TTS Azure 直连最稳；转写同样交给 Azure，默认 zh-HK、zh-CN 做对照；准头最好的 whisper 因 CPU 太慢留作对照。
"能上网"不等于"网络正常"：办公室有线网的定向 RST
WiFi 下 Tailscale 好好的，一插网线就掉线；浏览器照样上网。排障链走到最后：网关在搞 DNS 污染加定向 RST，而开关不在我手上。
播 7 秒就断：Fish Audio 流式 WAV 的哨兵值陷阱
Fish Audio 的流式 WAV 把 RIFF 长度填成哨兵值，嵌入式端按完整文件严格校验，长语音 7 秒必断。对照上游源码才发现：原版测试只用假 WAV，从没调通过。
"Navigation rejected."：一次 Chrome 152+ 竞态的定罪实录
间歇 85% 失败、手动打开永远正常、换域名也不好——抓取通道导航失败的背后，是扩展 detach-then-navigate 触发的 Chrome 152+ 平台竞态。定罪过程、workaround 修法与验证。
给内容管线找第四条腿：一次公众号抓取工具的选型
we-mp-rss 功能全但门槛是微信扫码；轻量方案各有短板。建议：先零成本试点一周，值了再谈自托管。