业务模式

由于微信的火爆，出现了很多提供公众号二次开发的平台公司。主要的业务都是为客户的公众号做二次开发，提供诸如微门户，微商城这样的服务。一般都是客户在平台上申请一个唯一的业务ID，然后将自己的公众号绑定到此ID上，所以公众号和微站是一一对应的

但是，申请公众号，特别是认证服务号的门槛比较高。我司由于所处行业的特点，用户基本上很难有资质申请到。所以我们的模式，是由我司提供一个共享的公众号，用户可以使用共享公众号提供的服务；同时如果用户自己能够提供公众号，也支持将专用的公众号接入到平台

URL规划

前面说到，大部分平台公司提供的微站URL类似于这样：www.pt.com/wsite/:ptid/shop，然后根据路径中ptid，就可以再从关联表中查到此ID对应的公众号信息（包括app_id，app_secret等）。因为前面说过，这种模式的平台id和公众号是一一对应的，所以才能这么做

但是混合模式的话，URL需要带上公众号的标识才行，所以URL类似：www.pt.com/wsite/:appId/:ptId/shop，多了一个appId，这样才能区分出，此页面当前是从哪个公众号打开的。如果URL中没有这个标识的话，由于一个页面，既可以从共享公众号打开，也可以从专用公众号打开，那么就没有办法判断当前所在的公众号了

比如以下这个场景，从微信OAuth页面跳转到微站，得到了访问者的code，接下来就需要根据code调用公众平台接口获取open_id，调接口需要app_id作为参数，此时URL中的appId就可以起作用了

数据模型设计

在数据库中保存粉丝的绑定关系时，混合模式也需要多保存app_id字段。比如业务系统里有member_id，那么专用的模式，可能只需要保存member_id和open_id就足够了，因为根据member_id，就足以找到平台唯一id，继而关联找到app_id，所以open_id对应哪个app_id也是唯一的

但是共享公众号和专用公众号混合的模式，上述数据模型也是不行的。因为最终用户可能是从专用公众号绑定的，也可能是从共享公众号绑定的，所以光凭借member_id，无法唯一确定app_id，因此在数据库表里，也需要同时保存app_id，才能唯一标识出粉丝，正确调用接口

比如以下这个场景，当用户到店消费以后，要给他发送一条模板消息。虽然根据member_id找到了open_id，但是还需要app_id才能调用模板消息接口，如果没有保存app_id的话，光凭借member_id，是查不到的

总结

关键是我们的平台不但提供了共享公众号，还支持专用号和共享号的混合模式。所以凡是涉及到用户标识的地方，都需要主动携带app_id信息。而平台id和公众号一一对应的方案，就不需要，因为可以根据平台id关联找到对应的公众号

微站共享公众号的方案设计