Show HN：Samemark 发布，兼容 remark-parse 的 Markdown 解析器，速度提升 10 倍

与 remark-parse 相同的 mdast，但快得多。

在线演示：一段很长的聊天回答分别流式渲染进 react-markdown（左侧）和 samemark/stream（右侧），每次更新的耗时都在你的浏览器中测量，并检查两个 DOM 是否完全一致， 还有一个 playground，在你输入时对比 samemark 的语法树与 mdast-util-from-markdown。

上面的录屏就是在线演示，录制于 GitHub Actions runner 上的无头 Chromium（录制运行 38066505899：250 次更新，左侧更新耗时 1.76 s，右侧 94 ms，全部 25 次检查中 HTML 完全一致）。在你自己的设备上数字会不同；它们是在你的浏览器中测量的。

samemark 是一个 markdown 解析器，它返回与 mdast-util-from-markdown 相同的 mdast 树，包含 GFM（即 remark-parse + remark-gfm 所产生的结果），并包含位置信息，对于任何它无法精确复现的内容，会回退到那个真正的解析器。

micromark 由 Titus Wormer 定义其行为；这个解析器与它保持一致， 并在必要时回退到它。它的测试套件和输出就是规范。

它是如何做出来的。大部分代码由 AI 智能体编写。每一处改动都会对照 micromark 自身的输出进行检查： 在数千份真实文档、CommonMark 规范示例以及数千万个生成的输入上，整棵树必须逐节点完全相等。这里没有任何东西 依赖于对作者或模型的信任；检查就在这个仓库里，运行它们的命令见下文。

你能得到什么

在真实的 unified 流水线中（用 remark-gfm、remark-rehype、rehype-stringify 把 markdown 转成 HTML），以 samemark 作为解析器时整个运行 快 6.2 倍到 10.3 倍，这是在 GitHub Actions runner（Node 24，7 轮取中位数，每个文件 HTML 完全一致）上对六个输入测得的。仅解析本身就快 28 倍到 47 倍；流水线的其余部分不变， 这就是端到端数字较小的原因。

在 Chromium 中把一段 30,000 字符的聊天回答流式渲染进真实 DOM 时，使用带记忆化块的 samemark/stream 相比 react-markdown 在每个分块时重新渲染整条消息， 主线程耗时少 60 倍，在 CPU 被限制 6 倍以模拟手机时少 77 倍（750 次推送从 79.4 s 降到 1.03 s；每次推送从 103 ms 降到 1.1 ms），且 DOM 相同。仅替换 react-markdown 内部的解析器就能快 5 倍到 6 倍。

构建一个 239 页的 Astro 站点，用 remark-parse 耗时 29.6 s，用 samemark 耗时 22.9 s（减少 23%）。

所有数字都来自同一次 CI 运行（38036885270），可用 npm run bench 复现。细节与方法：基准测试。

• parse(source) 返回的 mdast Root 与 fromMarkdown(source, {extensions: [gfm()], mdastExtensions: [gfmFromMarkdown()]}) 相等。
• remarkParseFast 可在 unified 处理器中直接替换 remark-parse。
• remark-gfm、remark-frontmatter（yaml、toml 或两者）和 remark-math（带或不带 singleDollarTextMath） 均已原生实现，可单独或一起使用。其他任何内容（remark-directive、MDX、自定义 frontmatter 围栏、 其他 micromark 扩展）都会被检测出来并交给真正的解析器。你得到的是 micromark 的答案，以 micromark 的 速度。
• 解析时不使用 micromark。快速路径只导入六个小型纯辅助包（四个 micromark-util-* 包加上 ccount 和 decode-named-character-reference），别无其他。mdast-util-from-markdown 仅在回退时需要，作为可选的对等依赖。

安装

npm install samemark
# for the fallback (recommended; the main entry imports it):
npm install mdast-util-from-markdown unified remark-gfm

Node 18 或更新版本，或任何支持 ES2020 和 TextDecoder 的运行时（浏览器、Deno、Bun、边缘运行时）。

用法

配合 unified 使用时，替换 remark-parse：

import {unified} from 'unified'
import remarkGfm from 'remark-gfm'
import remarkRehype from 'remark-rehype'
import rehypeStringify from 'rehype-stringify'
import remarkParseFast from 'samemark'

const file = await unified()
  .use(remarkParseFast) // instead of remark-parse
  .use(remarkGfm)
  .use(remarkRehype)
  .use(rehypeStringify)
  .process('# Hello *world*')

在已经安装了 remark-parse 的框架中（Astro、MDX、Next.js 插件），把它加入 remarkPlugins； 它会在 remark-gfm 注册之后替换解析器，这正是它需要的顺序：

// astro.config.mjs
import remarkParseFast from 'samemark'
export default {markdown: {remarkPlugins: [remarkParseFast]}}

配合 react-markdown 使用时（它在每次渲染时都会构建一个 unified 处理器，且 remark-parse 排在最前，因此设置解析器的插件会接管；已由下面的基准测试验证）：

import Markdown from 'react-markdown'
import remarkGfm from 'remark-gfm'
import remarkParseFast from 'samemark'

const plugins = [remarkParseFast, remarkGfm] // define once, outside the component

export const Answer = ({text}) => <Markdown remarkPlugins={plugins}>{text}</Markdown>

聊天应用在每次流式传输 token 时都会重新渲染整条消息，因此解析器每次都要在一个不断增长的字符串上重新运行；参见 Benchmarks 中的 react-markdown 数据。

没有处理器时：

import {parse} from 'samemark'
const tree = parse('# Hello *world*') // mdast Root

条目

主入口还会对每个处理器运行一次性检查：用处理器自身的扩展，由两个解析器分别解析三个小文档；任何差异都会将该处理器送入回退（原因："self-check ... failed"）。这可以防范某个改变行为的 micromark 版本。它是一道绊线，而非证明。

选项

parse(source, options) 和 remarkParseFast(options) 都接受：

parse 还额外接受 extensions 和 mdastExtensions（即你会传给 fromMarkdown 的数组）。省略时，假定为标准 GFM。source 可以是字符串、Uint8Array（UTF-8）或带有 toString() 的对象。

没有人应该在性能分析器里才发现回退。stats 由两个入口导出：

import {stats, check} from 'samemark'
stats // {fast: 120, fallback: 0, lastFallbackReason: null}
check(micromarkExtensions, fromMarkdownExtensions) // null when the fast path is exact, else the reason

面向聊天 UI 的流式处理

聊天 UI 在每次 token 到达时都会重新解析整条消息。以 samemark 作为解析器时，这种重新解析根据运行时的不同便宜 3 到 7 倍，且输出完全相同（react-markdown 数据见 Benchmarks）。samemark/stream 消除了重新解析：它是增量的，并且与解析整段文本完全一致。

import {createStreamParser} from 'samemark/stream'

const stream = createStreamParser()          // options: {frontmatter, math}, same meaning as remark-frontmatter / remark-math
for await (const chunk of tokens) {
  const tree = stream.push(chunk)            // mdast Root, equal to parse(everything pushed so far), positions included
  render(tree)
}
stream.end()                                 // final tree; stream.reset() starts a new message

• 每次 push 之后，树都等于 parse() 对目前所有文本返回的结果，也等于 micromark 的树。分块可以拆分任何内容：一个 token、一个围栏、一个表格行、一个链接。
• 不再可能改变的块在每次 push 之间保持其对象标识（未完成的尾部会重新解析，其余部分被复用），因此以节点为键的 React.memo 会跳过它们。一次 push 的成本是新文本加上未完成的尾部，而不是整条消息。
• 后面的引用或脚注定义可能会改变前面块的解析方式；受影响的块会作为新对象重建，因此标识恰好在内容可能已改变时发生变化。
• 支持标准 GFM，可选 frontmatter 和 math。对于其他扩展，请使用主入口解析整条消息。也支持从 CommonJS 使用 require('samemark/stream')。

React 集成位于 examples/react-chat/StreamMarkdown.jsx：一个 useMarkdownStream() hook 和一个 <StreamMarkdown tree> 组件，用 mdast-util-to-hast 和 hast-util-to-jsx-runtime 渲染 mdast，每个顶层节点对应一个记忆化块，应用与 react-markdown 相同的 URL 清理和原始 HTML 处理。对于整条消息，其 HTML 与 react-markdown 相同（test/stream.test.mjs，以及下方 Chromium 基准测试中的 DOM 比较）。

import {StreamMarkdown, useMarkdownStream} from './StreamMarkdown.jsx'

function Answer({tokens}) {                  // tokens: an async iterable of strings
  const {tree, push, reset} = useMarkdownStream()
  useEffect(() => {
    reset()
    ;(async () => { for await (const chunk of tokens) push(chunk) })()
  }, [tokens])
  return <StreamMarkdown tree={tree} />
}

流式成本

仅解析器，来自 CI 中的 node bench/stream-bench.mjs（ubuntu-latest，每次 push 12 个字符，生成的 LLM 风格回答）：推送整个回答的总时间，每次 push 完整重新解析对比 createStreamParser。

该解析器在 CI 中的身份：465,378 个文档上共 48,196,453 次推送（语料重放、模糊字符串、1 字符、随机、类 token 和整行分块，带或不带 frontmatter 和数学公式），每棵树都与完整解析结果进行比较；0 失败。

包含 React 渲染（DOM 提交、记忆化块）：

来自 CI 运行 38036885270（Chromium，GitHub Actions runner）；在本地用 npm run bench:stream（jsdom，数字更小）复现，或运行 bench 工作流。

一条聊天消息以每次推送 40 个字符的速度流式写入一个真实 DOM 节点（Chromium 156.0.8078.4，React 19 生产版，每次推送 flushSync，因此每次推送都是解析 + React 渲染 + DOM 提交；不包括布局和绘制）。(a) react-markdown 每次推送重新渲染整条消息，(b) 相同但使用 samemark 作为解析器，(c) 带逐块记忆化的流式解析器（examples/react-chat）。“Total”是主线程上所有推送时间的总和。最终推送后以及每第 25 次推送后的 DOM 与 (a) 进行比较：最后一列。

环境：Node v24.21.0，GitHub Actions ubuntu24 X64（github 托管），INTEL(R) XEON(R) PLATINUM 8573C x4，linux x64。每个单元格是 1 轮预热后 7 轮的中位数，每个单元格使用一个全新进程。

(a) 是当今聊天 UI 的做法：react-markdown 在每次推送时重新解析并重新渲染整条消息。(b) 仅替换解析器。(c) 是 examples/react-chat。

示例

每个片段都针对此仓库运行；unified、frontmatter 和 fallback 示例打印所示内容。

unified 管道（markdown 转 HTML）：

import {unified} from 'unified'
import remarkGfm from 'remark-gfm'
import remarkRehype from 'remark-rehype'
import rehypeStringify from 'rehype-stringify'
import remarkParseFast from 'samemark'

const file = await unified()
  .use(remarkParseFast)
  .use(remarkGfm)
  .use(remarkRehype)
  .use(rehypeStringify)
  .process('# Hello *world*\n\n| a | b |\n|---|---|\n| ~~x~~ | y |')
console.log(String(file))
// <h1>Hello <em>world</em></h1>
// <table> ... <td><del>x</del></td> ... </table>

react-markdown，改一行：

import Markdown from 'react-markdown'
import remarkGfm from 'remark-gfm'
import remarkParseFast from 'samemark'

const plugins = [remarkParseFast, remarkGfm] // module level: not recreated per render
export const Answer = ({text}) => <Markdown remarkPlugins={plugins}>{text}</Markdown>

使用 samemark/stream 的流式聊天。 在 React 中使用 examples/react-chat（实时演示运行它）。不使用框架时：

import {createStreamParser} from 'samemark/stream'

const stream = createStreamParser()
let tree
for (const chunk of ['# Hel', 'lo\n\nSome **bo', 'ld** text\n\n- a\n- b\n']) {
  tree = stream.push(chunk) // same tree as parse(everything so far); finished blocks keep their identity
}
console.log(tree.children.map(node => node.type)) // [ 'heading', 'paragraph', 'list' ]

Astro：

// astro.config.mjs
import remarkParseFast from 'samemark'
export default {markdown: {remarkPlugins: [remarkParseFast]}}

Frontmatter 和数学公式保持在快速路径上：

import remarkFrontmatter from 'remark-frontmatter'
import remarkMath from 'remark-math'
import {stats} from 'samemark'

const file = await unified()
  .use(remarkParseFast)
  .use(remarkGfm)
  .use(remarkFrontmatter)
  .use(remarkMath)
  .use(remarkRehype)
  .use(rehypeStringify)
  .process('---\ntitle: Notes\n---\n\nEuler: $e^{i\\pi}+1=0$\n')
console.log(String(file)) // <p>Euler: <code class="language-math math-inline">e^{i\pi}+1=0</code></p>
console.log(stats)        // { fast: 1, fallback: 0, lastFallbackReason: null }

samemark 将数学公式解析为与 remark-math 相同的 inlineMath 和 math 节点；排版是渲染器的工作，与 remark-parse 完全一样。在 remark-rehype 之后添加 rehype-katex（或 rehype-mathjax）以将它们转换为方程式：

import rehypeKatex from 'rehype-katex'

unified().use(remarkParseFast).use(remarkGfm).use(remarkMath).use(remarkRehype).use(rehypeKatex).use(rehypeStringify)

浏览器中的 samemark/core（无 fallback 导入；browser 构建约 20 KB gzip 后，见 Bundle size）。它需要一个遵循包 exports 的打包器，例如 esbuild 或 Vite：

import {parse} from 'samemark/core'

const tree = parse('# Hello *world*') // mdast Root, GFM

检查 fallback，以免有人在 profiler 中发现一个：

import remarkDirective from 'remark-directive'
import remarkParseFast, {stats} from 'samemark'

const reasons = []
await unified()
  .use(remarkParseFast, {onFallback: reason => reasons.push(reason)})
  .use(remarkGfm)
  .use(remarkDirective) // not in the supported set: the real parser takes over
  .use(remarkRehype)
  .use(rehypeStringify)
  .process(':::note\nhi\n:::')
console.log(reasons) // ['micromark extension not in the supported set (GFM, frontmatter, math): ...']
console.log(stats)   // { fast: 0, fallback: 1, lastFallbackReason: '...' }

传入 {strict: true} 以抛出错误而不是回退。

兼容性

确切声明。快速路径仅针对这些固定版本进行验证（package.json devDependencies，由 npm ci 安装）：

其他版本不在声明范围内。若新版 micromark 改变了输出，主入口的自检会捕获到（随后使用回退方案），本仓库中的 npm test 也会捕获到——如果标准 GFM 构造集发生变化，该检查就会失败（node scripts/gen-signature.mjs --check）。

是否算作受支持由构造名称决定，而不是由函数源码决定，因此 micromark 的压缩打包版本仍能走快速路径（已用包含 frontmatter 和 math 扩展的 esbuild --minify 打包版本测试过）。隐藏在闭包中的设置（singleTilde: false、singleDollarTextMath: false，即 frontmatter matter 所使用的围栏，anywhere: true）通过在探测字符串上运行真正的分词器来读取；结果会与标准配置的行为进行比较。任何未知构造、任何 disable 条目、自定义或 anywhere frontmatter matter，或缺少 GFM 组件，都意味着回退。

哪些配置会走快速路径

由 node scripts/compat-table.mjs 从 npm test 所断言的相同用例生成（每个快速行还会在一个能触发它的文档上与 remark-parse 进行比较）：

框架。Astro（纯 markdown，remark-gfm 默认）：快速。Starlight 为旁注添加了 remark-directive，因此会回退，得不到任何好处。Docusaurus 和 MDX 通过 micromark-extension-mdxjs 编译：回退。@mdx-js/mdx 搭配 format: 'md' 和 remark-gfm：快速。

如何验证一致性

一眼看正确性（每一行都将完整树，包括位置，与 mdast-util-from-markdown + GFM 进行比较；细节和命令见下表）：

“完全相同”指 JSON 相等的树，包括每个 position，而非“看起来一样”（firstDiff 在 bench/common.mjs 中；undefined 字段视为不存在）。

第三方文本从不提交。文档语料库在固定提交处获取（许可证：Node.js、Vite 和 React 为 MIT，Rust 书为 MIT 或 Apache-2.0，GFM 规范示例为 BSD-2-Clause 代码及 CC-BY-SA 规范文本）， README 语料库通过 sha256 清单从 npm 重建，合成语料库由种子生成。

已知差异

在测试集（规范示例、语料库、留出集、边缘输入）上没有差异。差分模糊测试确实发现了 存在差异的形态，都是围绕脚注定义和列表的块级角落；它们连同最小 输入列在 KNOWN_GAPS.md 中，目前尚未出现在真实文档中。身份声明未覆盖的内容： 非 GFM 扩展（按设计回退）、非字符串输入类型，以及兼容性表中未列出的其他流水线。

故意表现不同的行为：micromark 在大约 10,000 层嵌套时会抛出 RangeError；samemark 则能解析它。大型单一输入：micromark 的耗时随文档大小增长快于线性（在快速笔记本电脑上，一个混合文档在 400 KB 时为 1.6 秒，800 KB 时为 5.1 秒，1.6 MB 时为 19 秒；一个 500 KB 的内联标记段落需要 16 秒；一次 10 MB 的对比运行了 42 分钟并耗尽了 6 GB 堆内存），而 samemark 解析一个 10 MB 的混合文档大约只需 0.4 秒。这就是为什么边缘测试中的全树对比止步于 2 到 3 MB，而 10 MB 的用例只检查 samemark 能完成且不抛出异常。

基准测试

哪些数字来自哪个输入。 下表由 bench 工作流（以及解析器级别的流式基准测试由 bench/stream-bench.mjs）在该项目还位于私有仓库时生成。名为“README 语料库”的行运行在包含 4,780 个文件的 npm 包 README 开发语料库上（较慢的测试使用 1/4 或 1/16 的抽样；其中 4,648 个文件可从 bench/readme-corpus-manifest.json 重建）。以仓库命名的行（node-api-docs、rust-book、vite-docs、node-changelog-v22、react-changelog）运行在 bench/corpora.json 中固定的提交上；任何人都可以用 npm run corpus 精确获取这些提交。react-markdown 表格使用生成的聊天风格回答（bench/perf/chat-text.mjs），Astro 站点使用三个文档集，而在全新检出上运行 npm run bench 会测量固定的文档集加上合成语料库（以及重建后的 README 语料库，使用 --readme）。运行器 CPU 因任务和运行而异，因此请比较同一表格内的比率，而不是跨表格的绝对时间。

环境：Node v24.21.0，GitHub Actions ubuntu24 X64（github 托管），AMD EPYC 7763 64 核处理器 x4，linux x64。每个单元格是 7 轮（在一轮预热之后）的中位数，每个单元格使用一个全新进程。

端到端：使用 unified 将 markdown 转换为 HTML

unified().use(parser).use(remarkGfm).use(remarkRehype).use(rehypeStringify)，使用 remark-parse 或使用 samemark 作为解析器。输出 HTML 逐文件比较。

内容流水线，如文档或博客站点运行的方式：remark-gfm、remark-frontmatter（yaml）以及 remark-rehype 之前的 remark-math。vite-docs 的每个页面都有真实 frontmatter；合成（或 README）文档会获得一个生成的块，因此每个文件都有一个。两侧在 HTML 上进行比较。

作为参考，同一输入上的其他转换器（不同的流水线和输出：HTML 字符串，无 mdast，不是直接替代品）：

环境：Node v24.21.0，GitHub Actions ubuntu24 X64（github 托管），AMD EPYC 7763 64 核处理器 x4，linux x64。每个单元格是 7 轮（在一轮预热之后）的中位数，每个单元格使用一个全新进程。

react-markdown（桌面端，Node，renderToStaticMarkup，React 生产构建）

react-markdown 10.1.0 在每次渲染时都会构建一个新的统一处理器（unified().use(remarkParse).use(remarkPlugins)...），因此 remarkPlugins={[remarkParseFast, remarkGfm]} 在每次渲染时都会替换其解析器。输入是一个合成的聊天风格回答（标题、列表、代码、表格、链接；bench/perf/chat-text.mjs）。输出 HTML 在 120 个前缀长度上进行比较，包括不完整的结构：120/120 完全相同。samemark 路径：6148 次快速，0 次回退。

在固定消息长度下的一次更新（这也是渲染一条已完成长回答的成本）：

流式模拟：消息每次增长几个字符，并且每一步之后都会重新渲染整条消息，正如聊天应用所做的那样：

Chromium 中的 react-markdown，CPU 降速作为手机代理

Chromium 156.0.8078.4，react-markdown 10.1.0 生产包，页面中的 renderToStaticMarkup。CPU 降速使用 DevTools Emulation.setCPUThrottlingRate（主线程 4 倍和 6 倍降速）。这是对较慢设备的代理，而不是对某台设备的测量。与桌面表格相同的聊天风格输入；这里的流式步骤为 100 个字符，以保持降速运行时间较短。

将一条 30,000 个字符的回答流式写入 DOM

一条聊天消息以每次推送 40 个字符流式写入真实 DOM 节点（Chromium 156.0.8078.4，React 19 生产环境，每次推送 flushSync，因此每次推送都是解析 + React 渲染 + DOM 提交；不包括布局和绘制）。(a) react-markdown 每次推送重新渲染整条消息，(b) 使用 samemark 作为解析器的相同情况，(c) 带有逐块记忆化的流式解析器（examples/react-chat）。“总计”是主线程上所有推送时间的总和。最终推送后以及每第 25 次推送后的 DOM 与 (a) 进行比较：即最后一列。

环境：Node v24.21.0，GitHub Actions ubuntu24 X64（github-hosted），INTEL(R) XEON(R) PLATINUM 8573C x4，linux x64。每个单元格为 1 轮预热后 7 轮的中位数，每个单元格使用一个全新进程。

仅解析

两侧使用相同的 mdast（mdast-util-from-markdown 使用 micromark-extension-gfm 和 mdast-util-gfm，即参考实现）。"Identical" 统计的是完整树（包括位置信息）相等的文件。

同一输入上的其他解析器。输出不同：markdown-it 返回 token 列表，marked 返回自己的 token 树，两者都不是 mdast，也都不是可直接替换的替代品。此处仅用于展示规模。

环境：Node v24.21.0，GitHub Actions ubuntu24 X64（github-hosted），AMD EPYC 7763 64-Core Processor x4，linux x64。每个单元格为 1 轮预热后 7 轮的中位数，每个单元格使用一个全新进程。

MDX（@mdx-js/mdx compile）

纯 format: 'md' 搭配 remark-gfm，默认解析器对比以 samemark 作为解析器。format: 'mdx' 会加载 micromark-extension-mdxjs，而它不在标准 GFM 集合中，因此 samemark 按设计在此处回退；它是在有效 MDX 的文件上测量的，以表明开销为零。比较的是编译输出。

真实站点：Astro 6.4.8 构建 239 个真实 markdown 页面

rust-book、vite-docs、node-api-docs（6.53 MB 的 markdown），标准 Astro markdown 流水线（remark-parse、remark-gfm、smartypants、Shiki、rehype-raw）。每次均为冷构建（移除 dist、.astro 和 Vite 缓存），每个变体交替构建 3 次，显示中位数，Node v24.21.0，AMD EPYC 7763 64-Core Processor x4。

构建时间节省：6.7 s（22.7%）。解析器时间节省：6.57 s。

各次构建（s）：默认 29.2、29.6、29.7；samemark 22.7、22.9、23.3。

解读 react-markdown 的数字。每次更新的加速比小于仅解析的数字，因为 React 渲染和 hast 到 JSX 的步骤没有变化。它因运行时而异：Node 6.5x 到 7.0x，未限速的 Chromium 4.8x 到 5.4x，限速的 Chromium 5.3x 到 6.6x。我没有经过验证的解释来说明为什么该比率在 CPU 限速下会增大（限速会减慢主线程；垃圾回收和编译线程不会以同样的方式被减慢，这只是猜测，不是测量结果）。绝对数字才是实际结果：在 6x 限速下，一个完成的 30,000 字符答案渲染耗时 35 ms 而不是 200 ms。

复现：

npm ci
npm run bench:small   # a few seconds: the synthetic corpus sample plus one changelog, laptop sized
npm run bench         # the full run (what CI ran), fetches the pinned documents first

npm run bench 打印出上面的确切表格。方法：每个单元格都是一个全新的 Node 进程（独立的 JIT 和堆）， 一轮预热，然后对输入的所有文件取指定轮数的中位数；轮次之间强制 GC； 在报告计时之前，比较双方输出是否完全一致（否则运行失败）。 markdown-it 和 marked 仅用于规模对比：它们生成 token 或 HTML，而非 mdast，且并非可直接替换。 文档：bench/corpora.json 固定了每个集合的仓库、提交和 sha256。

打包体积

使用 esbuild 压缩，ESM，平台中立。node scripts/size.mjs 复现了该表格。

browser 行是打包器为浏览器生成的产物：decode-named-character-reference 随后通过 DOM 解码实体，而不是附带其 35 KB 的表。边缘运行时（workerd、worker、edge-light、deno）则使用该表。

适用场景

Sätteri，这个作为 Astro 7 默认 markdown 处理器的 Rust 引擎，在其文档中表示它 “并非 unified 的直接替代品”，并且现有的 remark 和 rehype 插件无法未经修改地运行。samemark 面向那些继续使用 unified 的项目：相同的 mdast，现有插件无需改动即可运行， 而且它是纯 JavaScript，没有原生二进制文件。

致谢

• micromark、mdast-util-from-markdown 以及 GFM 扩展由 Titus Wormer 及贡献者定义了这个解析器所复现的行为，并提供了 它导入的辅助包（micromark-util-*、ccount、decode-named-character-reference）。
• CommonMark 规范及其示例。
• unified 和 remark。

许可证

MIT。dist/core.cjs 中打包代码的第三方许可证见 dist/LICENSES.txt。