企业微信第三方接口怎么选型

先把「第三方接口」这个词拆开

检索「企业微信第三方接口」和「企微开放接口」时，落在同一个词底下的其实是三种供应形态，评估重点完全不同。

• 官方生态里的服务商应用：接口行为由官方规范定义，你评估的是这家服务商的交付能力与存续性。
• 网关式接入：对方把账号接入、登录态维持和接口封装一起交付，你的系统直接依赖它的语义，所以评估的是这套封装本身的质量。
• 外包自建：本质是买人力，评估对象是团队而不是产品，不在本文范围。

这篇讲前两种，尤其是第二种 —— 它的评估最容易被能力清单带偏，因为清单是对方写的，而你要承担的成本大多在清单之外。路线怎么选是另一个问题，这里假设路线已定，只谈同一条路线上怎么挑供应方。

第二种为什么值得多花两天尽调：你的业务代码依赖的是对方定义的语义，不是官方定义的语义。这层依赖在合同里几乎写不清楚 —— 合同能写清可用率和响应时限，写不清「某个字段的含义半年后不许变」。所以这部分保障只能靠工程手段自己拿，而拿的方式就是下面这六个指标。站内讲协议服务怎么挑供应商的那篇问的是另一半 —— 只能靠追问和条款确认的那部分，这篇不重复它，只收能在两天里自己量出来的东西。

前三个指标：决定联调与排障成本

这三个在接入的头两周就会显形，而且一旦不合格，后面每一次排障都要重复付一次代价。

1. 1文档的可执行性。不是看文档全不全，是看一个没接触过的工程师能不能不问人、照着文档在半小时内跑通「发一条消息加收一个事件」。这是可计时的，找个同事真跑一遍，记下每一次卡住的地方。不合格的样子很好认：错误码只有一张编号表没有语义说明、示例是跑不了的伪代码、字段的可选性与默认值不写、回调验证只有一句「按约定校验」。这一条测的其实是对方有没有真的用自己的文档接过一次。
2. 2错误语义的分辨率。故意造五种错误：参数错、权限不足、频率超限、对象不存在、账号状态异常，看返回能不能区分成五类。这一条直接决定你的重试逻辑能不能写对 —— 分不出来就只能全部重试或全部不重试，两种都是错的。标准很硬：能分成五类算合格，只有成功和失败两态的，你后面所有工程投入都要打折。
3. 3请求的可追溯性。每次调用有没有一个能报给对方的标识，以及凭这个标识对方能不能查到这次调用到底发生了什么。这条测的不是技术，是扯皮成本。验法是在 POC 期间真的提一次工单，拿一次失败的标识去问，看多久拿到结论。超过一天就要重新评估，线上出事时你等不起这个时间。

第三条落到工程上是一句话的事：把这个标识在每次调用时就记进业务日志。wecomapi 的响应里带的请求标识，联调阶段就该和你自己的追踪标识串起来，出事时一条查询就能把那次调用捞出来。等到线上出问题再回头补日志，你要补的偏偏是已经发生过的那一次，而它不会重演。

后三个指标：决定长期账单

这三个在头两周完全看不出来，但它们决定的是第二年的成本，而且都很难中途补救。

1. 1事件投递的可靠性契约。三个问题：投递语义是至少一次还是最多一次、失败重试几次重试多久、有没有补拉或重放的口子。第三个最关键 —— 没有重放口子的事件通道，一次故障就是一段永久的数据缺口，而且你在故障当天根本不会知道缺了什么。这类问题的答案必须落成文字，比如 wecomapi 的事件是否支持按时间窗重放，要在文档里找到明确说法，口头承诺在故障当天不作数。
2. 2变更的透明度。有没有状态页、破坏性变更提前多久通知、新旧版本怎么并存。这一条两天里测不出来，只能查历史 —— 要过去半年的变更记录和一次故障复盘，给不出来本身就是答案；具体怎么问、什么样的回答算过关，站内讲协议服务怎么挑供应商的那篇已经拆成问句，这里不重复。
3. 3退出成本。迁走要多久，这个数要在签约前算，不是在想走的时候算 —— 该向对方要什么（导出样例、标识映射、历史消息在不在里面），同样见站内讲协议服务怎么挑供应商的那篇。这里只补你自己这侧能测的动作：业务代码里有多少个文件直接引用了对方的字段结构，grep 一遍就知道；留一层薄适配把这些字段挡在业务代码之外是唯一有效的对冲，第一天做成本几乎为零，第六个月做是一次全面重构。这层适配在 wecomapi 这类请求结构统一的形态下尤其便宜 —— 各项能力共用同一种调用形态，你要包的只是字段到自有模型的映射，而不是每个能力包一遍。

六条不等权。前三条是入场券：任何一条不合格就该直接淘汰，因为它们的代价是每天都在付的，不会因为价格便宜而变小。后三条是加权项，可以拿价格、交付周期或其他条件去换 —— 但换的时候必须写明白换掉的是什么，以及你打算用什么补。「事件不支持重放，我们自己做每小时对账」是一个可以接受的决定；「事件不支持重放，先上线再说」不是。

一个两天能跑完的 POC 清单

POC 的目标不是「跑通」。跑通只能证明最顺的那条路是通的，而你要买的是不顺的时候它怎么表现。

第一天照文档跑通发消息和收事件，全程计时，记录每一次需要问人的地方；然后造五种错误，看返回的可分辨程度。第二天做投递可靠性测试：把回调地址换成一个受控端点，让它在一段时间内返回 500，然后恢复，统计缺口。

// 示意逻辑，事件唯一标识的字段名以 wecomapi 文档为准
let mode = "ok";              // 手动切成 "fail" 持续若干分钟，再切回 "ok"
const seen = new Map();       // 事件标识 -> 首次收到时刻
const rejected = new Map();   // 被我们主动拒掉的那些

app.post("/probe", (req, res) => {
  const id = eventId(req.body);
  if (mode === "fail") {
    rejected.set(id, Date.now());
    return res.sendStatus(500);        // 制造一段人为故障
  }
  if (!seen.has(id)) seen.set(id, Date.now());
  res.sendStatus(200);                 // 恢复期照常快速 ACK
});

// 恢复十分钟后比对：rejected 里的标识有多少出现在 seen 里、各隔了多久回来

三种结果对应三种结论。全部补回来，说明至少一次的语义成立，你要做的只是幂等；部分补回来，说明有重试但有上限，你必须自己再做一套补拉；一条都没回来，说明这个事件通道不能作为唯一数据来源，业务上必须配定时对账 —— 这笔成本要当场算进选型里，而不是上线半年后再发现。

顺带还能测出第二件事：补投是密集重放还是平滑重放。密集重放意味着恢复的那一瞬间会有一个尖峰打到你的服务上，你的队列和限流得按这个尖峰来设计，而不是按平均流量。

POC 期间还要顺手记一个不写在评估表里的数：从你提问到对方给出结论的时间，以及回答给的是结论还是推诿。这个数在合作期只会变差不会变好 —— POC 阶段是对方最积极的时候，销售还在盯着。如果这时候一个技术问题就要等两天，上线之后的故障期你可以预期到什么水平。

评估表怎么填才不会变成打勾游戏

六个指标测完之后，最容易发生的事是把结果填成一张 1 到 5 分的评分表，加权求和，选总分高的那家。这一步会把前面两天的工作全部作废，因为加权求和的作用是把「事件不支持重放」这种硬伤稀释成零点几分的差距。

1. 1每个指标只允许三档：合格、勉强、不合格。不要打连续分，连续分是给自己留的模糊空间。
2. 2任何一项「不合格」都必须配一段文字，写清楚你打算怎么补、补的成本是多少人天、由谁负责。写不出来的，这一项就不叫勉强，叫不合格。
3. 3把这些补救成本加进总成本再比价。很多时候两家的报价差距，还不够填一项补救的坑。
4. 4评估表要留档，并在上线三个月后复盘一次。哪几项当初判断错了、错在乐观还是悲观，这个反馈是下一次选型唯一真正有用的输入。

不该当硬指标的三件事

有三样东西最容易主导决策，又最没有预测力。

• 单价。要看的是计价单位，不是单价。按调用次数计价，你的重试、幂等校验、定时对账这些工程上正确但调用量大的做法会被成本模型反向绑架，最后往往是为了省钱把对账砍掉 —— 省下的钱不够赔一次数据不一致。按账号订阅、订阅内可无限次调用接口、不按调用次数计费（适用公平使用策略）的模式下，调用量不进成本模型，这类投入才做得起来。
• 能力清单的条目数。条目数和你要用的能力之间几乎没有相关性。正确做法是把未来半年真正会调的动作列出来，通常不超过十五个，只核这十五个，其余一律不看。清单长两倍不代表更好，只代表宣传页更长。
• 客户 logo 墙。它说明对方卖得动，不说明对方在你这个场景下跑得稳。有意义的是同规模同场景的具体案例，以及能不能真的联系到人问两句。

还有一条不算指标、但一定要写进评估表：对方的接入形态需不需要你自备服务器、自己维护登录态。SaaS 形态把账号托管和登录态维持收在平台侧，你的团队不需要为「让它活着」排班；自建或半托管方案要把这部分人力折算进总成本。折算方法很粗但够用：一次账号异常要占多少人分钟、一个月出几次、乘以账号数。wecomapi 这类托管形态把实例运行与异常恢复收在平台侧，这一项剩下的主要是确认告警的时间；自建方案里它是完整的排查加恢复。这笔钱从来不出现在报价单上，但它每周都在花，而且花的是你最贵的那几个人的时间。