CompressionStream 不能直接压缩 DOM 状态快照，需先采集（如 outerHTML、scroll、input 值等）、再序列化为 JSON 并转为 Uint8Array 流，最后通过 CompressionStream 压缩传输，服务端须支持 gzip 解压且正确设置 Content-Encoding 和 Content-Type。
CompressionStream 本身不适用于直接压缩 DOM 状态快照，它是一个用于压缩 ReadableStream 数据流（如 fetch() 响应体、文件读取流）的底层 Web API，不能处理 DOM 树、JavaScript 对象或内存中的状态结构。所谓“原始 DOM 状态快照”，本质是运行时内存中的一组可序列化对象（如 document.documentElement.outerHTML、window.getComputedStyle() 结果、事件监听器元信息等），需先采集 → 序列化 → 编码 → 流式压缩 → 传输，而非对 DOM 节点本身调用 CompressionStream。
下面分三步说明如何合理、高效地完成这一目标：
采集 DOM 快照：轻量、可控、可复现
避免全量 innerHTML 或递归遍历所有节点（易漏样式、伪元素、shadow DOM）。推荐组合方式：
- 使用
document.documentElement.cloneNode(true)获取结构副本，再移除非必要属性（如on*事件、data-*中的临时 ID） - 补充关键运行时状态：
-
getComputedStyle(element)提取计算后样式（仅对可见/关键元素） -
window.scrollX/Y、document.activeElement?.id、input.value等交互态字段
-
- 排除不可序列化内容（如函数、
NodeList、Window引用），用JSON.stringify()预检是否可序列化
✅ 示例精简采集逻辑：
const snapshot = { html: document.documentElement.outerHTML, scroll: { x: window.scrollX, y: window.scrollY }, activeId: document.activeElement?.id || '', inputs: Array.from(document.querySelectorAll('input, textarea, select')) .reduce((acc, el) => ({ ...acc, [el.name]: el.value }), {}) };
序列化与流式压缩：用 CompressionStream 真正起效的位置
将采集后的 JS 对象转为字节流，再接入压缩管道：
- 先用
JSON.stringify(snapshot)得到字符串 - 转为
Uint8Array（UTF-8 编码）：new TextEncoder().encode(str) - 构造
ReadableStream并接入CompressionStream("gzip") - 直接
.pipeTo()到WritableStream（如fetch()的请求体）
✅ 完整压缩传输链路：
async function sendCompressedDOMSnapshot() {
const snapshot = await captureDOMState(); // 上一步封装的采集函数
const json = JSON.stringify(snapshot);
const encoder = new TextEncoder();
const stream = new ReadableStream({
start(controller) {
controller.enqueue(encoder.encode(json));
controller.close();
}
});
const compressedStream = stream.pipeThrough(
new CompressionStream("gzip")
);
await fetch("/api/snapshot", {
method: "POST",
body: compressedStream,
headers: { "Content-Encoding": "gzip" }
});
}
⚠️ 注意：服务端必须支持解压 Content-Encoding: gzip，且明确声明 Content-Type: application/json。
传输与服务端协同：避免“压缩了但白费”
前端压缩只是半程——若服务端未配置对应解压中间件，请求体将被当作乱码拒绝。关键协同点：
- 请求头必须带
Content-Encoding: gzip（浏览器不会自动加，需手动设置） - 后端框架需启用 gzip 解析（如 Express +
express.raw({ type: 'application/json', limit: '50mb' })+ 自定义解压中间件） - 若使用 CDN 或网关（如 Nginx、Cloudflare），确认其未在转发前解压并丢弃编码头
- 对超大快照（>10MB），考虑分块压缩（
TransformStream分片）+ 断点续传，而非单次流
? 实测建议：
- 小快照（JSON.stringify + CompressionStream，延迟增益明显（压缩率 60–80%）
- 大快照（>5MB）：先
structuredClone()深拷贝防冻结，再分批序列化+压缩，避免主线程卡顿- 避免在
requestIdleCallback中做压缩——CompressionStream是异步但非空闲感知，仍可能抢占渲染帧
不复杂但容易忽略：CompressionStream 是流式压缩，不是“一键压缩字符串”。它只工作于 ReadableStream 管道，而 DOM 快照必须先变成流，再进管道。跳过序列化或漏设 Content-Encoding，整个链路就断在第一步。
