写在前面：一个流式输出的前端问题
引子：从一道面试题说起
“假设 AI 正在流式输出一段 Markdown，你如何实现页面不闪烁？”
这是我最近在不同技术社区频繁看到的一道面试题。问法各异，但核心指向同一个技术命题：
- 有候选人回答：用
marked.js每段 parse 一下 - 面试官追问：那加粗
**和j同时到达时，页面为什么会闪？ - 候选人沉默，面试结束
这个故事并非虚构。随着 AI 应用井喷式爆发，“流式 Markdown 渲染”已经从一个小众的边缘场景，变成了每个 AI 前端团队必须面对的核心基础问题。
我们所处的时代背景
2023 年 ChatGPT 横空出世，带火了“流式输出”这个交互模式。到 2026 年，几乎所有 AI 应用——对话机器人、代码生成器、AI 写作助手、智能客服——都在使用流式传输。
用户体验的评判标准也随之改变：
旧标准：内容正确即可。
新标准：逐字流畅、无闪烁、无卡顿、像真人打字一样丝滑。
这个看似简单的诉求，背后却涉及：
- HTTP/SSE/WebSocket 协议的理解
- 浏览器渲染机制与性能优化
- Markdown 语法规范的深度剖析
- 有限状态机的设计模式
- 生产级架构的分层设计
- 开源工具链的选型与集成
这是一个打通“前端基础知识”与“AI 应用实战”的绝佳工程场景。
这个系列能给你带来什么？
市面上的技术文章，要么只讲“怎么用 Streamdown”，要么只讲“为什么闪烁”，很少有系统性地、从 P5 到 P7 逐层递进地讲透整个问题域。
这个系列不同：
① 追根溯源，讲透本质
第 1 篇会回答：为什么“每段 parse”一定会闪？从 Markdown 语法特性、流式数据结构到浏览器 DOM 更新机制，一次性讲清楚。
② 逐层递进，覆盖 P5 到 P7
这不是一篇“科普文”，而是一套完整的工程化认知升级路径：后续下面五篇文章会陆续更新，目前可能点击找不到，说明还没有发布，请关注，及时接收到后续通知
| 篇目 | 核心 | 地址 |
|---|---|---|
| 读完第 1 篇 | 你理解了问题的本质 | 审阅 |
| 读完第 2 篇 | 你能手写一个缓冲渲染器 | 审阅 |
| 读完第 3 篇 | 你能用状态机解决代码块难题 | 审阅 |
| 读完第 4 篇 | 你掌握了 2026 年的标准化工具链 | 审阅 |
| 读完第 5 篇 | 你具备构建生产级架构的能力 | 审阅 |
③ 有理论，有代码，有场景
每一篇都包含：
- 问题驱动：从一个真实场景出发
- 原理剖析：为什么会出现这个问题
- 方案落地：完整的可运行代码
- 局限分析：这个方案解决不了什么
④ 对标职级，看到成长路径
每篇文章标注了对应的职级水平（P5 → P5+ → P6 → P6+ → P7），让你清晰看到自己在什么阶段，下一步该往哪里走。
本系列适合谁读？
- ✅ 正在开发 AI 对话应用的前端工程师
- ✅ 准备面试大厂、想系统提升工程能力的求职者
- ✅ 对浏览器渲染性能感兴趣的技术爱好者
- ✅ 想从“写页面”升级到“做架构”的进阶开发者
如果你属于以上任何一类，这个系列值得你花时间读完。
关于我为什么写这个系列
在过去的两年里，我深度参与了多个 AI 产品的研发，每一次上线都伴随着流式 Markdown 渲染的踩坑和重构。从最初的“能用就行”，到后来的“极致体验”，我走过很多弯路，也积累了不少经验。
如今，AI 应用已经从“新奇玩具”变成“生产力工具”，用户对体验的要求只会越来越高。流式渲染的稳定性、流畅度、性能，不再是“锦上添花”，而是“生死线”。
我希望把这些经验系统性地整理出来，让后来者少踩一些坑，也让这个领域有一个相对完整的技术参考。
系列开篇，我们从一个最简单的例子开始。
下一章，你将看到一段只有 3 行的 Markdown，如何在流式传输中引发页面“地震”——以及，这背后到底发生了什么。
第 1 篇预告：问题的本质——为什么“每段 parse”会闪？
