微信作为一款app，提供了友好的用户体验，在开发微信应用时，我们应该尽可能得让自己的网页像webapp一样。用户使用我们的网页，就好像在使用微信内置的app，这样用户才会喜欢我们的网站。

   本文将讲解微信开发的前期准备，包括微信开发上的一些坑、架构上的设计、接口上需要注意的地方，全部来自自己的开发经验，如有不对，请指正。

微信开发的坑

1、微信授权

    微信中涉及到了OAuth2.0网页授权，正因为这样，我理所当然的用这个接口来读取用户的基本信息，包括头像、用户名等，因为之前了解过淘宝的公众平台，大家都是这么玩儿的。

    后来走了不少弯路，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并不会重新生成，其实可以想象微信为了不让开发者的服务器不断重建session造成压力已经将sessionId持久化了一段时间。

    sessionId其实是服务端识别用户所属session的标识，只要sessionId不变，那用户的session上下文也不会变，也就不会重建session了。

    最合理的方案其实应该讲session自定义，比如使用memcache、redis等独立的缓存服务来存储session，好处是用户不打开我们的网站而是点击微信聊天窗口的菜单与我们的服务器交互时，我们照样可以识别是哪一个用户在与我们交互。

架构设计

    架构设计应与我们的网站系统业务相结合，大体上将几点值得注意的地方。

   1、第一点就是上面所讲的sessionId问题，如果我们自定义了sessionId，可以带来相当大的好处。在应用中，可以使用具有一定规律的自定义sessionId方便的找到一个用户，对用户进行操作。

   2、微信的接口和通常所说的接口有些不一样。通常的接口是两个系统间进行交互，而微信的接口是用户发起操作，我们的服务器访问微信服务器进行交互，返回数据给用户。相当于我们是一个中间件，供用户去操作微信。这就带来一个问题：当并发量大了之后，服务器不断的发送请求到微信，这对服务器的带宽都是一个不小的考验。

    所以我们需要适当考虑接口的重试机制。拿获取用户基本信息来说，完全有可能第一次请求无响应，第二次请求才成功，不要因为第一次的失败就导致我们拿不到用户的基本信息了。

   3、缓存。不止是针对微信，互联网网站缓存可以说是必不可少的。我比较喜欢使用redis来作为缓存，当然，mongodb也不差。

微信开发之架构设计