基于企业微信API的微应用前端与后端架构设计

1. 引言

微应用前端负责给员工点：查订单、提审批、看客户。后端负责鉴权、任务、出站。把发送写进按钮点击函数里，页面一卡、人连点，就是多条通知。架构要把「界面操作」和「投递」切开。

2. 三层不要焊死

前端（工作台 / 管理页） → 后端业务 API（鉴权、校验、写任务） → 发送进程（号在线才出站） → 员工会话 回调入口 → 入队 → 业务消费 → 回写工作台

前端不持有发送凭证。凭证在发送进程。员工在前端看到的「已发送」，以任务状态为准，不要以按钮返回为准。

QiWe API 放在发送进程和回调入口，不要嵌进浏览器。

3. 前端

工作台可以是你们自己的管理端，不必先上官方 JS-SDK。需要的是：当前员工、当前客户绑定、任务列表、失败原因（存活 / 对象 / 投递）。不要在前端拼会话 ID 当隐藏域长期保存后还拿去发。

后端怎么调发送，以 API文档 为准。

4. 后端

defcreate_notify(user,customer_no,text,db):bind=db.get_bind(user.device,customer_no)ifnotbind:return{"ok":False,"reason":"unbound"}key=f"ui:{user.id}:{customer_no}:{hash(text)}"ifdb.try_insert(key):db.enqueue(user.device,bind["peer"],text)return{"ok":True}

出站交给 QiWe API。回调入口只入队。前端轮询任务状态，不轮询聊天窗口。

测试和生产不能共用任务表。前端环境标识必须传到任务行上。

频率、回调和附件分模块做，不要挤进页面按钮。

5. 验收

连点三次按钮只有一条出站；关闭页面后任务仍会发；号掉线时前端看到的是存活失败，不是「接口 500 自己猜」。

6. 总结

微应用架构的合格线：前端无凭证、后端有任务、发送有进程、回调有队列。企业微信API是出站层，不是页面组件。