JavaScript操作二进制数据必须使用ArrayBuffer及其视图（如Uint8Array、DataView），因String是UTF-16编码且会Unicode正规化，普通Array存储JS值而非连续字节，无法保证对齐与大小端控制，易致网络传输、文件解析等场景数据错位或静默损坏。
JavaScript 操作二进制数据，核心不是用 String 或普通数组模拟，而是必须用 ArrayBuffer 及其视图（Uint8Array、DataView 等）——否则无法真正读写原始字节，也容易在编码/解码环节出错。
为什么不能直接用字符串或普通数组处理二进制？
字符串在 JavaScript 中是 UTF-16 编码的，一个字符至少占 2 字节，且会自动做 Unicode 正规化；普通 Array 存的是 JS 值（如 Number），不是连续内存块，无法保证字节对齐和大小端控制。一旦涉及网络传输、文件解析（如 PNG header）、加密或 WebAssembly，这些都会导致数据错位或静默损坏。
常见错误现象：
- 用
str.split('').map(c => c.charCodeAt())处理含 emoji 或代理对的字符串，得到错误字节数 - 把
fetch()的response.text()结果当二进制用，实际已是解码后的字符串，丢失原始字节 - 用
JSON.stringify(new Uint8Array([0xff, 0x00]))得到"[255,0]"，误以为这是“二进制表示”，其实只是数字数组的字符串化
从 fetch 到 ArrayBuffer：正确获取原始二进制数据
浏览器中绝大多数二进制输入源（图片、音频、API 响应）都支持直接返回 ArrayBuffer，而不是先转成字符串再折腾。
立即学习“Java免费学习笔记（深入）”；
使用场景：下载文件、解析自定义二进制协议、读取 ZIP 元数据
实操建议：
- 用
response.arrayBuffer()替代response.text()或response.json() - 避免中间经过
TextDecoder再转回字节 —— 除非你明确需要按某种编码（如 UTF-8）解释内容 - 注意：
arrayBuffer()返回 Promise，不可同步调用
示例：
fetch('/data.bin')
.then(r => r.arrayBuffer())
.then(buf => {
const view = new Uint8Array(buf);
console.log(view[0].toString(16)); // 第一个字节：比如 'ff'
});
用 DataView 精确读写多字节类型（int32、float64、大小端）
Uint8Array 适合逐字节操作，但遇到 4 字节整数、8 字节浮点数或需要指定字节序时，DataView 是唯一可靠选择。
参数差异：
-
view.getInt32(offset, isLittleEndian)：第二个参数决定是否按小端读取，默认为false（大端） - 不传
isLittleEndian且数据实际是小端（如 x86 机器写的二进制），结果会完全错误 -
offset单位是字节，必须对齐（如getInt32要求 offset 是 4 的倍数），否则抛RangeError
性能影响：频繁创建 DataView 开销极小，它只是 ArrayBuffer 的视图，不拷贝数据。
Node.js 中的 Buffer 与浏览器 ArrayBuffer 不兼容，别混用
Node.js 的 Buffer 是 Uint8Array 的超集，有额外方法（如 buf.writeUInt32BE()），但它不是标准 ArrayBuffer 视图。直接把 Buffer 传给期望 ArrayBuffer 的 API（如 WebCrypto.subtle.importKey()）会失败。
转换方式：
- Node → 浏览器兼容：
buf.buffer（前提是buf未被切片过；否则用buf.slice().buffer） - 浏览器 → Node：
Buffer.from(arrayBuffer)（注意：这会拷贝数据） - 跨平台库（如
readable-stream）通常内部已处理，但自定义二进制解析逻辑仍需显式判断环境
容易被忽略的一点：Node.js 的 Buffer.from(string, 'hex') 和浏览器的 Uint8Array.from('ff00', Number.parseInt) 行为不同——前者严格要求偶数长度 hex 字符串，后者对单字符会报 NaN，错误提示不一致，调试时容易卡住。
