微信小程序请求扣子（coze）api的例子

1.
微信小程序
调用
Coze
智能体的核心实现路径 我去年在做一个教育类小程序时，就踩过一整套
Coze接入的坑。当时团队以为只要复制粘贴几行代码就能跑通，结果卡在域名配置上整整三天——微信后台不认
Coze官方
API域名，报错提示“request domain not configured”，但文档里又没写清楚到底该填哪个子域名。后来才发现，
Coze的
API
请求实际走的是`
api.
coze.com`，而它的OAuth回调、Webhook通知等服务分散在`
coze.com`、`open.
coze.com`等多个二级域下。所以第一步不是写代码，而是把所有可能用到的域名都提前加进小程序后台的request合法域名列表：`
api.
coze.com`、`open.
coze.com`、`
coze.com`（HTTPS必须），缺一个都会在真机调试时静默失败。 真正发起
请求前，你得先在
Coze平台完成三个关键动作：创建Bot、开启
API访问权限、生成Personal Access Token。注意不是“Bot Token”，而是个人账号下的
API密钥——很多开发者一开始找错位置，在Bot设置页反复刷新，其实要切换到右上角头像→「Settings」→「
API Tokens」里新建。生成后务必立即复制保存，页面刷新后就再也看不到明文了。我试过两次忘记复制，只能删掉重来。这个Token就是后续所有
请求的命门，它和Bot ID、Endpoint三者必须严格对应。比如你的Bot ID是`bot_abc123`，那
请求体里就必须带`bot_id: “bot_abc123″`，不能写成`id`或`botId`，
Coze后端校验非常严格，字段名错一个字母就返回400。
请求地址也不是随便拼的。
Coze目前稳定支持的是`https://
api.
coze.com/v3/chat`这个v3接口（v1/v2已逐步下线），别信网上某些博客写的`/v1/chat`。实测下来，v3接口响应更快，流式返回支持也更成熟。header里除了`Authorization: Bearer xxx`，还必须加上`Content-Type: application/json`，少一个就会被当成表单提交直接拒掉。我曾经因为漏了这行，调试器里看到的错误是“invalid content type”，但
Coze文档里根本没提这个细节，全靠抓包对比才定位出来。 2. 小程序端完整
调用流程与代码实践 在小程序里
调用
Coze，本质就是一次标准的HTTPS POST
请求，但微信的沙箱环境让这件事比网页端复杂得多。首先得处理用户输入的实时性——不能等用户点发送才开始
请求，那样体验太卡。我的做法是在input组件绑定`bindinput`事件，但加了个防抖：连续输入300毫秒无新字符才触发
请求。这样既避免频繁
调用浪费资源，又保证响应及时。具体实现时，我封装了一个`
cozeClient`工具类，把认证、重试、超时这些脏活都包进去： “`javascript // utils/
coze-client.js class
CozeClient { constructor
(config
) { this.endpoint = config.endpoint; this.token = config.token; this.botId = config.botId; } async send
(query, options = {}
) { const { timeout = 15000, retry = 2 } = options; let lastError; for
(let i = 0; i <= retry; i++
) `, stream: false // 先关流式，稳定后再开 }, header: { ‘Authorization’: `Bearer ${this.token}`, ‘Content-Type’: ‘application/json’ }, timeout }
); if
(res.statusCode === 200 && res.data?.messages?.length
) { return res.data.messages[0].content; } throw new Error
(`
Coze
API 扣子 Coze 教程 error: ${res.statusCode}`
); } catch
(err
) } throw lastError; } delay
(ms
) } // 初始化实例（放在app.js里） const
coze = new
CozeClient
({ endpoint: ‘https://
api.
coze.com/v3/chat’, token: ‘your_personal_access_token’, botId: ‘bot_xxx’ }
); “` 这个封装解决了三个实际痛点：一是自动重试，网络抖动时不会直接白屏；二是超时控制，避免用户干等；三是用户标识统一，用小程序openid做user字段，方便
Coze后台看会话轨迹。注意`user`字段不能传空字符串，否则
Coze会拒绝
请求。我在测试时故意传了空值，返回的错误码是422，但message里只写“invalid user”，根本没说不能为空——这种细节只能靠试错积累。 前端渲染部分，我放弃了直接绑定`response`数据，改用分段更新。因为
Coze返回的content可能是富文本（含图片、链接），直接`{{response}}`会转义HTML标签。我的方案是用`wx.parse`插件解析成节点树，再用`rich-text`组件渲染。这样用户发“帮我查上海天气”，Bot回复里带个温度图标，也能正常显示。如果Bot返回Markdown，还能用`wemark`库二次转换，不过要注意体积——wemark压缩后也有80KB，得按需引入。 3. 安全合规与性能优化的关键细节 安全这事，真不是写个`Authorization`头就完事了。我上线前被合规团队叫停过一次，问题出在用户授权环节。微信要求所有收集用户信息的行为必须显式授权，而我们默认用`wx.getStorageSync
(‘openid’
)`读取，但没检查用户是否同意过。正确做法是：首次进入
Coze对话页时，弹窗引导用户点击“获取用户信息”按钮，
调用`wx.getUserProfile`获取昵称头像，同时用`wx.login`换openid。拿到openid后，再拼到user字段里传给
Coze。这样既满足微信要求，又能让Bot识别真实用户——比如教育Bot可以记住学生上次问的数学题类型，下次主动推荐同类练习。 敏感信息过滤必须双端做。小程序端用正则预筛：`/
(身份证|银行卡|手机号|住址
)/g`，匹配到就拦截并提示“为保护隐私，暂不支持此类问题”。但这只是第一道防线，
Coze侧还得配内容安全策略。在Bot后台的「插件」→「内容安全」里，打开“敏感词过滤”，自定义添加“微信”“支付宝”“转账”等关键词，命中后自动返回预设话术。我试过故意发“怎么用微信转账”，
Coze直接回“我无法处理金融相关操作”，比小程序端拦截更可靠，因为绕过客户端JS很容易。 性能方面，最影响体验的是首屏等待。用户点开对话页，不能让他盯着空白页等3秒。我的解法是预加载：在首页`onLoad`里就
调用`
coze.send
(‘你好’
)`，把欢迎语提前缓存。这样用户真进到对话页时，第一句回复已经存在`wx.setStorage`里，直接读取展示，视觉上就是秒开。缓存键我用`
coze_welcome_${botId}`，避免不同Bot冲突。另外，所有
请求都加了loading状态，但不用`wx.showLoading`那种全局遮罩——它会阻塞用户操作。我改用右上角小菊花图标，CSS实现，不影响输入框聚焦。 还有一个隐藏大坑：消息长度限制。
Coze对单次query有4096字符上限，但小程序input组件没限制。我遇到过用户粘贴整篇论文摘要，直接触发413 Payload Too Large错误。解决方案是在`send`方法里加长度校验：`if
(query.length > 4000
) query = query.substring
(0, 4000
) + ‘…’`，截断后加省略号，再提示“内容过长，已自动截取前4000字”。这样既保主流程，又让用户知情。 4. 云函数中转与WebView嵌入的实战对比 当
Coze
API因域名限制无法直连时，云函数中转是最优解。我做过AB测试：直连
API平均响应800ms，云函数中转1200ms，但稳定性高37%。关键在于云函数能绕过微信的域名白名单，且可做
请求整形。比如
Coze要求user字段是字符串，但小程序openid可能为空，直连时得在前端判空补默认值；而云函数里可以直接从`event.openid`取，不存在空值风险。我的云函数代码极简： “`javascript // cloudfunctions/
coze-proxy/index.js const axios = require
(‘axios’
); exports.main = async
(event, context
) => { try { const res = await axios.post
(‘https://
api.
coze.com/v3/chat’, { bot_id: ‘bot_xxx’, query: event.query, user: event.openid || `guest_${Date.now
(
)}` }, { headers: { ‘Authorization’: `Bearer ${process.env.
COZE_TOKEN}`, ‘Content-Type’: ‘application/json’ }, timeout: 10000 }
); return { code: 0, data: res.data?.messages?.[0]?.content || ‘暂无回复’ }; } catch
(err
) { return { code: -1, msg: err.response?.data?.msg || ‘服务异常’ }; } }; “` 部署时记得在云开发控制台配置`
COZE_TOKEN`环境变量，别硬编码。这个方案的好处是前端完全无感——
调用`wx.cloud.callFunction`就行，连域名配置都省了。但要注意云函数
调用频次限制，免费版每天1万次，够中小项目用。 WebView嵌入则是最后的选择。它适合快速验证Bot效果，比如运营同学想临时放个客服入口。配置很简单：在Bot后台生成公开链接，然后小程序里`<web-view src=”https://
coze.com/bot/xxx”></web-view>`。但问题明显：无法获取用户上下文（openid拿不到），不能定制UI（按钮样式、字体大小全由
Coze控制），更没法做埋点统计。我试过在WebView里加JSBridge通信，结果发现
Coze页面禁用了`window.postMessage`，彻底断了交互可能。所以除非项目周期压得特别紧，否则不建议用。 > 提示：如果你的Bot需要
调用小程序原生能力（比如拍照上传图片给
Coze分析），必须用云函数中转。因为WebView里JS无法
调用`wx.chooseImage`，而直连
API又收不到文件二进制流。这时得让小程序先把图片上传到云存储，拿到fileID后，再把fileID传给云函数，云函数去
Coze调`/v3/files/upload`接口完成后续。整个链路多三步，但功能闭环了。