企微二次开发从哪开始

「二次开发」这个词底下压着两类需求

同样说要做企业微信二次开发，两拨人要的东西完全不同。一拨是企业自己的技术团队：把客户数据接进 CRM、把工单通知发到群里、让内部系统能读会话，服务对象是自己公司。另一拨是做产品的团队：要把这套能力封装成 SaaS 卖给几十上百家企业，服务对象是别人的公司。

这两类需求在接口层看起来很像 —— 都是发消息、都是拉客户列表。但在路线层是两个世界：前者要的是接入速度和编排效率，后者要的是可授权、可分发、可审计的交付形态。用后者的方案做前者，前置成本平白翻几倍；用前者的方案做后者，做到一半会发现规模化分发这条路压根没铺。

三条路线各自在解决什么

路线 A：官方开放平台 + 自建应用

企业管理员在自己的后台创建应用、配置可见范围与权限，开发者拿到凭证后调用官方接口。规范公开、边界清楚，是内部集成里路径最清晰的一条。它的成本几乎全在前置：能开哪些能力由管理员的授权决定，而管理员通常不是你的同事，配置一轮要排期；权限项、可见范围、网络出口这些但凡有一项没对齐，第一个请求就通不了，而且报错看起来还都差不多。

判断标准很简单：如果你能在一周内约到管理员、把后台配置一次性对齐，这条路的长期维护成本最低，出了问题也有公开规范可依。如果管理员在客户那边、要走对方的流程，这个「一周」会变成一个月，而且每加一项能力就再来一轮。

路线 B：官方第三方应用（服务商）

要把能力卖给多家企业，就不能让每家客户自己建应用，必须走服务商这条路：注册服务商、开发应用、提交审核、上架，客户企业授权安装之后你才拿得到调用凭证。三条路里它周期最长、前置最重，也是唯一一条能规模化对外分发的。

这条路真正的成本不在开发，在流程：审核有轮次、能力申请有边界、上架之后每次改动都要再走一遍。值得走它的唯一理由是商业模式要求 —— 客户企业必须以官方授权的方式把权限交给你。如果只是想快，别碰这条。

路线 C：网关式接入

把账号实例交给 wecomapi 这类网关托管，对外只面对一套 REST 接口。这条路的成本结构和前两条完全不同：没有审核轮次，也不需要等谁配后台，前置基本只剩「拿凭证」和「按文档完成实例绑定」两步，从零到发出第一条消息通常以小时计。它换来的是接入速度，代价在下一段。

它换来的是接入速度和编排集中，代价是能力边界由网关的覆盖面决定，而不是由你在后台勾了什么决定 —— 所以选型阶段要对着 wecomapi 文档逐项核、在预发环境实测，别按宣传口径估。它也不解决「以官方应用形态上架分发」这件事，那是路线 B 的活。

三条路线的选型对照表

维度            A 官方自建应用      B 官方服务商        C 网关式接入
--------------  ------------------  ------------------  ----------------
典型前置周期    数天到数周          数周到数月          小时到数天
主要成本落点    管理员配合与授权    审核与合规流程      能力核对与联调
能力边界由谁定  企业管理员授权      审核通过的权限项    网关的覆盖范围
交付形态        自有系统内部集成    可上架、可分发      自有系统内部集成
改动的代价      再约一次后台配置    再走一遍审核        改调用参数即可
不适合的场景    多客户规模化分发    只服务一家企业      需要官方上架分发

这张表里最该盯的是「能力边界由谁定」那一行。它决定的不是你今天能调什么，而是项目做到一半发现能力不够时，你要去找谁、要等多久 —— 找管理员是一次沟通往返，走审核是一个周期，核网关文档是半天。排期风险全藏在这一行里。

混合不是骑墙，是按边界切

三选一其实是个假命题。真实项目里最常见的组合是 A+C：组织架构、内部通知这类走已经配好的官方自建应用，客户会话与外部群这类高频编排走网关。B+C 也成立，但顺序是固定的 —— 对外分发的主干先上架，再补一条内部快链路；反过来指望网关替掉上架，那条路压根没铺。

混合具体按哪些维度切、两侧的长期账单差在哪，站内的「企业微信网关接入与开放平台六维对照」已经逐维对过，这里不重复。只提一条和排期直接相关的：混合会多出一份身份映射要维护，而它必须从第一天就开始记 —— 等数据攒起来再补，补的不是一张表，是一次迁移。

留一层 adapter，把路线决定推迟

路线可以选错，但不该选一次就锁死。在写第一个业务功能之前，把「发一条文本」「拉一次客户列表」这类动作定义成你自己的接口，官方接口和 wecomapi 的差异都关在实现里。这一层值不值得写不用再论证，真正决定它有没有用的是抽在什么粒度上。

// 示意逻辑，两侧的精确字段与鉴权方式以各自线上文档为准
const adapters = {
  official: (msg) => officialClient.send(toOfficialShape(msg)),
  gateway:  (msg) =>
    http.post("https://manager.wecomapi.com/message/sendText", {
      guid:    msg.accountId,
      toId:    msg.to,
      content: msg.text,
    }),
};

// 换路线时只动这一行，上层业务代码不用改
export const sendText = (msg) => adapters[ROUTE](msg);

注意要抽的是「业务动作」，不是「HTTP 请求」。抽成 request(path, body) 那种通用封装等于没抽 —— 路径和字段形状照样漏到业务代码里，换路线时该改的地方一个都没少。精确字段、错误分类与端点以 wecomapi 线上接口文档为准，不要照抄示意代码上生产。

排期时最容易少算的三件事

1. 1前置授权不是「一天的事」，是「一次沟通往返乘以 N 轮」。按往返次数排期，不按工时排期，这两个数差一个量级。
2. 2联调环境要独立。拿生产账号联调，第一次批量测试就会把真实客户打扰一遍，接着你要停下来解释一周。
3. 3异常路径要占预算。频控退避、回调重复投递、登录态失效重连，这三件事在演示阶段一次都不会出现，上线第一周会全部出现。给它们留出和主流程相当的时间。