微信小程序客服消息必须通过触发，前端不可直接调用接口；AI逻辑需在后端实现，用户点击按钮后，后端监听回调并调用客服消息接口下发响应，消息限制为5条/48小时。
uni-app里调用微信小程序客服消息接口必须走 button open-type="contact"
微信小程序平台不允许前端直接调用客服会话接口，哪怕你拿到AI服务的响应结果，也**不能绕过原生客服按钮**发起会话。这是硬性限制，不是uni-app封装问题，而是微信侧的安全策略。所以所谓“智能客服机器人”，实际是：AI处理逻辑 + 微信原生客服入口触发 + 会话中人工接管或消息透传。
常见错误现象：uni.openCustomerServiceConversation 在真机调试时报错 fail no permission 或直接静默失败——因为该API仅限已配置客服的主体且需用户主动点击按钮触发。
- 必须用
<button open-type="contact"></button>，不能用uni.navigateTo或自定义view模拟 - 按钮需设置
session-from属性传递上下文（如用户ID、当前页面路径、问题摘要），后续可在客服后台或消息回调中解析 - 微信后台需在「客服管理」中开通并配置「小程序客服」，否则按钮点击后提示“暂无客服在线”
AI接口应在后端调用，而非uni-app前端直连
把AI模型请求（如通义千问、讯飞星火、或自建LLM）放在uni-app的 uni.request 中直连，会暴露API Key、鉴权Token和模型细节，极易被爬取或滥用。微信小程序的 request 请求还受限于合法域名白名单，调试期容易卡在 net::ERR_CONNECTION_REFUSED 或 fail invalid url。
正确做法是：uni-app只负责收集用户输入 → 发送至你自己的后端服务 → 后端完成AI调用、内容过滤、上下文维护 → 返回结构化响应给前端渲染。
- 前端发送消息时，用
uni.request调你自己的/api/chat接口，不要直连https://dashscope.aliyuncs.com/api/v1/services/aigc/text-generation/generation这类地址 - 后端需做流式响应适配（若AI支持SSE），uni-app可通过
uni.connectSocket或轮询方式接收分段回复，避免长等待白屏 - 注意微信小程序对HTTPS证书要求严格，你的后端域名必须有有效CA签发证书，自签名证书会触发
fail tls handshake error
客服按钮点击后如何把AI回答“塞进”会话气泡
微信不提供API让你往客服对话里“主动发消息”，所以所谓“机器人自动回复”其实是障眼法：用户点按钮进入客服窗口 → 你后端监听到该会话建立事件（通过微信客服消息回调）→ 立即向该用户推送一条客服消息（用 POST https://api.weixin.qq.com/cgi-bin/message/custom/send）→ 用户看到的就是“客服发来的第一条消息”，看起来像机器人开场白。
这需要你在微信公众号平台（或小程序后台）配置消息服务器URL，并启用「客服消息」权限。回调事件里能拿到 FromUserName 和 SessionId，结合你之前传入的 session-from 参数，就能匹配上下文、调用AI生成欢迎语并下发。
- 客服消息接口调用频率限制为每秒2条，高并发场景需加队列或降级（比如先返回固定文案）
- 消息内容长度上限600字符，含emoji或富文本会更快触顶，超长需拆条或改用图文消息
- 用户未关注公众号时，
custom/send可能失败，错误码45015，此时只能等用户手动输入再响应
本地调试AI逻辑时，用微信开发者工具的“客服消息”面板不现实
开发者工具里的客服消息面板仅用于测试人工客服，**不会触发你配置的消息回调URL，也不会调用你后端的AI接口**。这意味着你在工具里点按钮，看到的永远是“暂无客服”，根本测不了AI响应流程。
真实验证路径只能是：真机预览 → 扫码进入 → 点击客服按钮 → 观察手机微信通知栏是否收到客服消息 → 查看自己后端日志是否有回调到达和AI调用记录。
- 提前在后端加日志：打印
MsgType、Event、SessionId，确认微信回调格式是否符合预期 - 用
curl -X POST模拟微信回调，快速验证后端逻辑，避免反复扫码 - 微信对回调响应超时限制为5秒，AI调用耗时过长会导致重复回调或丢消息，务必设置超时兜底（如返回“正在接入，请稍候”）
