textencoder和textdecoder是浏览器原生api，textencoder.encode(str)返回uint8array（utf-8编码），textdecoder.decode()可安全还原字符串，支持stream模式处理分片、fatal选项控制错误行为，但仅限utf-8且ie不支持。
直接用 TextEncoder 和 TextDecoder 就行，不用额外库、不依赖后端、浏览器原生支持——但得注意它们只处理 UTF-8，且 TextEncoder.encode() 返回的是 Uint8Array，不是普通数组或 ArrayBuffer。
TextEncoder.encode() 怎么把字符串转成 UTF-8 字节
核心就一行：encoder.encode(str)，返回标准 Uint8Array。它不接受配置参数，也不支持流式分块编码，必须传完整字符串。
- 别写
new Uint8Array(encoder.encode(str))——这是多余拷贝，encode()已返回正确类型 - 中文、emoji、代理对（如 ?）都能正确编码，比如
"Hello 世界! ?"→Uint8Array(19) - 如果频繁调用，建议复用一个
TextEncoder实例，避免每次new的开销 - 鸿蒙 NEXT 中需通过
@ohos.util导入，写法是new util.TextEncoder()，不是全局构造函数
TextDecoder.decode() 如何安全还原字节为字符串
TextDecoder 默认就是 UTF-8，显式写 new TextDecoder('utf-8') 或 new TextDecoder() 效果一样。关键在输入：必须是 Uint8Array、Int8Array 等 TypedArray，不能直接传 ArrayBuffer（得先包装）。
- 常见错误：传
event.data前不判断类型，WebSocket 收到ArrayBuffer时要先转new Uint8Array(event.data) - 大文本分片接收？加
{ stream: true }，然后多次调用decode()，内部会缓存未完成的 UTF-8 序列 -
fatal: true会让非法字节直接抛错，适合调试；生产环境一般保持默认（静默替换为 ） - IE 完全不支持，小程序里也要查文档——微信基础库 2.27.0+ 才稳定支持
WebSocket 场景下为什么不能只传字符串
因为 ws.send("text") 是隐式 UTF-8 编码，你无法控制过程。一旦协议要求前缀长度头、混用二进制帧、或服务端解析器对 BOM/代理对敏感，就容易出乱码或截断。
- 正确做法：统一走字节流路径，
ws.send(encoder.encode(message)) - 若需拼接 header + body，必须用
Uint8Array合并，比如new Uint8Array([...header, ...body]) - 服务端返回二进制数据（
ArrayBuffer）时，必须用TextDecoder解码，不能用String.fromCharCode(...new Uint8Array(buf))——后者会错解多字节字符
真正容易被忽略的是边界情况：空字符串 encode("") 返回空 Uint8Array，而 decode(new Uint8Array([])) 返回空字符串，这没问题；但如果你手动截取字节数组（比如取前 10 字节），可能切在 UTF-8 多字节字符中间，导致 TextDecoder 解出 ——这种问题不会报错，只会静默损坏数据。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
