微信公众号家族的API的规划思路是从 “公” 和 “私”两个角度划分的。导致代码也基本按照这个套路。
1 对公API是针对网站本身的API 走/cig-bin/目录 例如 微信公众菜单 ，用户消息，JSSDK 页面分享，地图服务等
2 对私API 针对网站用户的API 走/connect/ 或者/sns/目录的 例如 微信用户信息授权，微信支付等 。
诡异的是这两条线都有access_token的概念 ，所以很多初次接触微信API的人常常傻傻分不清楚 。
简单的说对私API的access_token是跟用户的客户端走的，不同的用户 不同的IP access_token在同一时间是不同的。
而对公的API的access_token可以在两小时内保持一样，无论客户端是谁都是同一个access_token.
为了解释方便 我们給两种access_token分别命名为 G access_token 和 P accss_token 简称G 和P
我们可以通过P的方式获取用户的openid存入数据库 或者其他什么地方。
P+openid 可以获取用户信息 通过请求/sns/userinfo
G+openid 也可以获取用户信息 通过/bin-cig/user/info
测下来这两种获取用户数据的方法 第G+openid更靠谱和准确，比如用户客户端语言的获取是正确的。而P＋openid获取的用户信息的语言貌似总是中文。
所以微信API的几条产品线我们可以这么区分：
1 针对网站或者公众号本身的有JSSDK， 微信公众号菜单，用户消息等
2 针对用户个人有微信授权，微信支付等
值得回味的是 公众号消息发送是G 针对某个用户发送消息的openid是被动的从用户回复消息里获取的。
由于多条G的产品线使用的access_token是一样的，那么这多条产品线的代码最好能共享access_token否则可能会造成access_token频繁失效 甚至报错。
