企业官网建设流程全解析

做微信二次开发都遇到过这种场景：客服程序要用 Eyun 接口回消息、运营要用它发通知、数据分析要用它拉历史记录。三拨人盯着同一套能力（Webhook + sendText + 消息记录），各写各的代码会大量重复，wId 和 Token 也难统一管。复用不是"大家都把接口调一遍"，而是按复用粒度分层共享——Eyun 这套能力可以被多个业务程序复用，但粒度不同管理方式也不同。下面按粒度从粗到细分三层。

一、接口级复用：多个业务直接调同一个 Eyun 接口

三个业务程序各自独立调 Eyun 接口，互不感知。客服程序调 Eyun 的 sendText 发回复，运营也调 sendText 群发通知，分析调消息记录接口拉数据。按 Eyun 开发文档规范，sendText 需传 wId、toUser、content 三个必填参数，三个程序传不同参数复用同一接口，代码在业务程序里，wId 和 Token 散落各处。

大白话：3 个部门共用一台打印机——各打各的，互不干扰，但都在用同一台机器。

二、服务级复用：封装成微服务，多个业务通过 API 调用

把这套 Eyun 接口封装成 WechatService 微服务，对外暴露"发消息 / 收消息 / 拉历史"三个 API。客服、运营、分析各自调 WechatService，不再直接碰 Eyun 接口。WechatService 内部统一管 wId + Token + 错误码 + 限流，Eyun 的错误码体系（1002 需刷新、1004 需退避）由服务统一处理，业务程序只拿业务结果。

大白话：3 个部门共用一个"文印中心"——文件交过去，中心帮你打印、管纸量、处理卡纸，各部门不用自己管打印机。

三、平台级复用：搭建微信能力平台，业务程序作为租户接入

平台统一管理多个 wId 实例 + Token 池 + 回调分发 + 消息路由 + 配额管理。每个业务程序作为"租户"接入，按需申请配额（每天发 N 条），平台按配额调度 wId 和接口调用，租户间配额隔离。在 Eyun 平台 管理的多个 wId 实例由平台统一调度，业务程序感知不到底层 wId，只关心"还剩多少配额"。

大白话：建一个"文印服务公司"——各业务程序是客户，按套餐用打印服务，公司统一管所有打印机和纸张分配。

三层复用对比

演进代码骨架

def send_direct(wid, token, to, content): # 接口级：业务直调 Eyun return eyun_send_text(wid, token, to, content) class WechatService: # 服务级：统一封装 def __init__(self, wid, token): self.wid, self.token = wid, token def send(self, to, content): try: return eyun_send_text(self.wid, self.token, to, content) except EyunError as e: if e.code == 1002: self._refresh(); return self.send(to, content) if e.code == 1004: time.sleep(2); return self.send(to, content) raise class WechatPlatform: # 平台级：多租户配额 def __init__(self): self.quotas = {} def send(self, tenant, to, content): if self.quotas.get(tenant, 0) <= 0: raise QuotaExceeded() self.quotas[tenant] -= 1 return self._pick_wid_and_send(to, content)

选型建议

三层按"管理粒度递增"排列：接口级最松散（各调各的，重复代码多）、服务级中等（统一封装减少重复）、平台级最集中（统一管理 + 配额 + 隔离）。选型信号：3 个以下业务用接口级，够用就行别过度设计；3-10 个用服务级，减少重复 + 统一错误处理；10 个以上用平台级，做配额隔离和资源调度。

无论哪层复用，Eyun 接口的参数规范不变，变的是"谁管理调用"——业务自己管、微服务管、还是平台管。接口参数细节见 Eyun 开发文档，按业务规模选合适粒度，才是落地关键。