以前能用最近坏了，先查自己最近的改动

更新于 2026-06-04

**「之前没问题、最近出问题」时，默认假设是自己这边的改动造成的回归：先去翻最近几次提交动了哪条链路，而不是先怀疑外部源（网站改版、上游接口、环境）。** 外部源没变，也完全能解释全部症状。

一、排查顺序

  1. 列最近的改动，尤其最近的修复提交——修复往往就是下一次故障的起点。
  2. 把症状按「链路换实现的时间点」对齐：症状是跟着某次提交出现的，就是回归。
  3. 只有当自己的改动解释不了现象时，再去怀疑外部。

二、修复补丁常把旧问题换个形态暴露

为修「图片显示成 ![](url) 字面量」，parser 从输出 Markdown 改成输出 inline HTML，同时加了兜底「渲染前剥掉所有 <span>」。图片是好了，但副作用是：靠 span/section 组织版式的页面（公众号文章）段落和样式被压平。

教训：补丁解决的是现象，如果它的作用面比问题大（这里是全局剥标签），副作用就会以另一种症状出现。改全局渲染规则前，先想清楚有哪些页面依赖被改掉的结构。

三、换存储载体会让数据质量问题从隐性变显性

同一段内容，从 SQLite（只当 app 内部数据用）改成落盘 Markdown 文件后，parser 输出质量就变成了「数据真相」：以前视觉问题不显眼，现在文件里第 18 行就是一整条超长 inline HTML，一眼可见。

推论：持久化位置/格式变更后，要重新审视上游产物的质量。问题不是新产生的，只是从看不见变成看得见。

四、连带的表象不要单独修

窗口偏移是这个坏数据的第二后果（超长 inline HTML + 缺横向溢出约束把阅读区撑宽，露出透明背景），不是布局单独写错。先修根因，表象跟着消失。

相关