自建应用、群机器人、H5 页面 —— 三种接入方式的权限、能力与适用场景完全不同。
· 要让员工在企微里「像聊天一样提问」→ 自建应用（机器人）
· 要推通知、发告警、不要求交互 → 群机器人 Webhook
· 要做复杂界面（表格、图表、审批流）→ H5 页面嵌在企微里
三者不是替代关系，同一个项目里经常要用两种甚至三种。
在企微管理后台创建自建应用，配置接收消息的回调地址，用户发消息时企微会推送到你的服务。
优点：能拿到用户身份（企微 userid），可以做权限控制；支持富文本、图片、文件；可以主动给用户发消息。
缺点：需要处理消息加解密（企微的回调是加密的）；需要公网可访问的回调地址；回复有时限（一般 5 秒内要响应，长任务要先回「处理中」再异步推结果）。
适合：智能体问答、工单提交、查询类操作。
在群里加一个机器人，拿到 Webhook 地址，往这个地址 POST 消息就能发到群里。
优点：五分钟能接完，不需要服务器暴露回调；支持文本、Markdown、图文卡片。
缺点：单向，只能发不能收（用户回复机器人收不到）；不支持按人推送，只能发到群。
适合：告警通知、日报推送、任务提醒。不适合做交互式智能体。
把网页嵌在企微的工作台里，用户点开就是你的应用。
优点：界面不受限，可以做表格、图表、审批流；能通过 JS-SDK 拿到用户身份。
缺点：需要配置可信域名和 JS 接口安全域名；体验不如原生，加载速度受网络影响。
适合：需要复杂界面操作的场景，比如填写表单、查看报表、审批。
以设备运维场景为例：
· 员工在企微里向自建应用提问「3 号厅投影仪不亮」→ 自建应用处理
· 智能体给出排查建议 → 直接回复在对话里
· 如果判断需要报修 → 通过群机器人 Webhook 推给维修群
· 维修人员点开消息里的链接 → 打开 H5 页面填写维修单
一个场景用了三种方式，每种做它最擅长的事。
坑一：回调地址必须是公网 HTTPS，且要在企微后台配置可信域名。内网部署的项目需要一层反向代理。
坑二：消息回调有重试机制，如果服务响应慢，企微会重复推送。要做幂等处理（按 msgid 去重）。
坑三：自建应用需要配置「可见范围」，没配的话员工看不到应用，会以为没上线。
坑四：H5 页面的 JS-SDK 签名要用后端生成，前端不能自己算，否则会报签名错误。