[Bug] 多行 $$ 公式块丢失开首行内容，并把后续正文一路吞成数学源码（渲染为红色原文）

[Sc0re-16]

Summary / 摘要

@deepseek-ai/dsh-client-ui-primitives 的 markdown 渲染器（文档预览与聊天消息共用）无法正确解析最常见的 Obsidian / MathJax 风格 display math：

$$a=b,\qquad
c=d$$

$$a=b
c=d
$$

两种写法都会出错：

1. $$ 开围栏后同一行上的公式被上游 mathFlow 当成 fence meta，而 mdast 的 node.meta 在整个渲染模块里没有任何代码读取 → 开首行内容静默消失；
2. 收尾围栏必须位于行首，写在公式行尾的 $$ 不算闭合 → math 节点的 value 把后续正文一路吞到下一个行首 $$（没有就吞到文件末尾）；
3. 被吞进去的内容不是合法 TeX，katex.tsx 的三臂渲染链只能把整段原文以红色 katex-error span 打印出来 —— 用户看到的就是"一大段红色原文"。

English TL;DR: a display-math block that starts its formula on the same line as the opening $$ and closes with $$ at the end of a formula line is parsed by micromark's upstream mathFlow, which turns the opening line into mathFlowFenceMeta. mdast-util-math stores it in node.meta, the renderer only reads node.value, and since the closing fence is only recognised at the start of a line, the math node swallows every following line up to the next bare $$ (or EOF). KaTeX then fails and prints the whole blob as raw red text. mathCompatibility() already contains a same-line dollar flow that would handle this, but parseGfmWithMath registers math() after it, and micromark gives the later extension precedence, so that construct is always shadowed.

Reproduction / 复现

应用内：把下面的内容写进任意 markdown 文件，用侧边栏文档预览打开（聊天消息同样可复现）。

四种写法对照（⏎ 表示换行）：

#	输入	期望	实际（mdast）
1	$$x+y$$	display math	✅ math(value="x+y")
2	$$⏎x+y⏎$$	display math	✅ math(value="x+y")
3	$$a=b⏎c=d$$	display math，内容 a=b⏎c=d	❌ math(meta="a=b", value="c=d$$")
4	$$a=b⏎c=d⏎$$	display math	❌ math(meta="a=b", value="c=d")
5	第 3 种 + 后续普通段落	公式块 + 正常段落	❌ math 节点吞掉后续全部内容包括标题、列表、正文，直到下一个行首 $$ 或 EOF

最小复现（不需要 DSH 内部源码，只用公开依赖即可观察到关键的第 1、2、3 步）：

import { fromMarkdown } from 'mdast-util-from-markdown'
import { mathFromMarkdown } from 'mdast-util-math'
import { math } from 'micromark-extension-math'

const source = '$$a=b,\\qquad\nc=d$$\n\n后面这段正文也会被吞掉\n'
const root = fromMarkdown(source, { extensions: [math()], mdastExtensions: [mathFromMarkdown()] })
console.dir(root, { depth: 6 })

实测输出：

math {
  meta: 'a=b,\\qquad',        // ← 开首行内容进了 meta，渲染器从此不再看它
  value: 'c=d$$\n\n后面这段正文也会被吞掉'   // ← 行中 $$ 不闭合，value 一路吃到 EOF
}

真实案例：一篇 777 行的 Obsidian 笔记里，以 $$ 开头的行有 75 处、没有任何一行是"只有 $$"的围栏行。第 144 行的 $$ 打开围栏后，\cos\theta=\frac{x}{1}=x,\qquad 成为 meta 被丢弃，从第 145 行的 \sin\theta=...=y$$ 起，直到文件末尾全部落进同一个 math 节点（该节点 value 长 19792 字符）。KaTeX 第一层 throwOnError: true 直接抛 KaTeX parse error，随后由 errorColor: #cc0000 把整段原文渲染成红色，也就是现象里那一大段"乱码"。

Current behavior / 当前表现

• 开围栏行上的公式内容静默丢失（表格第 4 种：即使结尾是独占一行的 $$，a=b 也照样不见）。
• 行中收尾的 $$ 不闭合，导致公式块吞并后续正文；后果从"一个公式块渲染错"升级为"整篇文档后半部分全毁"。
• 被吞的原文以红色 monospace 原文形式输出，看起来像乱码/崩溃，误导性很强。

Expected behavior / 预期表现

与 Obsidian、MathJax、KaTeX、VS Code 等实现一致：$$ ... $$ 是 display 块，允许在 $$ 同一行开始写公式、允许跨行、允许在任意 $$ 处结束。至少：

• 不应把 $$ 后同一行的内容当作可丢弃的 meta；
• 未闭合时也不应让 math 节点吞并后续无关的块级内容；
• 若确实保留了 meta，render.tsx 的 case 'math' 应当把它一起渲染，而不是静默忽略。

Root cause / 根因

1. packages/client/ui-primitives/src/markdown/parse.ts:42：

   extensions: [gfm(), cjkFriendlyStrong(), mathCompatibility(), math()],

2. micromark 的 combineExtensions 把每个扩展的 constructs 前插（micromark-util-combine-extensions：splice(existing, 0, 0, before)），即数组里越靠后的扩展优先级越高。因此上游 math() 的 mathFlow 总是先于本包的 mathCompatibility() 被尝试。

3. packages/client/ui-primitives/src/markdown/mathCompatibility.ts:325-330 的 sameLineDollarMathFlow 是 multiline = false：

   const sameLineDollarMathFlow = createMathFlow(
     codes.dollarSign, codes.dollarSign, codes.dollarSign, false,
   )

   它只在"上游 mathFlow 失败"时才会被用到，而上游 mathFlow 对任何 $$ 开围栏都成功（afterDollarOpen，mathCompatibility.ts:152-154，只有在开围栏后紧跟第二个 $ 时才 nok）。

4. 上游 mathFlow 允许开围栏行剩余内容作为 fence meta；mdast-util-math@3.0.0 将其写入 node.meta（enterMathFlowMeta / exitMathFlowMeta），而渲染端只读 node.value：render.tsx:338-339

   case 'math':
     return <Fragment key={key}>{renderTexToReact(node.value, true)}</Fragment>

   在整个 markdown 模块中搜索 .meta，只有 render.tsx 里的事件 metaKey 一处，没有任何地方读取 node.meta → 开首行公式静默消失。

5. 上游 mathFlow 的收尾围栏要求位于行首（其后仅允许空白），所以 c=d$$ 这种行中收尾不闭合，value 继续吞并后面的行。

6. 本包自己的 dollar flow 也帮不上多行场景：mathCompatibility.ts:156-169 的 content() 中

   if (markdownLineEnding(code)) {
     return multiline
       ? effects.attempt(nonLazyContinuation, afterContinuation, nok)(code)
       : nok(code)
   }

   multiline === false 时遇到换行直接 nok。（backslashMathFlow，mathCompatibility.ts:318-323，是 multiline = true，所以 \[ ... \] 多行是正常的 —— 这也说明多行支持本来就是设计意图，只是 dollar 分支漏了。）

7. 红色原文的出处：katex.tsx:66-90 的三臂链 —— katex.renderToString(value, { displayMode, throwOnError: true }) 抛错 → { strict: 'ignore', throwOnError: false }（KaTeX 自己用 errorColor 渲染错误，内容即原始源码）→ 兜底 <span className="katex-error" style={{ color: '#cc0000' }}>{value}</span>。

Suggested fix / 建议修复

两处改动需要同时应用：

--- a/packages/client/ui-primitives/src/markdown/parse.ts
+++ b/packages/client/ui-primitives/src/markdown/parse.ts
@@ -39,7 +39,7 @@
 export function parseGfmWithMath(text: string): Root {
   return recoverLocalImages(fromMarkdown(text, {
-    extensions: [gfm(), cjkFriendlyStrong(), mathCompatibility(), math()],
+    extensions: [gfm(), cjkFriendlyStrong(), math(), mathCompatibility()],
     mdastExtensions: [gfmFromMarkdown(), mathFromMarkdown()],
   }), text)
 }

--- a/packages/client/ui-primitives/src/markdown/mathCompatibility.ts
+++ b/packages/client/ui-primitives/src/markdown/mathCompatibility.ts
@@ -322,10 +322,10 @@
-const sameLineDollarMathFlow = createMathFlow(
+const dollarMathFlow = createMathFlow(
   codes.dollarSign,
   codes.dollarSign,
   codes.dollarSign,
-  false,
+  true,
 )
@@ -333,7 +333,7 @@
   flow: {
     [codes.backslash]: backslashMathFlow,
-    [codes.dollarSign]: sameLineDollarMathFlow,
+    [codes.dollarSign]: dollarMathFlow,
   },

（mathCompatibility.ts:281 里 name: ... ? 'sameLineDollarMathFlow' : 'backslashMathFlow' 建议一并改名。）

注意：两处必须同时改。实测"只把 multiline 改成 true"没有任何效果（该 construct 被上游 math() 抢先），"只交换数组顺序"也没有效果（提前的 dollar flow 仍然是 multiline = false）。

验证方式：在真实依赖（micromark 4.0.3、micromark-extension-math 3.1.0、mdast-util-math 3.0.0、mdast-util-from-markdown 2.1.0、katex）上把 mathCompatibility() 逐行移植后重建 parseGfmWithMath，对 13 个形状做改前/改后对照：只有 4 个"应当被修复"的形状发生变化（开首行带文本的多行块、块引用内的同类块、列表项内的同类块、公式块后接正文），其余全部保持一致 —— 未闭合 $$（仍按上游语义、meta 丢弃）、行内 $$a=b$$、连续两个单行块、\[ ... \]、代码围栏内的 $$、转义 \$$、单美元行内公式 $x+y$。

建议补测试：$$a⏎b$$、$$⏎a⏎$$、$$a$$ 三种写法都应得到 math 节点，且前两种的 meta 为 null、value 为完整内容。

Environment / 环境

• DSH 桌面端 0.2.0-rc.2（macOS，Electron 外壳）；文档预览由侧边栏 document preview 使用 @deepseek-ai/dsh-client-ui-primitives 渲染，聊天消息使用同一渲染器。
• markdown 相关依赖：micromark@4.0.3、micromark-extension-math@3.1.0、mdast-util-math@3.0.0、mdast-util-from-markdown@2.1.0、katex。
• 复现环境：Node v26.11.1，直接在上述依赖上重建 parseGfmWithMath 的扩展数组。

Impact / 影响面

这不是边角写法：Obsidian、Typora、MathJax 用户与 LLM 导出的数学笔记普遍采用"$$ 与公式同行起头 + 多行 + 行尾 $$ 收尾"。本地一个 vault 的统计：218 篇 markdown 笔记中 142 篇出现 $$ 围栏、139 篇含跨行 $$ 块（共 2227 个开围栏）；其中 6 篇的 30 个块（60 个围栏）使用了"开首行带公式 / 行尾收尾"的写法，改前触发 13 处 KaTeX 失败并输出红色原文，把围栏改成各自独占一行后降为 0。

Workaround / 临时规避

内容侧可以绕开：把开、收 $$ 各自独占一行，或写成单行 $$x$$，或改用 TeX 的 \[ ... \]（backslashMathFlow 已是 multiline = true）。但这需要用户批量改写自己的笔记，且渲染器对最常见的数学写法仍然是坏的，建议在渲染器侧修复。

[PerryLink]

渲染层的缺陷是真的，你也把 mathCompatibility 那一族扩展读得很细。但**"node.meta 被丢弃是主因"这条因果链不成立** —— 而且仓库里有一条测试正好证明同行开首的内容是能渲染的。所以你给的两处 diff 不能直接投，照投会打破既有测试。

1. ⚠️ 最关键：你的目标场景已经被测试钉成可用

packages/client/ui-primitives/tests/markdown.client.spec.tsx:398 的用例名就是：

…same-line tagged display blocks after the reply settles

:404 的输入：

'$$\\theta \\in \\left(\\frac{\\pi}{4}, \\frac{\\pi}{2}\\right). \\tag{1}$$'

:414-417 断言它渲染成 .katex-display、annotation 含 \tag{1}、且 .katex-error 为 null；同一段用例里紧跟一张 GFM 表格，并断言 expect(container.querySelector('.katex-error')).toBeNull() ⇒ 这一块既没有丢开首行，也没有吞掉后面的表格。

⇒ 「开首行内容静默消失」在这个形状上被证伪。 而你提的"交换 extensions 数组顺序"一旦真生效，会打破这条测试。

2. ⚠️ 第二处：「两种写法都出错」是以偏概全 —— 请先说明渲染臂

packages/client/ui-primitives/src/markdown/parse.ts:6-8 的模块头注释写明：$$ 块在 streaming 臂是 paragraph、settled 臂才是 math。

而你从头到尾没有说测的是哪一个臂。这一点决定了结论：

• 若你测的是文档预览的增量/streaming 臂，那你观察到的"吞并后续正文"很可能是中间态的固有表现（块还没闭合、下游内容自然还在该段落里），而不是渲染器把已闭合的块算错了；
• 只有 settled 臂的失败才是渲染缺陷。

建议补两样：① 明确臂与是否 streaming 中间态；② 给出一个最小 md 片段（把你那 144 行笔记缩到能复现的最短内容）+ 一张 settled 状态的截图。没有这两样，这条无法与上面那条既有测试共存。

3. node.meta 无人读 —— 这点你说对了，但它不是主因

我复核了（\.meta 与 metaKey 两个 pattern）：整个 src/markdown/ 里只有 render.tsx:561 的 event.metaKey，确实没有任何代码读 node.meta。

⇒ 这个观察是准的，但它解释不了"同一行的开首内容也能渲染"（第 1 节）。所以它是一个真实的死角，不是本症状的原因。建议把它作为独立的次要发现列出，不要当作根因。

4. 你读对的部分（保留）

下面这些行号与判断我都核过，逐条吻合：

• parse.ts:42 → extensions: [gfm(), cjkFriendlyStrong(), mathCompatibility(), math()],
• mathCompatibility.ts:325-330 → const sameLineDollarMathFlow = createMathFlow(codes.dollarSign, codes.dollarSign, codes.dollarSign, false,)
• mathCompatibility.ts:165-168 → return multiline ? effects.attempt(nonLazyContinuation, …) : nok(code)
• mathCompatibility.ts:318-322 → backslashMathFlow = createMathFlow(…, true,) ⇒ 多行本来就是设计意图，你的读法正确
• mathCompatibility.ts:152-153 → function afterDollarOpen(code) { return code === codes.dollarSign ? nok(code) : content(code) }
• render.tsx:338-339 → case 'math': return <Fragment key={key}>{renderTexToReact(node.value, true)}</Fragment>
• katex.tsx:66-90 的三臂链（throwOnError: true → strict: 'ignore', throwOnError: false → className="katex-error" style={{ color: '#cc0000' }}）—— 这正好解释你看到的红色原文
• mathCompatibility.ts:343-344 的注释亲口说明 math() 与兼容扩展必须同时注册

5. ⭐ 真正可以补的测试缺口（这条我建议你提）

packages/client/ui-primitives/tests/markdown-dom-parity.client.spec.tsx:220 的 parity fixture math-inline-and-display 用的是 '$$' / 公式 / '$$' 各占一行；而 $$a=b⏎c=d$$ 这种"开首行带文本 + 跨行 + 行尾 $$"的形态在 parity fixture 里没有覆盖。

⇒ 这是仓库真实存在的覆盖缺口，也是你那条诉求最容易被采纳的落点：

请把「开首行带文本 + 跨行 + 行尾 $$」定成一条先失败的用例，再改实现 —— 而不是先改 extensions 顺序。

6. 建议的诉求重写

1. 删掉"交换 extensions 数组顺序"这个具体 diff（它会打破 markdown.client.spec.tsx:398）；
2. 先说清渲染臂（parseGfm vs parseGfmWithMath）与是否 streaming 中间态；
3. 把诉求定为：为「开首行带文本 + 跨行 + 行尾收尾」这一形态补齐 parity 覆盖并修正行为（引用 markdown-dom-parity.client.spec.tsx:220 的缺口）；
4. node.meta 无人读单列为次要发现。

7. 内容侧可以立刻用的规避

$$ 独占行、或改用 \[ … \] —— 这两种写法在当前实现下是稳的（前者正是既有测试与 parity fixture 覆盖的形状）。在你的笔记里改这两处，症状应立刻消失；这也能反过来帮你确认到底是哪个形状触发的。

8. 边界

• 我核的是 origin/master = d743267388（= dsh-v0.2.1-alpha.2）上的 markdown/ 与两条测试。你写的是桌面端 0.2.0-rc.2 —— 上述文件请在你那侧的产物里对一遍再引用。
• ⚠️ 你实际测的是哪条臂、以及那个 144 行笔记的具体片段，我无法核实 —— 这正是第 2 节要你补的东西。渲染层是否有真实缺陷，取决于那个答案：我确认的是"你给的因果链与既有测试冲突"，不是"你看到的现象不存在"。

[Sc0re-16]

谢谢这么快来核，第 3、5 节我接受。先把两个最要紧的结论摆出来：（1）:398 那条测试测的不是我报的形状；（2）把 :398 的输入逐字跑一遍，交换顺序不会让它失败。

1. 先回答"哪条臂"：settled 臂

• 流式臂不注册 math：StreamingRenderer（bundle lib/index.js:11712-11713）用 new IncrementalMarkdownParser(parseGfm)，而 parseGfm 只挂 gfm() + cjkFriendlyStrong()（parse.ts:27-32；parse.ts:21-23 的注释就是 "no math, so incomplete TeX never flashes KaTeX errors mid-stream"）。
• settled 臂才是 renderSettled() → parseGfmWithMath(text)（bundle 11680-11681）。
• 所以中间态不会出现红字：KaTeX 只在 settled 臂被调用。

顺带修正我之前没说准的一点，正好回答"红字从哪来"：红字是第二臂打的，不是第三臂。第二臂 throwOnError:false 时 KaTeX 自己不抛，而是把出错片段包成

<span class="katex-error" title="ParseError: KaTeX parse error: Can&#x27;t use function &#x27;$&#x27; in math mode at position 4: c=d$̲$ …" style="color:#cc0000">c=d$$ …</span>

（实测输出，$̲$ 那个组合下划线就是 KaTeX 的错误标注）。第三臂只在连 strict:'ignore' 都抛的输入上兜底。

2. :398 覆盖的是"单行闭合"，不是"开首行带文本 + 跨行"

markdown.client.spec.tsx:404 的输入是一整行：

$$\theta \in \left(\frac{\pi}{4}, \frac{\pi}{2}\right). \tag{1}$$

$$、公式、收尾 $$ 同行 → 上游 mathFlow 在 fence meta 里遇到 $ 就 nok（meta 的 chunkString 不接受 $）→ 落到 sameLineDollarMathFlow 单行闭合。这条路本来就是好的，我的分析一开始也是这么预期的（报告里同形的 $$a=b$$ 被列在"内容侧可以绕开"）。

我报的形状是开首行 $$ 之后有内容、收尾 $$ 在后续某行的行尾：

$$a=b,\qquad
c=d$$

两者在 micromark 里是不同路径，:398 覆盖前者，证伪不了后者 —— 而后者正是你第 5 节指出 parity fixture 没覆盖的缺口。我们说的是同一件事。

3. 交换顺序会不会打破 :398：实测不会

把 :398 的 source 逐字喂给两套语法（mdast-util-from-markdown 2.1.0 + micromark-extension-math 3.1.0 + mdast-util-math 3.0.0 + katex；mathCompatibility 按 bundle 10432-10701 逐行移植，含 backslashMathText）：

• A（今天）：[gfm(), cjkFriendlyStrong(), mathCompatibility(), math()]
• D（提案）：[gfm(), cjkFriendlyStrong(), math(), mathCompatibilityMultiLineDollar()]

逐节点一致：

[A] katex total=6 (display 2/inline 4) red-katex-error=0 table=true
[D] katex total=6 (display 2/inline 4) red-katex-error=0 table=true
    math value="\theta \in \left(\frac{\pi}{4}, \frac{\pi}{2}\right). \tag{1}"  meta=null

:412-418 的六条断言（6 个 .katex、2 个 .katex-display、首个 display 的 annotation 含 \frac{\pi}{4}、末个 display 含 \tag{1}、.katex-error 为 null、表格内有 .katex）逐条满足；\(...\) 与 \[...\] 两套顺序下也都仍由兼容扩展接管（math() 不认识反斜杠 delimiter）。A 与 D 在这个输入上没有可观察差异，所以我没能复现"照投会打破 :398"。如果你们 CI 有别的失败点，把失败输出贴我，我按它改。

4. 缺口形状的证据（同一 harness）

前言。

$$a=b,\qquad
c=d$$

后文正常。

| A | B |
| --- | --- |
| $\alpha$ | $\beta$ |

[A] katex total=1 (display 1/inline 0) red-katex-error=1  table=false
    math value="c=d$$\n\n后文正常。\n\n| A | B |…"  meta="a=b,\qquad"   ->  ARM2 RED
[D] katex total=3 (display 1/inline 2) red-katex-error=0  table=true
    math value="a=b,\qquad\nc=d"             meta=null -> arm1 ok

A 这边不只是丢开首行：后面那张 GFM 表格连同 $\alpha$、$\beta$ 一起被吞进 math 的 value（table=false），这是它构成渲染缺陷、而非"中间态固有表现"的关键。真实笔记那段（$$ 开首行带 \cos\theta=…,\qquad，下一行行尾 \sin\theta=…=y$$）同样：A 触发第二臂红字，D 正常。

5. 按你的第 5、6 节收敛后的诉求

1. 诉求改成：为「开首行带文本 + 跨行 + 行尾 $$」补一条先失败的用例（挨着 parity fixture math-inline-and-display 加形状），再改实现；顺序 diff 不作为正式提案。但需要说明它为什么出现在原 diff 里：
2. 只把 dollar flow 改成 multiline、不换扩展顺序是无效的：micromark-util-combine-extensions 对后注册的扩展做 splice(existing, 0, 0, before)，所以 parse.ts:42 数组里更靠后的 math() 实际先被尝试；上游 mathFlow 一旦能把 $$ 开成块，兼容扩展就没机会，meta 照样被丢。两处要一起改，或者换机制（例如在 mdast 层消费 node.meta）。
3. node.meta 无人读（src/markdown/ 全域只有 render.tsx:561 的 event.metaKey）按你说的降级为独立次要发现，不再当根因。
4. 版本边界照办：我核的是桌面端 0.2.0-rc.2 产物，lib/index.js:10684 仍是 sameLineDollarMathFlow = createMathFlow(codes.dollarSign, codes.dollarSign, codes.dollarSign, false)，10699-10701 的 mathCompatibility() 返回的 text map 含 backslashMathText，与 master d743267388 的 mathCompatibility.ts:325 / :347-349 一致，行为无差异。
5. 最小片段见第 4 节，共 11 行，在当前实现下打开即为红字；文档预览的 settled 截图我随后补一张。

[Sc0re-16]

补上 settled 截图（右侧就是 DSH 的文档预览，打开的是 11 行最小复现文件 d9619-minimal-repro.md）：

图中可见：标题与 前言。 正常渲染；从第 4 行的 $$ 块开始，块的后半段 c=d$$ 连同其后的正文与表格一起被当作数学内容，KaTeX 报错后由 katex.tsx 的兜底分支原样输出为红色等宽文本（c=d$$ 后文正常。 | A | B | --- | --- | $\alpha$ | $\beta$）。这条路径走的是 settled 臂（renderSettled() → parseGfmWithMath，parse.ts:40-45），流式臂不注册 math（parse.ts:27-32），因此不是流式渲染的中间态。

[PerryLink]

你说得对，我上一条那条判断是错的，撤回。

我去把 :398 那条测试的输入逐行读了（新版 master，也就是 dsh-v0.2.1-alpha.3/alpha.4 那条线）。markdown.client.spec.tsx:399-409 里那段 source，:404 是：

'$$\\theta \\in \\left(\\frac{\\pi}{4}, \\frac{\\pi}{2}\\right). \\tag{1}$$',

单行，$$ 和 $$ 在同一行里闭合。你报的是跨行（$$a=b 换行 c=d$$），两者根本不是同一个形状。所以"你的场景已经被测试钉成可用"这句不成立——我引的那条测试确实没覆盖你报的情况，抱歉。

你的第（2）点我现在也能解释为什么你说得对。parse.ts:40-43 的注册顺序是：

extensions: [gfm(), cjkFriendlyStrong(), mathCompatibility(), math()],

而 mathCompatibility.ts:325 那个 dollar 流是这么建的：

const sameLineDollarMathFlow = createMathFlow(…, false)   // ← multiline = false

它是单行的，名字也直说了 sameLineDollarMathFlow（:281 那句 name: marker === codes.dollarSign ? 'sameLineDollarMathFlow' : 'backslashMathFlow'）。跨行的 $$ 块归最后注册的 math()（也就是 micromark-extension-math，parse.ts:17 的那个 import）。

所以交换数组顺序，动的是一个本来就不负责跨行块的流——那条测试自然不会红，你的问题也不会因此修好。这一层我上一条完全搞反了。

那个 settled 的回答很有用

你说是 settled 臂，而且流式臂根本不注册 math——这跟源码一致。parse.ts:6-8 的模块注释写得很清楚：

…so the arms differ only where TeX delimiters begin a math construct (a $$ block is a paragraph while streaming and a math block once settled, by design).

所以我上一条问"你测的是哪条臂"，答案就是 settled，这也把范围收窄了。

那接下来该看哪里

既然跨行块归 math()，我建议把观察点放在两个 dollar 流交接的地方：mathCompatibility 在 math() 之前注册，而它自己只认单行。如果一个跨行 $$ 的开头被前面那个流吃掉了一部分（或者它对 $$\n 这种开头返回了什么意料之外的状态），后面的 math() 就可能从一个错位的位置开始解析——这能对上你看到的"开首行内容丢失"。

不过这一步我没有跑，只是从注册顺序和 multiline: false 推出来的方向，不是结论。方法是现成的：mathCompatibility.ts:152 的 afterDollarOpen 和 :166 那个 multiline ? … : … 分支各打一次日志，跑你那份 11 行最小复现，就能看出是谁先吃了那几个字符。你手上已经有最小复现和截图，做这一步成本很低。

一点说明

我上一条依据的是别人给我的一份核实材料，我对它做了二次核对（行号和文件都对），但没有自己去看那条测试的输入内容——只看用例名就下了"它覆盖了你的形状"的判断，这是错的。这一条我记下了：用例名不能当断言内容用。

你截图里那段"从第 4 行的 $$ 开始，块的后半段 c=d$$ 连同其后的正文与表格一起被当作数学内容、KaTeX 报错后走 katex.tsx 的兜底分支原样输出成红色等宽文本"——这条链路跟 render.tsx 的 case 'math' 分支和那个三臂兜底是一致的，我核过，没问题。