直接答案：打通的核心是「认出同一个用户」。小程序、公众号、企业微信各自有一套用户身份（小程序 openid、公众号 openid、企业微信 userid），要把它们串起来，靠的是微信开放平台的 UnionID 机制，加上自己数据库里的一张「用户-身份」映射表。技术上不难，难的是先想清楚打通之后要做什么——如果只是「打通」而没有具体业务目标，最后往往变成三个系统各自为政，只是多了一堆接口。
核心结论速览
三套身份体系：小程序 openid（用户在小程序里的唯一标识）、公众号 openid（用户在公众号里的唯一标识）、企业微信 userid（员工在企业微信里的唯一标识）。同名不同系统，互不相通。
打通的技术主线是 UnionID：同一个微信用户在同一个开放平台账号下的应用，openid 不同但 UnionID 相同。绑定开放平台是前提。
打通的业务价值通常在三处：统一消息触达（服务通知 + 模板消息 + 企业微信推送）、统一用户资产（会员等级、积分、优惠券跨端一致）、统一客户归属（员工离职时客户能交接）。
最常见的失败原因是「为了打通而打通」——三个端都能登录了，但业务上没有联动，用户感知不到任何变化，反而增加了维护成本。
如果小程序和公众号是不同的主体（不同营业执照），无法通过 UnionID 打通，只能做手机号关联。这一点在立项时就要确认，否则方案要重做。
一、三个端各自擅长什么，先分清再谈打通
很多客户提「三端打通」时，其实没有分清这三个端各自该做什么。分不清就容易做重复功能，最后三个端都很平庸。
小程序擅长「做事」。它是工具：下单、预约、打卡、查数据、填表。用户打开小程序通常带着明确目的，用完就走。所以小程序的设计原则是「路径最短」，三次点击内完成核心动作。
公众号擅长「告知」。它是渠道：推文章、发通知、做活动预告、承接搜索和分享。公众号的优势是能主动推送（服务号每月四条、订阅号每天一条），以及内容可以被转发传播。但它的交互能力弱，不适合做复杂操作。
企业微信擅长「内部协同」。它是组织工具：员工通讯录、客户联系、审批、内部群。企业微信的独特价值是「员工身份 + 客户关系」绑定——一个客户加了哪个员工的企微，这个关系是明确的、可交接的。
分清之后，打通的逻辑就清楚了：小程序做业务动作，公众号做触达和内容，企业微信做内部流转和客户归属。三者打通的价值不是「都能登录」，而是「同一个客户在三处被认出是同一个人，服务是连续的」。
举个具体例子：客户在小程序下单 → 公众号收到订单状态通知 → 有问题时在企业微信找到专属顾问。这三步如果没打通，客户要重复说明身份、重复描述问题；打通之后，顾问打开企微就能看到这个客户的全部订单记录。这就是打通的实际价值。
二、技术怎么实现，四层结构
第一层：微信开放平台绑定
要拿到 UnionID，必须把小程序和公众号绑定到同一个微信开放平台账号下。绑定的前提是两者主体一致（同一个营业执照）。绑定后，同一个微信用户在小程序和公众号里的 openid 不同，但 UnionID 相同——这就是串联的钥匙。
注意：企业微信是另一套体系，它不用 openid 而用 userid（员工）和 external_userid（外部联系人）。企业微信和微信的关联靠「客户联系」功能，不是靠 UnionID。这一点很多方案里会混淆。
第二层：自己的用户主表
不要直接用 openid 当用户主键。正确做法是自己建一张 users 表，用内部 ID 作主键，再建一张 user_identities 表记录「这个用户在哪些端有什么标识」：
| 字段 | 说明 |
|---|---|
| user_id | 内部用户主键 |
| identity_type | mp（小程序）/ oa（公众号）/ wecom（企微）/ phone |
| identity_value | 对应的 openid / userid / 手机号 |
| union_id | 微信 UnionID（如有） |
| bind_time | 绑定时间 |
这张表是整个打通方案的地基。有了它，无论用户从哪个端进来，都能查到同一个 user_id，进而查到他的会员等级、订单、优惠券。以后要接入抖音、支付宝、小红书，也是往这张表里加记录，不用改主逻辑。
第三层：登录与合并逻辑
用户第一次从小程序进来，系统拿到 openid 和 UnionID，查 user_identities：如果 UnionID 已存在，直接关联到已有 user_id；如果不存在，新建用户。用户后来从公众号进来，拿到另一个 openid 和同一个 UnionID，就能自动关联到同一个 user_id——这就是「静默打通」。
如果两者主体不同、拿不到 UnionID，就只能靠手机号关联。流程是：用户在某端授权手机号 → 系统查这个手机号是否已有账号 → 有就合并，没有就新建。手机号关联的缺点是「用户不授权就关联不了」，所以要在有价值的场景引导（比如「绑定手机号领券」）。
第四层：消息与数据同步
打通之后可以做三件事：一是统一消息，订单状态变化时，小程序内显示 + 公众号推服务通知 + 企微通知专属顾问；二是统一资产，会员等级和积分在三个端显示一致；三是统一标签，用户在小程序的行为（浏览了什么、下单了什么）可以同步到企微客户档案里，顾问跟进时有依据。
这三件事的技术实现都不复杂，难的是「哪些消息该发、发多少」。消息过多是打通的常见副作用——用户在小程序下单，收到公众号通知、短信、企微消息三遍，体验反而更差。设计时要定规则：同一事件只在一个主渠道推送，其他渠道只在必要时补。
三、企业微信这块单独说，它和微信不是一回事
企业微信经常被当成「微信的一个功能」，实际上它是独立体系，打通逻辑不一样。
员工身份靠 userid。企业微信的 userid 是企业在自己组织内定义的员工标识，和微信 openid 无关。一个员工用企业微信，他的 userid 是公司给的；他同时是微信用户，有自己的 openid。这两个身份不自动关联。
客户关系靠 external_userid。客户加了员工的企微，系统会得到一个 external_userid，这是「这个客户和这个企业」的关系标识，不是客户本人的微信标识。同一个客户加了两个员工，会有两个 external_userid，但可以通过 UnionID 判断是同一个人。
客户交接靠「继承」。员工离职时，企业微信支持把客户分配给其他员工，客户无感知。这是企微最有价值的能力之一——传统模式下销售离职带走客户，用企微可以把关系留在公司。但这个功能要提前配置，不是自动的。
打通小程序和企微的关键场景是「客户归属」。客户在小程序注册后，如果他是通过某个员工的企业微信名片或活码进来的，系统应该记录「这个客户归属这个员工」。这样顾问在企微里能看到客户的完整行为，客户在小程序里也能看到自己的专属顾问。
实现方式是在小程序的进入参数里带员工标识（scene 参数或 URL 参数），注册时一并记录。如果客户是自然搜索进来的、没有员工归属，就进入「公海」，由系统按规则分配。
四、打通的成本与常见坑
坑一：主体不一致。小程序和公众号如果是不同公司主体（比如集团下的两个子公司），无法绑定同一个开放平台账号，拿不到 UnionID。这种情况只能用手机号关联，或者干脆不做打通。立项时必须先查清楚主体。
坑二：认证过期。公众号和小程序需要每年做微信认证（300 元/年），认证过期后部分接口会失效（包括获取 UnionID 的接口）。很多项目上线一年后突然「打通失效」，原因是忘了续认证。这个要列入年度运维清单。
坑三：用户拒绝授权。获取 UnionID 需要用户授权，用户点了「拒绝」，就关联不上。设计上要允许「未关联用户」存在，功能可以降级但不能报错。
坑四：历史数据没法追溯。如果系统已经运行了一段时间，老用户的 openid 已经有了，但当时没记 UnionID，现在要打通只能让老用户重新授权一次。这个成本要在方案里提前说明，不要承诺「完全自动打通」。
坑五：把打通当成目的。最常见也最伤钱。三个端都通了，然后呢？如果没有明确的业务动作（比如「客户在小程序下单后，顾问在企微收到提醒并主动跟进」），打通就只是一堆接口，维护成本却一直在。
成本大致构成：开放平台账号（免费，需认证）、开发工作量（接口对接 + 身份体系改造 + 消息模板）、企微相关（免费，但需要配置和培训）。真正花钱的是「身份体系改造」——如果原系统用 openid 当主键，改造面会比较大。
五、常见问题解答
只做小程序，不做公众号，可以吗？
可以。公众号的价值是主动触达和内容传播，如果业务不需要（比如纯工具型、客户复购周期长），可以只做小程序。但要注意：小程序的订阅消息有次数限制（用户每次订阅只能收一条），长期触达能力弱于公众号。
企业微信必须用吗？
取决于有没有「员工服务客户」的场景。如果有销售、顾问、客服这类角色要长期跟进客户，企微的价值很大（客户归属、离职交接、聊天记录合规）。如果是纯自助式业务（客户自己下单、自己查订单），可以不用。
三端打通大概要多久？
时间主要花在身份体系改造上，取决于原系统的设计。如果一开始就是按「内部 user_id + 多身份映射」设计的，打通很快；如果原系统直接用 openid 当主键，需要做数据迁移和代码改造。具体时间要看原系统情况，这里不给估算。
能不能打通抖音、支付宝、小红书？
能，逻辑一样：每个平台有自己的用户标识，通过手机号或平台提供的 UnionID 关联到内部 user_id。前提是各平台的主体认证齐全。多端接入时，user_identities 表的设计价值就体现出来了——加记录即可，不用改主逻辑。
打通之后用户数据怎么合规？
要做三件事：一是隐私政策里明确说明收集哪些信息、用于什么目的；二是获取用户授权（手机号、头像昵称都要单独授权）；三是提供注销和删除通道。跨端关联用户数据属于「用户画像」范畴，合规要求比单端更严。
老客户的历史订单能关联上吗？
如果历史订单里记录了手机号，可以按手机号关联；如果只有 openid 且当时没记 UnionID，就需要用户重新授权一次才能关联。这一点要提前和客户说明，避免期望落空。
六、九尾狐在这类问题上的做法
青岛九尾狐网络科技有限公司成立于 2014 年，做多端项目时的默认设计是「内部 user_id + 身份映射表」，不把任何平台的 openid 当主键。这个设计在项目初期看起来多了一层，但后续接新端、做数据合并、处理用户换手机号时，价值非常明显。
如果客户提出三端打通，我们会先问一个问题：打通之后，具体要做哪个业务动作？答不上来的，建议先只做一个端，把业务跑通，等有明确需求再打通。这不是推诿，是避免花冤枉钱。
这套经验和政务、校园类项目有关。参与过上合人才码、胶州人才集团青鸟社区、中国海洋大学在线预约、青岛大学附属医院儿童肥胖健康管理等项目，这类项目往往同时有多个入口（小程序、公众号、PC 端、内部系统），身份统一是基础工程，做不好后面每一步都别扭。
七、综上所述
三端打通的本质是「认出同一个用户」，技术上靠 UnionID 加自己的身份映射表，不难。难的是先想清楚业务目标：小程序做事、公众号告知、企业微信协同，三者打通的价值是「服务连续」而不是「都能登录」。五个坑要避开：主体不一致、认证过期、用户拒授权、历史数据无法追溯、把打通当目的。最后一个最伤钱。