企业微信账号实例怎么隔离

两个维度，别混着问

环境维度问的是「这次调用属于哪一套环境」：开发、预发、生产。业务维度问的是「这次调用代表哪条业务线」：售前、售后、某个区域团队。两者正交，一个账号实例在这两个维度上各占一个坐标，谈隔离必须先说清楚在谈哪一个。

混着问的典型症状有两个，而且经常出现在同一个团队里。一个是「我们业务线不多，所以不用隔离」，于是开发直接拿生产账号联调。另一个是「隔离越彻底越好」，于是渠道、活动、坐席各开一个号，实例数按业务组合数膨胀，每一个都要一个真人去扫码，每一个都要一份持续运维。

还有一种混法更隐蔽：把隔离理解成「多开几个号分摊风险」。分摊风险要先看风险源在哪 —— 如果风险来自平台侧的账号异常，多个实例确实能降低整体停摆概率；如果风险来自你自己的调度代码，多开号只会让同一个 bug 同时作用在更多号上，把一次单点故障放大成一次全线故障。

环境这一刀不能省

理由不是「规范要求」，是三件具体的事，每一件都没法靠纪律绕过去。

1. 1登录态只有一份。同一个账号实例在同一时刻只有一套会话，你没办法让它「对开发流量表现成开发环境」。共用之后，联调期间的任何一次重登或状态切换，都会直接打在生产链路上。
2. 2事件订阅没法按环境分流。事件是按账号推的，不是按调用来源推的。共用一个实例，开发服务和生产服务会收到同一批事件，谁处理、会不会被处理两遍，只能靠人去约定 —— 而人在赶进度的时候不遵守约定。
3. 3发送节奏是共享的。账号侧的频率约束按账号算，联调阶段的重复请求会挤占生产的发送节奏。这一条最阴险，因为它不报错，只是让生产链路慢一点点，慢到你以为是平台的问题。

代价的形态也和普通环境事故不一样：脏数据可以清，但一条测试消息发到真实客户那里是不可撤销的。这就是为什么这一刀要在项目第一天切，而不是等第一次误发之后再补。

开发和预发的实例不必和生产同规格，但必须是真的独立账号，不能是「生产账号在非高峰时段借用一下」。借用这件事在日历上成立，在事件推送上不成立 —— 事件不会看你的排期表，它照推不误，而收到它的两套服务都会认为该自己处理。

具体做法其实很轻：给开发和预发各准备独立的账号实例，配置里把实例标识和环境绑死，不允许从环境变量以外的地方读到生产实例标识。企微接口这一层不需要为此改任何代码 —— 用 wecomapi 接入时，端点、鉴权和请求结构在各环境是一样的，变的只是这次调用用哪个实例。

业务这一刀默认不切，四个信号出现才切

默认不切的理由在上一节的成本里。出现下面任意一个信号，才值得为它单开一个实例；一个都不成立，你要的是一个字段。

1. 1对外身份必须不同。客户看到的是谁，这件事本身就是业务要求 —— 售前和售后用同一个号，客户的心理预期会错位。这是唯一一个「不切就做不了」的信号，其余三个都是「不切会很难受」。
2. 2发送节奏要互不影响。一条线的批量作业会不会饿死另一条线的客服回复？如果两条线高峰重叠、又都在意时延，共用一个号的发送节奏迟早会演成「因为在发通知，所以客服回不了话」。
3. 3爆炸半径要隔开。一个实例掉线，能不能只停一条业务线？两条线挂在同一个号上，那这个号的可用性就是两条线可用性的上限，谁也别想比它高。
4. 4数据与审计边界。不同法人主体、不同客户群体，会话记录和日志能不能互相看到 —— 这通常不是技术问题，是评审问题，而评审的结论没法用架构绕过去。

有一个理由经常被误当成第五个信号：报表要分业务线。它不构成切实例的依据。报表要的是维度，一个字段就能给，而且字段能随时补算历史。凡是以「为了统计方便」提出的切分请求，都该被打回去重写成「为了什么业务约束」。

四个信号都不成立时硬切，得到的是一堆低负载实例：每个都要监控、每个都可能掉线、每个都摊薄你的注意力，而业务上它们本来可以是同一个号加一个字段。wecomapi 把登录、保活与实例隔离收敛在平台侧，省掉的是维持这些实例的工作量，省不掉的是它们占用的注意力 —— 后者才是实例数的真实上限。字段和实例的根本区别在可逆性：字段填错了改一行数据，实例开错了要么留着当负担，要么走一次带客户身份迁移的下线流程。

第三个维度一律用字段

渠道、活动、坐席、租户这类维度会不断冒出来，共同点是数量不封顶、生命周期短。它们一律用字段承载，不要用实例承载。判断只要一句话：这个维度半年后还会不会存在？答案不确定的，就不配拥有一个实例。

落到调用侧，规矩是业务维度不进请求体，它属于你自己的路由层。路由层的唯一职责，是把「哪套环境、哪条业务线、什么动作」翻译成一个具体的实例标识，然后走同一套接口发出去。

// 示意代码，实例标识的精确语义与字段以线上文档为准

function pickInstance(env: Env, bizLine: string, tenant: string) {
  const key = `${env}/${bizLine}`;    // 只有这两个维度参与选实例
  const guid = INSTANCE_TABLE[key];   // tenant 只是自己库里的一个字段
  if (!guid) throw new Error(`没有为 ${key} 配置实例`);
  return guid;
}

// 选完之后，调用形态对所有业务线都是同一个：
//   POST https://manager.wecomapi.com/message/sendText
//   { "guid": "<pickInstance 的返回>", "toId": "...", "content": "..." }

路由表本身该放配置中心，不该硬编在代码里：实例会因为掉线、更换、临时借用而变，改一次映射不该走一次发版。但它必须有审计 —— 谁在什么时候把哪条业务线指到了哪个实例，这条记录在排障时的价值超过大多数日志，因为「消息为什么从这个号发出去」的答案永远在这里。

这一节的重点不是代码，是那句注释：换业务线只是换一个实例标识，接口形态、鉴权和错误模型都不变。所以在实例数上做加法，加的从来不是开发量，加的是运维面 —— 而运维面是按月付账的那一项，开发量是一次性的。

实例是有历史的资源，切了就不好合

前面所有判断的底层理由是同一条：实例不是无状态容器，它带着历史。这条决定了切分基本上是单向操作。

• 会话历史挂在实例上。合并两个实例，等于要把两段互不相干的会话拼成一段，时间线能拼，上下文拼不了。
• 客户身份挂在实例上。同一个人加了你两个号，在两个实例下就是两个互不相通的外部身份。合并实例意味着要合并客户身份，而这件事没有可靠的自动判据，最后只能人工核。
• 客户那边的观感也挂在实例上。号一旦下线，加过它的那批客户就断了联系。这是唯一一段技术上无解的部分，其余都只是工作量。

还有一个常被忽略的方向：切分决定了你的告警面板长什么样。实例是最自然的告警维度，实例数基本就是面板的行数。行数超过一屏之后人就不看了，而这正是「多切一个实例」那笔运维成本里最贵、也最难量化的一项 —— 它不体现在账单上，只体现在下一次掉线没人第一时间发现。

由此得到两条不对称的建议：环境维度宁可早切，它的代价是一次性的准备工作；业务维度宁可晚切，它的代价是不可逆的。拿不准的时候先加字段跑三个月，等信号真的出现了再拆 —— 从「一个实例加字段」拆成「两个实例」，比从「两个实例」合回去容易一个数量级。