直接复用 uint8array 缓冲区是降低 js/node.js 流读取 gc 压力最有效手段，关键在于确保每次 read() 获取的 buffer 真正来自池、用完立即归还且不被外部持有。
直接复用 Uint8Array 缓冲区是降低 JS/Node.js 中流读取 GC 压力最有效的手段之一。关键不在“建个池”，而在“让每次 read() 拿到的 buffer 真正来自池、用完立刻归还、且不被外部意外持有”。
明确适用场景：不是所有流都适合缓冲区池化
Uint8Array 池化真正起效的前提是：
-
流数据有稳定大小范围：比如 HTTP body 固定分块（如 4KB/8KB）、WebSocket 帧 payload ≤ 64KB、文件按 chunk 读取（
fs.createReadStream({ highWaterMark: 16384 })） - 缓冲区生命周期短且集中：一次 read → 解析 → 处理 → 丢弃，全程在单次事件循环或 async 函数内完成；避免跨 await、传入未受控回调、塞进 Promise resolve/reject 中
-
不依赖 ArrayBuffer 共享或 transfer：若需用
postMessage(..., [buffer])或WebAssembly.Memory，则必须用ArrayBuffer.transfer，此时不能池化——transfer 后原 buffer 失效，池中引用即失效
选对池实现方式：优先用内置池，慎用手写全局池
浏览器和 Node.js 均提供轻量、线程/上下文友好的缓冲区复用机制：
-
Node.js 推荐
Buffer.poolSize = 8192+readable.read(n)：Node 内部已用 slab pool 管理 Buffer，默认 8KB slab。只要 highWaterMark ≤ 8192 且不调read()无参形式（它会返回剩余全部，可能触发新分配），就能自动复用 -
浏览器可用
new Uint8Array(poolBuffer)手动切片：预分配一个大 ArrayBuffer（如 64KB），每次从其中slice(offset, offset + need)创建视图，用完仅重置 offset，不 new 新 ArrayBuffer -
避免手写
new Set()或Array池管理 Uint8Array：JS 引擎无法保证这些数组本身不逃逸；且多消费者场景下需加锁或复杂同步，得不偿失
严格遵循 Get–Use–Reset–Return 流程
缓冲区复用失败，90% 出在“用了没清”或“归还了还在用”。必须做到：
-
Get 后立即记录长度，不用 length 属性猜：流返回的 Uint8Array.length 是当前有效字节数，但底层 ArrayBuffer 可能更大；保存
const len = buf.length，后续操作只读写0..len -
Use 完必须 Reset 视图状态：若用
TextDecoder.decode(buf, { stream: true })，需调decoder.decode(new Uint8Array(0), { stream: true })清内部状态；自定义解析器要手动buf.fill(0)或标记已用完（不强制清零，但不可残留逻辑状态） -
Return 必须在作用域末尾、await 前、且无异步引用：错误写法：
return buf; setTimeout(() => process(buf), 0)；正确写法：process(buf); returnPool(buf);，确保函数退出前归还
验证是否真的减少了 GC 压力
写了池不等于压低了 GC。打开 Chrome DevTools 的 Memory 面板，录制一次典型流读取流程，重点关注：
-
Allocation instrumentation on timeline：过滤
Uint8Array，对比池化前后“每秒新分配实例数”是否下降 70%+ - Heap snapshot 对比：取两个时间点快照，用 “Objects allocated between snapshots” 查看新增 Uint8Array 是否集中在 old space（说明没及时回收）
-
Node.js 可加
--trace-gc --trace-gc-verbose：观察 Young GC 频次是否下降、每次 GC 中Scavenge阶段耗时是否缩短
