WebSocket如何发送数组数据 Int8Array与Float32Array用法【实战】-js教程-PHP中文网

能，但必须传 Int8Array 或 Float32Array 的 .buffer 属性；直接传视图在旧版 Safari 和微信小程序中会静默失败或抛 TypeError，正确写法是 ws.send(arr.buffer)，并确保 ws.readyState === WebSocket.OPEN。

websocket如何发送数组数据 int8array与float32array用法【实战】

WebSocket.send() 能不能直接传 Int8Array 或 Float32Array？

能，但必须传它的 .buffer 属性，而不是视图本身。浏览器内部会自动识别 ArrayBuffer 并走二进制帧通道；如果直接传 Int8Array 实例（比如 ws.send(new Int8Array([1, -2, 3]))），部分旧版 Safari 和微信小程序真机环境会静默失败或抛 TypeError。

常见错误现象：Failed to execute 'send' on 'WebSocket': InvalidStateError 或控制台无报错但服务端收不到数据——大概率是传了视图却没检查 ws.readyState === WebSocket.OPEN，或者漏了 .buffer。

正确写法：ws.send(new Int8Array([1, -2, 3]).buffer)
错误写法：ws.send(new Int8Array([1, -2, 3]))（不兼容）
更稳妥的写法：const arr = new Int8Array(4); arr[0] = 1; ws.send(arr.buffer)（避免临时对象被 GC 干扰）

Int8Array 与 Float32Array 的字节对齐和端序要注意什么？

两者底层都是 ArrayBuffer，但解释方式不同：Int8Array 每个元素占 1 字节，有符号；Float32Array 每个元素占 4 字节，IEEE 754 单精度浮点。发送前必须确认后端协议约定的字节序（小端还是大端）和字段偏移。

例如用 DataView 写入 float 值更可控：

const buf = new ArrayBuffer(4);
const view = new DataView(buf);
view.setFloat32(0, 3.1415926, true); // 第三个参数 true 表示小端序
ws.send(buf);

而直接用 Float32Array：

const f32 = new Float32Array([3.1415926]);
ws.send(f32.buffer); // 同样发 4 字节，但字节序由平台决定（通常小端）

跨平台传输 float 时，优先用 DataView 显式指定端序
Int8Array 不涉及端序问题，适合做原始字节流（如 PCM 音频采样）
别混用：比如把 Float32Array 的 .buffer 交给后端按 int8 解析，会得到完全不可读的乱码

为什么 Float32Array 发过去，服务端解析出的值总是不对？

最常见原因是后端没按 4 字节对齐读取，或误把整个 ArrayBuffer 当作单个 float 处理。比如你发 new Float32Array([1.0, 2.0, 3.0]).buffer（共 12 字节），后端只读前 4 字节，就只拿到 1.0，其余丢弃。

WebSocket 8.18.2

WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。

下载

另一个高频坑：前端用 TextEncoder 编码字符串后误当 float 数组发——TextEncoder.encode("1.0") 得到的是 Uint8Array [49, 46, 48]（ASCII），不是 float 二进制表示。

调试建议：在发送前打印 new Uint8Array(f32.buffer) 看实际字节，和后端收到的原始字节比对
若后端用 Protobuf，确保字段类型定义为 float（对应 wire type 5），不是 sint32 或 bytes
音频流场景下，Float32Array 常用于 Web Audio API 输出，但 WebSocket 传输时建议转成 Int16Array 再发（节省带宽、服务端解码更稳）

小程序和 Safari 中 Int8Array/Float32Array 的兼容性差异

微信小程序真机不支持 TextDecoder，但 Int8Array 和 Float32Array 的构造与 .buffer 访问是 OK 的；Safari 15.4+ 支持直接 send 视图，但 iOS 14.x 及更早版本仍要求显式传 .buffer。

如果你的业务要覆盖老设备，统一用这个模式最保险：

function sendTypedArray(ws, typedArr) {
  if (ws.readyState !== WebSocket.OPEN) return;
  ws.send(typedArr.buffer);
}
sendTypedArray(ws, new Int8Array([1, 2, 3]));
sendTypedArray(ws, new Float32Array([1.1, 2.2]));

不要依赖 typedArr.constructor.name 做类型分发——Int8Array 和 Uint8Array 的 .buffer 行为一致，无需区分
避免在循环中反复构造新视图：for (let i = 0; i 会产生大量小 ArrayBuffer，GC 压力大；应预分配大 buffer，复用视图写入
真机调试时，用 console.log(typedArr.buffer.byteLength) 确认实际发送长度，比看数组 length 更可靠

真正容易被忽略的是：Float32Array 的 NaN、±Infinity 在二进制层面有特定编码，但某些嵌入式后端协议会直接拒绝这类值，导致整包解析失败。上线前务必用真实边界值测一遍。