Node.js Buffer 完全指南：从内存分配到协议解析的实战手册

说实话，我第一次在 Node.js 里被 Buffer 教做人的场景，到现在还记得很清楚：拿着一个从 TCP 连接里收到的数据包，想当然地按字符串拼接去解析业务字段，结果中文注释全变乱码，几个关键的二进制字节还被悄悄吞掉，最后花了整整一个晚上排查，才发现每一帧数据根本就不是字符串，而是一段标准的 Buffer。

这也是我后来写任何 Node.js 网络代码和文件处理代码时，都绕不开的底子。Buffer 是 Node.js 里专门用来处理二进制数据的核心机制，文件读写的返回值、网络请求 chunk、加密摘要、图片处理，凡是跟字节打交道的地方基本都有它。这篇内容会把 Buffer 的内存分配、高频 API、典型协议解析场景以及我踩过的那些坑一次讲透，适合正在做 Node.js 后端开发、写网络协议、或者刚接触文件流、想搞懂 Buffer 到底是什么的读者。

如果你只是会写 Buffer.from('abc') 和 .toString()，那下面至少有八成内容你还没真正用上。

1. Buffer 到底是什么

1.1 为什么服务端 JS 不能只靠字符串打天下

JavaScript 这门语言最早为浏览器设计时，字符串和数组已经够用，因为页面交互处理的基本是文本和结构数据。但 Node.js 出现后，JavaScript 开始要面对文件系统、TCP 套接字、HTTP 报文、图片、压缩包这一类场景，这时就会发现一个致命短板：JavaScript 标准字符串是按 UTF-16 编码单位存的，它更适合存文本，却没办****法无损地表示任意二进制字节。

你可能想反问，Uint8Array 不是能表示字节吗？确实能，但这恰恰是 Buffer 的设计根基。Buffer 本质上是 Uint8Array 的子类，也就是 TypedArray 家族的一员，同时在它之上扩展了大量读写整数、浮点数、编码转换的方法。Node.js 里之所以单独把它拎出来，是因为早年 ECMAScript 还没标准化 TypedArray，Node 团队只能自己搞一套 Buffer；后来 TypedArray 普及了，Buffer 又需要保持向后兼容，于是干脆两种能力都保留：既具备数组式的按字节访问能力，又内置了文件流和网络栈需要的高层 API。

再解释下"buffer"这个词本身的歧义。不同领域里同名概念非常多，硬件音频电路里的运放 buffer 是电压跟随器，GIS 里的 buffer 是地理缓冲区，比如 shapely 库里的 .buffer() 方法，Vulkan 里的 command buffer 是 GPU 命令缓冲区。这些和 Node.js 的 Buffer 没有直接关系，只是都借用了"缓冲"或"中间存储"的字面含义。做 Node.js 开发时看到 Buffer，直接理解成"一段用 JS 对象封装的、可读写的原生二进制内存"就够了。

1.2 Buffer 和字符串、普通数组的本质差异

我用一个最直白的方式对比：

• 字符串存文本，按 UTF-16 编码，长度单位是码元，不能直接按字节覆盖写某个位置，追加时会产生新字符串，二进制数据混进去会触发隐式编码转换。
• 普通数组存任意 JS 值，动态可变，很方便，但每个元素是一个完整的 JavaScript 值对象，如果你拿它存 1 万个字节，内存开销远大于 1 万字节，而且 GC 压力巨大，遍历性能也远不如原生二进制。
• Buffer 存 0x00 到 0xFF 的原始字节，内存连续紧凑，读写直接作用于底层字节，性能最高。

拿实际例子说话。Buffer.from([1, 2, 3]) 占据的是三个连续字节，而 [1, 2, 3] 这个普通数组里每个数字都会封装成 Number 对象存储，整体大小远超 3 字节。如果你在大流量的服务器代码里用 Array 去拼二进制数据，后果就是内存以肉眼可见的速度涨。

还有个容易绕晕的点：很多人以为 Buffer 可以动态扩容，其实不行。一旦创建，Buffer 的长度就是固定的，它不像数组那样 push 一下就行。如果数据变了长度，需要重新分配 Buffer 或使用 Buffer.concat 合成新 Buffer。这一点和内存池策略强相关，下面会展开讲。

2. Buffer 的内存从哪来：分配机制比你想的更讲究

2.1 从 8KB 内存池说起

二进制数据如果每个小片段都直接向底层申请一块独立内存，系统调用和内存碎片会变得非常可观。Node.js 的设计方案是在模块加载时准备一块默认 8KB 的内存池，也就是 Buffer.poolSize = 8 * 1024，然后用“切蛋糕”的方式从池里给较小的 Buffer 分配视图。

这里的要点是：Node 在为某个 Buffer 申请底层存储时，如果目标长度小于 Buffer.poolSize >>> 1（也就是 4096 字节），会优先从当前 8KB 池的剩余空间里切一段出来。如果池剩余空间不够，就再新建一个 8KB 池。只有当需要的空间大于等于 4096 字节时，才会单独申请一块独立的底层内存，不走池。

这个机制带来的性能提升非常明显：大量小 Buffer 共用一块底层 ArrayBuffer，不需要频繁调用底层分配函数。但它也有个容易被忽视的后遗症，一旦某个池切片还被一个 Buffer 对象引用，这一整块 8KB 池就不能被释放。所以你在循环里反复创建小的 Buffer.from()，如果一直持有引用不释放，内存池可能被长期占住。

理解了这个，你就能明白为什么 Buffer.allocUnsafeSlow 这个名字里带一个 "Slow"。它不是速度慢，而是绕过了快速内存池，直接分配独立存储，适合那些生命周期很长、单独占用大块内存、不想浪费池空间的对象。

2.2 alloc、allocUnsafe、allocUnsafeSlow，到底选哪个

现在官方已经不推荐用 new Buffer() 来创建实例了。历史原因有二：第一是参数语义混乱，传入数字和传入字符串的行为完全不同；第二是安全风险，如果传入一个数字，旧版本会直接分配一块未初始化的内存，里面可能有之前进程留下的敏感数据。所以请记住，项目里不要再出现 new Buffer(size) 这种写法。

当前推荐的创建方式有三种，我先把它们的差异列出来：