Node.js Buffer 是什么？为什么需要 Buffer？

简化版

Buffer 是 Node.js 处理二进制数据的对象。JavaScript 字符串适合文本，Buffer 适合文件、网络包、图片、加密数据等原始字节。它和编码转换密切相关，比如 utf8、base64、hex。

详细版

示例：

const buf = Buffer.from('你好', 'utf8');
console.log(buf.length); // 字节长度，不是字符数
console.log(buf.toString('utf8'));

常见用途：

文件读写。
HTTP/TCP 数据处理。
图片、音频等二进制资源。
base64 编解码。
加密哈希。

Buffer 的 length 是字节数，字符串的 length 是 UTF-16 code unit 数，两者不是一回事。

完整版教学

一、JavaScript 原生字符串不适合所有数据

网络和文件底层都是字节。文本只是按某种编码解释后的字节序列。Node 做服务端 I/O，必须能直接处理原始字节，这就是 Buffer 的位置。

比如图片不能当字符串处理，否则编码转换可能破坏数据。

二、编码决定字节和文本如何互转

同一个字符串，用不同编码得到的字节可能不同。常见编码：

utf8：最常用文本编码。
base64：把二进制表示成可传输文本。
hex：十六进制表示。

理解编码能避免“中文乱码”“base64 解析错误”“签名不一致”等问题。

三、Buffer 分配的安全性

Buffer.alloc(size) 会初始化内存，较安全；Buffer.allocUnsafe(size) 可能拿到未清零内存，速度快但要立刻覆盖，否则可能暴露旧数据。

业务代码通常优先 Buffer.alloc，性能极敏感场景才考虑 unsafe。

四、面试追问与工程落地

常见追问是 Buffer 和 ArrayBuffer 的关系。ArrayBuffer 是 JS 标准里的通用二进制缓冲区，Buffer 是 Node 提供的增强实现，继承/兼容 Uint8Array，带更多编码和 I/O 相关方法。

工程里处理上传文件、接口签名、Webhook 验签时，常需要拿原始 Buffer。不能在中间随便转字符串，否则字节级签名可能失败。

五、用具体字节推演编码结果

UTF-8 中 ASCII 字符通常 1 字节，常见汉字通常 3 字节；JavaScript 字符串 length 统计 UTF-16 code unit。'你好'.length 是 2，而 Buffer.byteLength('你好', 'utf8') 和对应 Buffer 长度都是 6。

const text = 'A你好';
console.log(text.length);                    // 3 个 UTF-16 code unit
console.log(Buffer.byteLength(text, 'utf8')); // 7 字节
console.log(Buffer.from(text).toString('hex'));

Base64 是二进制到文本的表示，不是加密；每 3 字节通常编码成 4 个字符，所以 3 MB 原始数据仅正文就约变成 4 MB。把大文件转 Base64 塞进 JSON 会同时增加传输体积、字符串内存和解析成本。

API	内存关系	典型用途
`Buffer.alloc(n)`	新分配并清零	安全默认值
`Buffer.allocUnsafe(n)`	新分配但可能未清零	能立即完整覆盖的性能路径
`buf.subarray(a,b)`	与原 Buffer 共享底层内存	零拷贝切片
`Buffer.from(buf)`	复制字节	需要独立生命周期

六、共享视图、边界检查和敏感数据

Buffer 是 Uint8Array 的子类，但历史 API 有 Node 特有语义；subarray 返回共享底层内存的视图，修改子视图会影响原 Buffer。把小切片长期保存还可能让整块大底层内存无法回收，需要独立数据时应复制。

allocUnsafe 的“unsafe”不是越界写入，而是返回区域可能含旧内存内容；只有在暴露或读取前保证每个字节都被覆盖才可使用。处理密钥和口令时还要减少日志、序列化与多余复制，并在生命周期结束后按威胁模型考虑清零。

网络协议解析必须先检查长度再读整数或切片，不能相信包内长度字段。字符边界也可能跨 chunk，被拆开的多字节 UTF-8 不能对每块直接 toString() 后拼接，应使用 StringDecoder 或正确的流式解码器。

Buffer 思维是“先确认字节边界和编码，再谈文本”；任何无意的字符串转换都可能改变签名、长度或二进制内容。

二进制协议排查清单

处理网络包或文件头时，先确认字段的字节长度、端序、有无符号、编码和最大允许值，再调用对应的 readUInt*、readInt* 或解码 API。读取前要验证 offset + fieldLength <= buffer.length，写入前也要验证目标空间，不能把越界异常当成输入校验。

协议中的长度字段必须同时受业务上限约束：即使报文声称后续有 4GB 数据，也不能据此直接分配 4GB Buffer。分片到达时先保留不完整尾部，等下一块拼够一帧再解析；这与 Stream 的 chunk 不等于消息边界是同一个问题。

七、常见误区与追问

误区：Buffer.length 等于字符串字符数。 它始终是字节数，字符串 length 则是 UTF-16 code unit 数。
误区：Base64 能保护敏感数据。 Base64 可逆且不带保密性，只是传输表示。
误区：Buffer.allocUnsafe 会自动在返回前清零。 它可能包含旧数据，必须在读取或输出前完整覆盖。
追问：subarray 为什么可能影响原 Buffer？ 两者共享同一 ArrayBuffer 内存，只是 offset 和 length 不同。
追问：Buffer 与 ArrayBuffer 如何转换？ 要注意 byteOffset/byteLength，不能总把 buf.buffer 的整块范围当成当前 Buffer。
追问：中文为什么容易在 chunk 边界乱码？ 一个 UTF-8 字符可能跨两个 chunk，逐块独立解码会把不完整字节当错误序列。
追问：Webhook 验签为什么常要求 raw Buffer？ 签名针对原始字节计算，先解析再序列化可能改变空格、顺序或编码。

八、加强记忆

Buffer 是 Node 的“字节容器”。文本看编码，文件和网络看字节；Buffer.length 是字节数，不是字符数。

简化版

详细版