直接读写大文件会卡住 Node.js 进程，因 fs.readFile/write 默认全量加载内存，易触发 OOM 并阻塞事件循环；应使用流式处理（createReadStream/writeStream）分块操作，配合 Buffer.alloc() 预分配内存、手动流控、全程保持 Buffer 类型避免 toString() 丢数据。
为什么直接读写大文件会卡住 Node.js 进程
因为 fs.readFile 和 fs.writeFile 默认把整个文件加载进内存，1GB 文件就占 1GB 内存，还可能触发 V8 堆内存限制（通常 1.4GB 左右），进程直接 OOM。Node.js 的事件循环也会被阻塞，其他请求全卡住。
真正该用的是流式处理：用 fs.createReadStream 和 fs.createWriteStream 配合 Buffer 分块操作，每次只处理几 KB～几 MB，内存可控，CPU 利用率也更平稳。
Buffer.from() vs Buffer.alloc()：选错会导致内存泄漏
处理二进制流时最常踩的坑是误用 Buffer.from() 接收不确定长度的数据（比如网络分包、压缩流解码中间结果）。它会按传入参数类型做不同解析——字符串转 Buffer 会拷贝，而传入数组或 ArrayBuffer 也可能隐式分配超大空间。
更安全的做法是预估最大单次处理量，用 Buffer.alloc() 显式申请固定大小：
const chunk = Buffer.alloc(64 * 1024); // 每次最多处理 64KB readStream.read(chunk); // 直接写入预分配 buffer，避免重复 malloc
- 如果数据长度已知且稳定（如固定协议头），
Buffer.alloc()是首选 -
Buffer.from(array)适合从已有数组构造，但注意 array 元素必须是 0–255 整数，否则静默截断 - 绝对不要在循环里用
Buffer.from(string)处理高频小数据，字符串编码开销大，且每次新建对象增加 GC 压力
stream.pipe() 不能满足需求时，怎么手动控制 Buffer 流向
pipe() 简单但太黑盒：无法插入校验、加解密、格式转换逻辑，也无法动态调整 chunk size 或捕获中间错误。
手动流控的关键是监听 data 事件并用 Buffer.concat() 合并碎片（注意不是拼接字符串）：
const chunks = [];
readStream.on('data', (chunk) => {
chunks.push(chunk);
});
readStream.on('end', () => {
const fullBuffer = Buffer.concat(chunks); // 合并所有 Buffer，不转字符串
process(fullBuffer);
});- 合并前确认
chunks总长度别超内存预算，必要时加限流（如累计超 10MB 就 flush 一次） -
Buffer.concat()比循环buffer1 = Buffer.concat([buffer1, buffer2])快得多，后者每次调用都重新分配内存 - 若需边读边处理（如视频帧提取），改用
for await (const chunk of readStream)（Node.js ≥18），配合Uint8Array视图操作更省内存
gzip 流中混用 Buffer 和字符串会丢数据
用 zlib.createGunzip() 解压时，输出流 emit 的是 Buffer，但很多人习惯 toString() 转字符串再处理，一旦原始数据含非 UTF-8 字节（如图片、PDF、加密 payload），就会出现乱码或截断。
正确做法是全程保持 Buffer 类型，仅在最终落盘或协议边界才考虑编码：
gunzip.on('data', (chunk) => {
// ✅ 正确：chunk 是 Buffer，可直接 hash、加密、写入二进制文件
sha256.update(chunk);
writeStream.write(chunk);
});
// ❌ 错误：toString() 会破坏二进制语义
// gunzip.on('data', (chunk) => chunk.toString('binary'));- Node.js 中
Buffer是唯一能无损表示任意字节序列的类型，字符串只是它的视图之一 - HTTP 响应体、数据库 BLOB、音视频帧、私钥文件——所有非文本场景，都应避免过早 toString()
- 调试时可用
buffer.subarray(0, 16).toString('hex')查看前 16 字节十六进制，比打印全文本安全
Buffer 不是银弹，关键在“控制粒度”：chunk 太小，系统调用和事件开销大；太大，又回到内存瓶颈。实际项目里得根据 I/O 延迟、可用内存、业务容忍度反复测——比如日志归档可以 1MB/chunk，实时音视频就得压到 64KB 以下。
