【uni-ai 故障反馈】模型广场点击后不跳转，同时模型调用突然无法返回，报 502 或参数错误

感谢您提交这份详细的故障反馈。以下以官方视角对本次反馈进行评审，并给出基于现有文档资料的分析结论。

一、反馈完整性评审

整体评价：这是一份质量较高的反馈。包含了发生日期、环境信息、套餐状态（23.66K/300K，额度正常）、最小化测试说明、三个模型各自的 errCode/errMsg/耗时/request_id，并且做了排除业务干扰的最小测试，这些信息对排查很有价值，值得肯定。预期结果（模型广场正常展示、模型调用正常返回）合理，实际结果错误信息具体，不属于误报。

需要补充或澄清的内容：

1. 缺少可运行的代码示例：您描述了"仅发送'你好'、model 已正确传入 chatCompletion()"，但未贴出云对象的完整代码（包括 getLLMManager 的 provider 配置、chatCompletion 的完整调用参数）。官方人员需要通过代码确认 provider: 'qiniu' 的配置方式和 model 的实际传值，仅凭文字描述无法复核。
2. 版本信息不一致：问题描述中写 HBuilderX 5.26，表单中填写的版本号为 5.31，请确认实际测试使用的版本，避免排查方向偏差。
3. 附件无法识别：我这边无法识别截图附件，请以文字形式补充：点击"模型广场"后浏览器地址栏 URL 是否发生变化、页面实际渲染内容、浏览器 Console/Network 是否有报错。
4. 未说明是否使用了流式响应（stream: true / sseChannel），请明确最小测试是流式还是非流式。
5. 复现步骤中"点击模型广场即可"对控制台问题基本清晰，但模型调用问题的复现依赖上述缺失的代码示例，请补充。

二、问题成立性分析与文档依据

1. 关于 60001 / 502（deepseek-v3）

根据 uni-ai 错误码定义：60001 为"服务商接口抛出的错误"，60002 才是"接口调用凭证、key 等信息有误"。您收到的 "service provider error code: 502" 是七牛云服务商侧返回的错误，归类在 60001 下，说明请求已到达服务商并被服务商侧拒绝/失败；若为账号凭证问题，对应的应是 60002。结合您套餐额度正常（23.66K/300K），从错误码归类看更倾向服务商侧通道/服务异常，而非账号问题。request_id（chatcmpl-1f25d483058d470a86d121aa3dca9eea）是服务商返回的请求编号，具体根因需官方持该编号向服务商侧核查，我这边无法仅凭该编号直接判定细节，请耐心等待官方跟进。参考：uni-ai 错误码

1. 关于 50001 / "参数错误:model"（kimi-k2、deepseek-v3.1）

文档中 50001 定义为"缺少参数"，50002 为"参数错误"。实际 errMsg"参数错误:model"将问题指向了 model 参数本身。结合三个模型的差异（deepseek-v3 返回 502，另两个返回 50001），该报错通常与传入的模型 ID 与网关侧登记的不一致有关。需要说明的是：现有资料中未列出 qiniu 计费网关支持的具体模型 ID 清单，我无法直接确认 deepseek-v3、kimi-k2、deepseek-v3.1 这些写法是否为网关登记的准确 ID。文档明确 uni-ai 计费网关支持调用七牛云大模型服务，支持模型列表请以计费文档中的列表为准，请逐字核对代码中传入的 model 值与列表中的模型 ID 是否完全一致：uni-ai 计费网关支持模型列表

1. 关于本地运行方式

文档明确：使用 uni-ai 计费网关时，如需本地运行需要 HBuilderX 3.8.5 及以上版本。您使用的 5.26/5.31 满足该要求，本地运行独立云对象的测试方式本身可行。另请确认：若测试使用了流式响应，使用 uni-ai 计费网关时 sseChannel 参数必填，未传会导致异常。参考：迁移到 uni-ai 计费网关、流式响应说明

1. 关于模型广场无法跳转

现有知识库中未找到 uniCloud web 控制台"模型广场"菜单跳转异常的相关记载，暂无法基于现有资料判断原因。请按上文第 3 点补充文字化的页面表现信息（URL 变化、Console 报错等）以便进一步排查。

1. 两个问题是否同源

从现有错误表现看，控制台跳转属于 web 控制台页面问题，模型调用属于网关/服务商链路问题，目前没有依据表明两者是同一原因，建议分开跟进。

三、结论与建议

模型调用问题成立：60001/502 属于服务商侧抛错，需官方持 request_id 向服务商核查；50001"参数错误:model"请先对照官方模型列表逐字核对模型 ID 写法。控制台跳转问题需补充信息后跟进。请您补充：云对象完整代码、确认实际 HBuilderX 版本、是否流式调用、模型广场页面的文字化表现，以便官方继续排查。

截图已经证明：模型参数问题解决了，当前剩下的是 qiniu 上游服务异常。

最新错误

service temporarily unavailable
service provider error code: 502
request_id: chatcmpl-b45ae743b0ca42fd9270ea733e3813f3
当前实际配置
第二张图显示：

provider: qiniu
model: 空
模型为空时，qiniu 会使用默认模型。当前请求已经不再报：

参数错误:model
而是立即返回：

60001
service temporarily unavailable
502
这说明：

模型字段清空已经生效；
当前请求确实进入了 uni-ai/qiniu 网关；
网关能够接收到请求；
qiniu 上游模型服务返回了 502；
不是排盘、工具调用、历史消息或前端输入造成的；
不是云函数执行超时，截图显示请求很快就失败了。
这次可以把问题明确定位为：

uni-ai 的 qiniu 默认模型服务当前不可用，或者该账号到 qiniu 的服务路由异常。

前端之所以仍然看起来“无回应”，是因为错误发生后，chat.vue:403 仍然执行 pollReply()，不断调用 getMsgs。而 getMsgs 成功只代表查询消息成功，不代表 AI 已生成回复。

本次请求的官方排查编号是：

chatcmpl-b45ae743b0ca42fd9270ea733e3813f3
向 DCloud 反馈时，使用最新编号，并说明：

provider=qiniu，model 为空使用默认模型；
最小聊天请求立即返回：
60001 service temporarily unavailable
service provider error code: 502
request_id=chatcmpl-b45ae743b0ca42fd9270ea733e3813f3
现在不要再继续尝试不同模型名称，因为模型广场不可用，已经无法确认准确 ID。接下来只有两条有效路径：

等 DCloud/qiniu 恢复，并让官方根据 request_id 查询；
接入其他服务商的自有 API Key，绕过 qiniu。
另外，建议修复前端错误处理：只有真正的超时才轮询，收到 60001/502 应立即显示“AI 服务暂时不可用”，避免用户一直看到“正在思考”。

当前未修改生产配置。此前已修改的本地文件仍是：

nt-ai-chat/index.obj.js
nt-ai-model-test/index.obj.js
nt-ai-model-test.param.js
这些修改尚未上传云端。

模型广场页面现在能正常访问了

不行就换个其他模型，别在一棵树上掉死