微软开源 SwiftStreamingMarkdown，专治 AI 聊天界面卡顿

微软本周三在 GitHub 上甩出了一个叫 SwiftStreamingMarkdown 的开源库，MIT 协议，专门面向 iOS 平台，解决一个所有做过 AI 聊天 App 的人都吃过苦头的问题——大模型一边吐 token、UI 一边渲染 Markdown 的时候，主线程到底要怎么扛住。

这事说大不大，但凡做过 ChatGPT 风格客户端的开发者，多半都在 UITableView 或者 SwiftUI 的 List 里被这套组合拳教育过：模型每吐出几个字符，你就得把累计文本重新喂给 Markdown 解析器，解析器吭哧吭哧重建语法树，再把 AttributedString 推给 UI 重排版，滚动的时候顺便再卡一下。在 iPhone XS 这种几年前的中端机上，长回答跑下来掉帧几乎是肉眼可见的。

不是又一个 Markdown 渲染器

先把这个库的定位说清楚。市面上 Swift 生态里的 Markdown 渲染方案不算少，Apple 自家从 iOS 15 开始就在 AttributedString 里塞了 Markdown 解析，开源社区还有 MarkdownUI、Down、swift-markdown 等等。它们的共同假设是：你手上有一段完整的 Markdown 文本，渲染一次就完事。

SwiftStreamingMarkdown 解决的是另一个问题：文本是流着来的。这听起来像是个工程细节，但放到 LLM 场景里就是体验生死线。传统解析器每次接到新片段，都要对累计字符串做一次全量解析，因为你没法保证前一帧解析出来的 AST 在新字符到达后还成立——上一帧你以为是普通段落，下一帧突然冒出 ``` 把整段变成了代码块，结构完全不同。

微软的处理方式是把解析器本身做成增量的：随文本到达逐步推进，已经确定结构的部分不再重排，只对 "边缘 token"（也就是那个还在不停接收新字符的尾部块）做局部更新。配套的 UI 层 StreamedMarkdownView 会订阅一个异步数据源，每来一段就过一次增量管线，外加内置的过渡动画和滚动平滑处理。

说白了，思路跟去年 Chrome 团队推荐的 streaming-markdown 那套差不多，也跟阿里支付宝开源的 FluidMarkdown、社区那个 Incremark 是一个方向：把 Markdown 解析从 "全量重算" 改成 "追加式推进"，这是 AI 时代客户端渲染的新共识。微软只是把这套思路在 iOS 原生侧补齐了。

技术细节里值得拎出来说的几点

主线程负载控制

微软在 README 里给出了 iPhone XS 上的对比测试，号称在持续高负载流式推送场景下，主线程工作负载控制优于常见库。这个 "常见库" 没点名，但你掂量一下就知道大概率是直接拿 AttributedString 反复重算的那种朴素实现。

这里的关键不是峰值性能，而是滚动 + 增量更新同时发生时还能不能保住 60fps。聊天界面用户随时会上滑回看，这时候底部还在源源不断地追加新字符，UI 既要做内容增长引发的重排版，又要响应滚动手势，主线程一卡就是双重灾难。SwiftStreamingMarkdown 把解析这一步从主线程上拆出来、外加增量 diff，是从源头降负载。

语法支持的取舍

这个库的语法范围很坦诚地划在 CommonMark + GFM 的核心子集：

• 标题、段落、粗体、斜体、删除线
• 行内代码、围栏式代码块
• 链接（图片只显示 alt 文本）
• 引用块、有序/无序列表、分隔线
• 表格
• 行内和块级 LaTeX 公式
• 面向 LLM 的内联引用标记（source citation）

没实现的部分也挑明了：任务列表、脚注、高亮等扩展语法都不支持，遇到不认识的语法不会渲染错乱，而是降级为原始可读文本。这个 "降级显示" 的策略其实很务实——LLM 输出本来就有概率冒出奇奇怪怪的伪语法（特别是 GPT 偶尔会自创一些 HTML 标签），与其崩掉或者吞掉内容，不如直接秀给用户看。

那个面向 LLM 的内联引用标记是个比较有意思的点。Perplexity、ChatGPT Search 这些产品里那种 "句末带数字角标、点开能跳到原文" 的引用样式，过去都是各家自己拿正则切。微软把它做成了一类原生语法节点，意味着开发者只要让模型按约定的 token 格式输出，引用渲染就是开箱即用。这对接 RAG 应用的体验会舒服不少。

LaTeX 是亲儿子

数学公式渲染做成了一等公民。行内和块级都支持，配合流式推进——也就是说当模型还在写 \frac{a}{b} 的中间状态时，UI 不会先闪一段乱码再一次性切到正确公式，这部分体验微软显然下了功夫。技术教育、科研类聊天 App 应该会很欢迎这个特性。

可配置和钩子

样式系统用 MarkdownRenderConfig 统一配置，主题、字体、间距都能改，跟着 App 的设计语言走。MarkdownListener 协议则暴露了渲染生命周期事件和用户交互事件——这一点是给做产品分析的同学准备的。你想知道用户在回答的哪一段停下来选中了文字、点击了哪个链接、复制了哪段代码？协议钩子直接给你，不用自己在 view 上 hack 手势识别器。

iOS 上下文菜单（长按那个 "复制、分享、查询" 的菜单）也是原生支持，这点别小看，自己实现的话要踩不少 UIMenu API 的坑。

集成成本

部署成本非常低，Swift Package Manager 一行依赖搞定，给 App 增加约 3MB 体积。对一个能省掉自己造解析器、写动画、调主线程性能的库来说，这个体积在可接受范围内。如果你的 App 本来已经引了一套 Markdown 渲染方案，3MB 完全是替换成本里可以忽略的部分。

用法上，静态文本继续用 MarkdownView，流式场景换成 StreamedMarkdownView，绑定一个返回增量完整文本的异步数据源（注意是"逐步增量返回完整文本"，不是只返回新增片段，这一点要看清楚 API 约定，否则状态会乱）。

微软这一手放出来是什么意思

这两年大厂开源 AI 工程化的小工具节奏明显加快。前段时间支付宝把 FluidMarkdown 拿出来，Chrome 团队写了一长篇 streaming-markdown 的最佳实践，社区也涌出 Streamdown、Incremark 这类专门做增量解析的库。大家都看到了同一个事实：LLM 应用层的瓶颈正在从模型 API 转向客户端体验。

模型推理速度越快、token 吐得越密，前端的渲染压力反而越大。GPT-5、Claude Sonnet 4.5 这一代模型在高速通道下每秒能吐上百 token，传统全量解析直接被打爆。微软把 iOS 这一块补齐，背后逻辑跟它在 VS Code、Copilot 上做的事情一脉相承——它要把开发者构建 AI 体验的全栈基础设施握在手里。

国内开发者这边比较关心的是：iOS 原生这块过去基本没有现成轮子，要么自己拿 swift-markdown 改造，要么直接走 WKWebView 渲染 HTML，前者工作量大、后者性能和交互一致性都不理想。SwiftStreamingMarkdown 是第一个把 "流式 + 原生 + 性能" 三件事一次性给齐的方案。

如果你正好在做 iOS 上的 AI 聊天客户端，无论是接 OpenAI Hub 这种一个 Key 调全家桶的聚合服务（GPT、Claude、Gemini、DeepSeek 都走 OpenAI 兼容格式，省得自己适配各家 SDK），还是接自家的私有模型，前端这一块基本可以直接用这个库省掉一周的活。

几个仍然要自己操心的地方

吹完优点，也提几个开发者在落地之前要心里有数的点：

1. 仅 iOS 平台。macOS 暂时没提，跨平台的 Catalyst 能不能跑得看后续验证。Android 同学请绕道，得继续看 FluidMarkdown 或者自己造。
2. 语法子集。前面说了任务列表、脚注、高亮没实现。如果你的模型 prompt 里强依赖这些语法（比如带 checkbox 的 to-do 输出），要么改 prompt 要么自己补 patch。
3. 安全性。Chrome 团队那篇文章里反复强调要配 DOM sanitizer 防 prompt injection 注入恶意 HTML。SwiftStreamingMarkdown 在 iOS 原生侧不走 WebView，理论上 XSS 风险低，但如果你的语法配置允许了原始 HTML 或者用 WebView 渲染数学公式，依然要警惕模型被诱导输出可执行 payload。
4. "完整文本" vs "增量片段" 的契约。组件订阅的是逐步增量返回完整文本的数据源——也就是每次回调要拿到的是从头到目前为止的全部内容，不是 delta。LLM SDK 大多数情况下吐的是 delta，开发者要在数据层做一次累加再喂给 view，这个胶水代码别忘了写。

小结

SwiftStreamingMarkdown 不是什么颠覆性的新东西，它解决的是一个明确的、已经被多个团队各自踩过的工程问题。微软的版本做得相对完整：增量解析、原生动画、LaTeX、引用标记、上下文菜单、分析钩子一应俱全，MIT 协议拿来就能用。

对 iOS AI 应用开发者来说，这基本是当下流式 Markdown 渲染的默认推荐选项。后续值得关注的是社区会不会把它移植到 macOS、补齐缺失的 GFM 扩展，以及微软自家 Copilot for iOS 会不会切到这套渲染——如果切了，那就是最好的背书。

参考来源

• IT之家：微软开源 iOS 流式 Markdown 渲染库 — 微软发布 SwiftStreamingMarkdown 的首发报道，包含技术细节和性能测试结果
• 知乎专栏：支付宝开源移动端流式 Markdown 渲染引擎 FluidMarkdown — 同类思路的国产方案，可作为跨平台对比参考
• GitHub：ruanyf/weekly Incremark 自荐 issue — 社区另一款增量 Markdown 解析器的设计思路与性能数据