writablestream 不能用于直接更新 dom，因其是异步字节流 sink，无 html 解析能力；正确做法是用 readablestream + textdecoderstream + htmlparser2 分块解析后调用 insertadjacenthtml。
HTML 中没有 WritableStream 接口的直接可用实现，浏览器不提供 WritableStream 用于写入 HTML 文档或 DOM 节点。 它是 Web Streams API 的一部分，但仅作为底层流构造器存在；你不能用它“写入页面”或“追加 HTML 字符串到 body”。常见误解是把它当作文本写入器（类似 Node.js 的 fs.createWriteStream），实际中它只配合 TransformStream 或 ReadableStream 构建管道，最终目标通常是下载、转发或转换字节流。
为什么不能用 WritableStream 直接更新 DOM
DOM 更新必须同步、结构化、符合 HTML 解析规则。而 WritableStream 是面向字节/块的异步 sink，它没有解析能力，也不触发重排或事件。尝试把 HTML 字符串 chunk 写入一个自定义 WritableStream，然后期望自动渲染——这不会发生。浏览器不会监听 WritableStream 的 write() 调用去 patch DOM。
-
WritableStream的write()方法只把数据推给它的内部 sink（比如 Service Worker 的响应体、StreamSaver.js的文件写入器），不是 DOM 操作入口 - 想动态插入 HTML，必须用
element.insertAdjacentHTML()、innerHTML +=（不推荐）或document.createElement()+appendChild() - 即便配合
TextEncoderStream，输出仍是Uint8Array，不是可执行的 DOM 操作
WritableStream 的真实适用场景：下载与代理
它真正起作用的地方是“离开浏览器”的数据出口：保存文件、转发请求、注入 Service Worker 响应。例如 StreamSaver.js 就是靠它把 fetch 流转成本地文件。
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
- 典型链路：
fetch().body→pipeThrough(new TextDecoderStream())→pipeTo(new WritableStream({ write(chunk) { /* 写入 Service Worker 缓存或触发 iframe 下载 */ } })) - 若目标是“边加载边显示 HTML”，正确做法是用
ReadableStream+TextDecoderStream+htmlparser2解析器，再手动调用insertAdjacentHTML插入已确认闭合的标签块 - 不要在
WritableStream.write()回调里操作 DOM：它可能被节流、延迟、甚至丢弃（如流被 cancel）
如何构建一个「类 ETL」HTML 流式处理管道（前端可行版）
虽然不能用 WritableStream 写 DOM，但你可以用 TransformStream 做中间清洗，再交由 DOM 操作消费。关键在于：解码、分块、语义化提取三步分离。
- 输入必须是
response.body（ReadableStream），不是字符串或innerHTML - 第一级 transform：用
new TextDecoderStream('utf-8')解码字节流，避免中文乱码 - 第二级 transform：自定义
TransformStream，按?[^>]+>或 htmlparser2 的Parser实例做 chunk 边界对齐，缓存未闭合标签（如<div> 卡在 chunk 末尾）<li>输出流交给 <code>reader.read()循环消费，每次拿到完整标签块后，用DOMParser.parseFromString(chunk, 'text/html')提取body.children，再 append 到目标容器 - 注意：
DOMParser不支持流，所以 transform 输出的必须是「可安全 parse 的字符串片段」，不能是半截标签 - 务必在 fetch 时显式设置
headers: { 'Accept': 'text/html' }，并依赖响应头的Content-Type: text/html; charset=utf-8，而非 HTML 内的<meta> - 使用
decoder.decode(chunk, { stream: true })，不能省略{ stream: true }，否则多字节字符（如 emoji、中文）跨 chunk 会崩 - 遇到
<script></script>标签时，必须等其闭合（或）才触发 DOM 插入，否则 script 执行上下文错乱 -
htmlparser2的parser.write()是安全的，但你要自己管理parser.end()时机——只有在reader.read().done === true后才能调
容易忽略的边界：编码、chunk 边界、script 标签阻塞
流式 HTML 处理失败，90% 出在三个地方：UTF-8 多字节字符被截断、<script></script> 开始但没结束、<meta charset> 出现在流中段导致后续 decode 错位。
真正能落地的流式 HTML 处理，从来不是靠 WritableStream 往页面“写”，而是靠可控的 chunk 拆分 + 安全的 DOM 构建节奏。别试图绕过浏览器解析器，要顺着它的工作方式设计流边界。
