震惊！微信小程序调用 AI 大模型流式输出，线上 onChunkReceived () 分块结果竟为空？

在微信小程序开发过程中，当涉及调用 AI 大模型实现流式输出时，不少开发者遇到了一个诡异的问题：本地开发环境一切正常，onChunkReceived()方法能够顺利监听并获取分块结果，但一旦发布到线上，该方法监听获取的分块结果却为空。经过大量排查，发现问题很可能出在TextDecoder的使用上，微信生产环节可能并不支持TextDecoder，这就需要我们自定义一个 JavaScript 逻辑来实现字节转字符串的功能。接下来，让我们详细剖析这一问题及解决方案。

一、问题现象描述

在小程序中集成 AI 大模型的流式输出功能时，我们期望通过onChunkReceived()方法实时获取模型返回的分块数据，并进行相应处理展示。在本地开发环境下，通过模拟器和真机调试，该功能均能正常运行，分块结果能够被正确监听和处理。然而，当将小程序发布到线上环境后，却发现onChunkReceived()方法获取到的分块结果为空，导致流式输出功能无法正常实现。

二、问题排查过程

1. 网络请求检查：首先怀疑是网络问题，检查线上环境的网络请求是否正常。通过小程序的网络调试工具，发现请求能够正常发送到 AI 大模型服务器，且服务器也返回了响应数据，状态码正常，排除网络请求失败导致数据获取不到的可能性。
2. 数据解析怀疑：进一步考虑数据解析环节，由于是流式输出，分块数据的解析方式可能存在问题。在代码中，我们使用了TextDecoder来将字节流转换为字符串进行后续处理。在本地环境中，TextDecoder运行正常，但联想到线上线下环境的差异，推测微信生产环节可能对TextDecoder支持存在问题。
3. 验证 TextDecoder 支持情况：通过在小程序中添加测试代码，在不同环境下尝试调用TextDecoder的方法。结果发现，在本地环境下TextDecoder相关代码能够正常执行，而在线上环境中，调用TextDecoder的某些方法时会抛出异常，证实了我们关于微信生产环节不支持TextDecoder的猜测。

三、解决方案：自定义字节转字符串逻辑

既然确定问题出在TextDecoder的支持上，那么我们就需要自定义一个 JavaScript 逻辑来实现字节转字符串的功能，以替代TextDecoder。以下是一种实现方式：

文章最后有请求工具类的全部代码

decode(dataView) { let data; if (dataView instanceof ArrayBuffer) { data = new Uint8Array(dataView); } else if (dataView instanceof Uint8Array) { data = dataView; } else { throw new Error(\'参数必须是 ArrayBuffer 或 Uint8Array\'); } if (this.encoding === \'utf-8\') { return this._decodeUTF8(data); } else { throw new Error(\'当前只支持 UTF-8 编码\'); }}

_decodeUTF8(data) { let str = \'\';