小程序开发的与众不同
距离上次发文已经一年了，我真是个懒惰的人啊！！！
元旦过完了，假也休完了，开始新的一年了，总结一下最近开发小程序的与众不同之处。
1、小程序必须设置合法域名，否则无法发出请求。
官方文档是这么说的：
注意：域名只支持https,不能使用IP或者localhost，域名必须经过ICP备案，每个接口最多设置20个域名。
那么问题来了，我们开发的时候的域名不符合上面的要求啊！怎么办？
在微信开发者工具中有这个：
点击这个双箭头，从详情中
选择不校验合法域名，这时候就可以开发啦。同样，在真机调试时，也需要打开调试模式哦。
2、小程序登录态的管理
通常我们在做网页开发的时候会用cookie来管理登录态，但是小程序没有cookie。小程序官方建议的的登录态管理是这样的：
简单说就是：
（1）前端同学调用微信小程序api：login()拿到code传给后端
（2）后端拿着appid、appsecret和code调微信接口服务返回session_key+openId等，后端自定义登录态返给前端
（3）前端将自定义登录态存储到storage里，每次发请求时候带着
我们遇到的坑：用户切换账号时，由于登录态存储在了storage里，所以即使切换账号拿到的还是之前的用户的登录态，后端根据此登录态认为当前用户还是原来的用户，所以就乱了……
填坑方法： 当用户每次启动时都校验一下登录态是否过期，调小程序api:checkSession。我们在小程序官方文档上并没有找到明确说明若微信切换账号，登录态会过期，但是根据网友的建议和实际测试证明，若切换账号登录态的确会过期，那么过期之后重新问后端请求新的登录态，在请求数据就ok了。
3.小程序更新机制
我们遇到的坑：我们的小程序第一次上线是个全新的，所以不存在更新不更新之说，第二次上线就有了更新问题。第二次上线发布之后，同事们打开小程序发现并不是新版啊！！还是旧版啊！！
更新机制是怎么样呢？
要说更新得先从小程序的运行机制来说，speak is cheap,show doc:
也就是说，当我们发布新版小程序时，用户只有冷启动两次才能使用新版的小程序？what？我不接受……
官方提供解决思路：
1. 同步检查更新（放弃）：可能是最直接的解决思路，但主要问题是会影响小程序的启动速度，当下小程序的更新迭代是非常频繁的，部分用户可能每次启动都命中更新，如果需要同步检查更新+同步下载新的版本，那将会影响这部分用户的启动体验。
2. 模块热替换（放弃）：从技术上来说，这是最好的方案，小程序运行起来后，在打开新页面时，马上应用新版本里的页面，但这就会存在新旧逻辑、页面共存问题，对于开发者来说，反而更不好处理，特别是涉及到全局变量时，情况会更复杂，对于我们已有的框架来说，也是一个大挑战，不过这个也是我们之后努力的方向。
3. 定时 check 新版本（目前方案）：6.6.3 及以上版本的客户端，会定时 check 最近使用过的小程序是否有发布新版本；如果有，下次打开的时候会同步更新新版本再打开。这可以保证在新版本发布 24 小时后，所有小程序都能使用最新版本。（这部分是微信客户端自身优化，开发者无需关心）
4. 异步更新 + 强制更新（目前方案）：同步检查更新与模块热替换两者之间的折衷方案，即还是维持异步更新机制，在异步下载完小程序代码包后，提供重启小程序的能力，这样在遇到紧急问题时可以马上解决。
异步更新 + 强制更新方案介绍
从基础库 1.9.90 开始，我们提供了 wx.getUpdateManager 接口，使用该接口，可以获知是否有新版本小程序、新版本是否下载好以及应用新版本的能力。
当小程序冷启动时，会自动向微信后台请求新版本信息，如果有新版本，会马上触发新版本的下载。开发者可以通过 wx.getUpdateManager，获知当前更新的状态。
最佳实践
从用户体验上来说，我们还是建议只在非常必要时才强制用户重启更新，例如出现线上紧急 BUG。通常情况下，可以选通过弹出选择框让用户选择是否重启更新（实现请参考示例代码）。
哎呀，匆忙结尾，若有错误，欢迎指正，3Q
愿我们有能力不向生活缴械投降---Lin