TextEncoder 在微信小程序等环境中未定义是因运行时精简所致，需用 polyfill（如 FastestSmallestTextEncoderDecoder）兼容；encode() 返回的 Uint8Array 可直接用于 WebSocket 发送，但须复用实例并正确拼接长度头。
微信小程序、旧版 Safari 或某些嵌入式 WebView 中直接用 TextEncoder 会报 TextEncoder is not defined ——这不是你代码写错了，是环境压根没这个 API。
为什么 TextEncoder 在小程序里直接报错
微信小程序用的是精简版 JS 运行时（iOS 是 JavaScriptCore，Android 是 V8），不是完整浏览器。它默认不挂载 TextEncoder/TextDecoder 到全局，连基础库 2.25.0 之前都不支持。真机调试时看到这个错误，基本可以确定是环境缺失，不是语法或拼写问题。
- 开发工具可能“假装支持”（尤其高版本基础库模拟了部分行为），但真机运行立刻失败
-
typeof TextEncoder === 'undefined'是最稳的检测方式，别依赖try/catch启动时判断 - 即使基础库升级到支持版本（如 2.27.0+），iOS 14 以下设备仍可能 fallback 失败
怎么在不支持的环境里安全使用 TextEncoder
别自己手写 UTF-8 编码逻辑（容易漏掉代理对、BOM、空字符等边界），直接引入轻量 polyfill。三个主流方案中，推荐按场景选：
- 只要 UTF-8，且包体积敏感 → 用
FastestSmallestTextEncoderDecoder（压缩后仅 3.2KB，API 完全兼容，encode()性能比原生还快 10%~15%） - 需要解码 GBK/ISO-8859-1 等老编码 → 用
text-encoding（标准 polyfill，但体积大些，约 8.7KB，且只支持解码 legacy 编码，不支持编码） - 想最小改动迁移现有代码 →
EncoderDecoderTogether.min.js（API 层几乎 1:1，但注意它内部用查表法，长文本下内存占用略高）
引入后统一检测写法：
立即学习“前端免费学习笔记（深入）”；
if (typeof TextEncoder === 'undefined') {
require('path/to/FastestSmallestTextEncoderDecoder');
}
const encoder = new TextEncoder();
const uint8 = encoder.encode('你好');
TextEncoder.encode() 返回的 Uint8Array 能直接发 WebSocket 吗
能，而且更可靠——这是它最值得用的场景之一。直接传字符串给 ws.send() 会触发浏览器隐式 UTF-8 编码，但服务端若按字节解析（比如协议头含长度字段），中间经过 Nginx 或某些代理时可能被二次转义或截断。
- 务必复用
TextEncoder实例，不要每次发消息都new TextEncoder()（创建开销不小） -
encode()返回就是标准Uint8Array，不用再new Uint8Array(...)包一层 - 如果协议要求前缀长度头，拼接时用
new Uint8Array([...lengthHeader, ...uint8])，别用concat()（返回新数组但类型丢失）
典型安全写法：
const encoder = new TextEncoder();
const ws = new WebSocket('wss://api.example.com');
ws.onopen = () => {
const msg = '{"cmd":"ping","ts":123}';
const bytes = encoder.encode(msg);
const header = new Uint8Array([0x00, bytes.length]); // 2字节长度头
const packet = new Uint8Array(header.length + bytes.length);
packet.set(header);
packet.set(bytes, header.length);
ws.send(packet);
};
流式读取响应时，TextDecoder 的 stream: true 别乱开
用 response.body.getReader() 分块读取大响应时，TextDecoder 的 stream: true 参数只在跨块边界有代理对（如 emoji ?）或 UTF-8 多字节字符被切开时才真正起作用。多数纯 ASCII 场景关掉它反而更快。
- 开启
stream: true后，decode()会缓存未完成的字节，直到下一块到来；关闭则每块独立解码，遇到半截 UTF-8 字节直接报错 - 如果后端保证每块都是完整 UTF-8（比如按行分块、或用 \n 分隔 JSON），就设
stream: false（默认值） - 微信小程序里用
stream: true要确认 polyfill 是否支持——FastestSmallestTextEncoderDecoder支持，text-encoding不支持
正确流式处理示例：
const decoder = new TextDecoder('utf-8', { stream: true });
const reader = response.body.getReader();
while (true) {
const { value, done } = await reader.read();
if (done) break;
const chunk = decoder.decode(value); // 自动处理跨块代理对
console.log(chunk);
}
const final = decoder.decode(); // 清空残留缓冲
真正麻烦的从来不是“怎么写”，而是“什么时候该用 polyfill”和“哪些边界 case 没测到”。比如 iOS 微信 8.0.36 的某个 patch 版本里，TextEncoder 存在代理对双字节编码错位 bug，必须强制走 polyfill ——这种细节，只靠文档查不到，得靠真机日志堆出来。
