能，但必须传 Int8Array 或 Float32Array 的 .buffer 属性；直接传视图在旧版 Safari 和微信小程序中会静默失败或抛 TypeError，正确写法是 ws.send(arr.buffer)，并确保 ws.readyState === WebSocket.OPEN。
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：
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
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，其余丢弃。
另一个高频坑：前端用 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 在二进制层面有特定编码，但某些嵌入式后端协议会直接拒绝这类值，导致整包解析失败。上线前务必用真实边界值测一遍。
