绑定公众号之后，粉丝身份和站内账号要不要打通

内容站绑定微信公众号之后，粉丝身份和站内账号要不要打通，取决于站点有没有会员内容与订单场景：公众号对接管的是消息与粉丝触达，站内账号管的是访问权限与用户组、VIP 分组，本来就是两条独立链路。只做公开内容浏览时不必打通；有会员可见内容、有交易场景时再做身份映射，鉴权仍然由站内完成。

两条链路各管什么

公众号对接负责站外那一侧：关注关系、消息回复、把内容摘要推给粉丝。站内用户管理负责这一侧：账号、用户组、VIP 分组，以及不同用户组能访问哪些内容。订单管理、财务管理、分销管理都挂在站内账号这一侧，因为它们要落到一个可追溯的站内身份上。

两条链路在后台是两个独立入口，各自维护各自的数据。不存在绑定了公众号就自动拥有会员体系这件事，也不存在做了用户组就省掉公众号配置这件事。

先判断有没有会员内容

分三种情况看。只做公开内容浏览的，不需要打通，粉丝在公众号里读完就够。有会员可见内容的，站内身份必须成立，否则权限没有判定对象，用户组设置无处生效。有订单、分销、财务这类交易场景的，身份不打通会出现同一批人留两份数据，事后归不到一起。

第二、第三种才是需要投入的地方，第一种强行打通只会多维护一份映射关系，收益看不见。

打通时的身份映射与鉴权边界

打通只解决一件事：把站外的一个稳定标识和站内一个账号对应起来。这层对应关系怎么建、由哪一侧记录，属于对接方案要写清的边界；系统这边承担的是账号、用户组与 VIP 分组这一层，身份对应不改变权限的判定对象。

边界要说清楚。鉴权由站内完成，接口层用内置的 JWT 认证，登录态与有效期都在系统自己手里；权限判定不看外部标识，只看这个账号属于哪个用户组。身份映射回答的是「是不是同一个人」，用户组回答的是「能看到什么」，两者分开放，改任何一边都不会牵连另一边。反过来做，把外部标识当权限来源，就会出现标识变更后权限漂移。

不打通时的权限分层做法

不映射身份也能把内容分层：会员内容按用户组设置访问权限，读者在站内自行注册；公众号侧只做导引，给摘要和标题，正文回站内看。有交易需求但不想维护映射的，订单与财务都在站内闭环，分销关系用站内账号记录，公众号只当一条通知渠道。这条路的代价是注册转化慢一层，换来的是权限模型只有一套，不容易出越界。

常见的两处误配

一处是把外部身份当权限依据：按外部标识直接放行某类内容，等于绕过用户组设置；外部来源里同名标识撞在一起时，两个不同人的可见范围会互相污染。另一处是把渠道当分组：给「来自公众号的访问」整开放行，而不是给具体用户组开权限。渠道只应该影响引导文案，权限一律由用户组和 VIP 分组决定。

顺带说明，敏感词过滤、防采集干扰码属于内容与采集层面的防御，SQL 注入和 XSS 这类攻击面也有对应防护，但它们都不参与身份判定，别指望它们挡住越权访问。

常见问题

问：打通之后，粉丝还需要在站内再注册一次吗？ 答：取决于对接方案有没有记录这层对应关系；没有记录时，读者进站仍走正常注册。系统这边负责的是账号、用户组与 VIP 分组的权限判定，注册与否都不改变鉴权由内置 JWT 认证负责这一条。

问：能不能让公众号那边直接判断谁是会员？ 答：不建议。外部标识只用于身份对应，权限判定留在站内用户组，鉴权由内置 JWT 认证负责，规则改动才不会出现两边口径不一致。

问：VIP 分组和用户组是一回事吗？ 答：不是。VIP 分组面向前台读者的内容档次，用户组面向访问权限的分层，两者可以叠加，但各管一层。