微信作为一款app。提供了友好的用户体验。在开发微信应用时。我们应该尽可能得让自己的网页像webapp一样。
用户使用我们的网页，就好像在使用微信内置的app，这样用户才会喜欢我们的站点。
本文将解说微信开发的前期准备，包含微信开发上的一些坑、架构上的设计、接口上须要注意的地方，所有来自自己的开发经验，如有不正确，请指正。
微信开发的坑
1、微信授权
微信中涉及到了OAuth2.0网页授权。正由于这样，我理所当然的用这个接口来读取用户的基本信息，包含头像、username等，由于之前了解过淘宝的公众平台，大家都是这么玩儿的。
后来走了不少弯路，oauth2.0仅仅是一个网页授权，它在微信中被分为高级接口中，其意义在于用户没有关注您的公众号可是仅仅要用户允许，你也能够读取到用户的相关基本信息。
前面我们讲到。我们应该把咱的网页做得尽可能的像一个webapp，我是不推荐大量使用oauth去授权的。
我们应该努力地让用户成为我们的粉丝，而且在后台数据库中做上标记：这个用户已经关注我们了。
这个标记非常实用，后面的模板消息、客服接口等都推送接口都须要用户已经关注我们的公众号了。
相同。用户关注了我们后。我们能够不使用oauth2.0去进行网页授权了，使用“获取用户基本信息”接口相同能够获取用户的基本信息。这样就不会有授权页面出现。大大提高了用户体验。
2、openId
openId往往被我们用来作为用户的唯一标识，事实上这是不正确的。openId仅仅在对当前公众号唯一，你能够觉得它是MD5(公众号ID+用户微信ID)。
我公司的产品设计到多个公众号。可是后台数据库可能重用，想当然的就把openId公用了，结果可想而知。
事实上微信为开发人员提供了UnionId的机制，通过获取用户基本信息中的UnionId来保证用户的唯一性，兴许再写Union机制的详细实现。
3、AccessToken
微信中基本全部的接口调用都须要一个accesstoken，这个accesstoken的获取是有频率限制的。正常情况下access_token有效期为7200秒，这个须要特别注意，我们能够将accesstoken持久化，获取accesstoken的方法推断是否该又一次获取。至于持久化的方法，能够使用redis、数据库、本地内存等。
4、session问题
大部分人觉得微信窗体关闭后，session就消失了。又一次打开窗体訪问应用相当于重建session。
这也是有问题的，微信中又一次打开窗体sessionId并不会又一次生成。事实上能够想象微信为了不让开发人员的server不断重建session造成压力已经将sessionId持久化了一段时间。
sessionId事实上是服务端识别用户所属session的标识。仅仅要sessionId不变，那用户的session上下文也不会变，也就不会重建session了。
最合理的方案事实上应该讲session自己定义。比方使用memcache、redis等独立的缓存服务来存储session，优点是用户不打开我们的站点而是点击微信聊天窗体的菜单与我们的server交互时，我们照样能够识别是哪一个用户在与我们交互。
架构设计
架构设计应与我们的站点系统业务相结合。大体上将几点值得注意的地方。
1、第一点就是上面所讲的sessionId问题，假设我们自己定义了sessionId。能够带来相当大的优点。在应用中，能够使用具有一定规律的自己定义sessionId方便的找到一个用户，对用户进行操作。
2、微信的接口和通常所说的接口有些不一样。
通常的接口是两个系统间进行交互，而微信的接口是用户发起操作，我们的server訪问微信server进行交互，返回数据给用户。
相当于我们是一个中间件，供用户去操作微信。这就带来一个问题：当并发量大了之后。server不断的发送请求到微信。这对server的带宽都是一个不小的考验。
所以我们须要适当考虑接口的重试机制。拿获取用户基本信息来说，全然有可能第一次请求无响应，第二次请求才成功。不要由于第一次的失败就导致我们拿不到用户的基本信息了。
3、缓存。不止是针对微信，互联网站点缓存能够说是不可缺少的。
我比較喜欢使用redis来作为缓存，当然，mongodb也不差。
