虽然是第二次开发小程序，但是上次做小程序已经是一年前的事了，所以最终还是被坑得死去活来。
这次是从零开始开发一个小程序，其实除了一些莫名其妙的兼容性问题，大多数坑点都是在微信小程序的各个入口场景处。
所以这里整理一下微信小程序的各个入口场景，以及从这些入口场景进入小程序会面临的问题以及解决方案。
这里只列出常用的几种场景：
[简单场景]启动小程序并进入
[简单场景]退出重进（启动小程序后，退出小程序，再次进入小程序）
[简单场景]退出重进首页（启动小程序后，退出小程序，通过扫二维码再次进入小程序）
[复杂场景]启动并进入指定页面（从小程序的分享卡片或者微信发送的通知消息进入小程序）
[复杂场景]退出重进指定页面（启动小程序后，退出小程序，从小程序的分享卡片或者微信发送的通知消息进入小程序）
启动小程序并进入
微信小程序的入口场景光微信提供的场景值就有几十种，但是绝大多数都可以划分为启动小程序并进入。
这是最常用的一种进入小程序的方式，比如通过搜索进入或者点击最近使用小程序的方式进入，都算是这种类型。
这一场景下，首先我们需要明白发生了什么：
下载小程序 => 启动小程序 onLaunch事件触发 => 加载首页 onLoad事件触发 => 首页 onShow事件
然后在这个场景下，需要注意以下几个问题：
1.这个场景下一般会涉及到登录。
所谓登录，不一定是要在这个阶段做，但是登录信息的判断这个阶段是一定要做的。
通常前端肯定是要将登录的这些信息存储在小程序的storage里，然后在onLaunch事件中判断是否登录，没登录就跳转到登录页面，登录了就跳转到首页。
这里的登录判断一定要放在onLaunch，而不要放在首页的onLoad里面，因为小程序启动一定会进入onLaunch，而不一定会进入首页的onLoad。
2.而登录页面在设计的时候最好要加上一个url参数
传入登录成功后跳转到的页面地址，而不是登录之后始终跳转到首页，后面会讲为什么需要这么做。
3.onLaunch阶段是否有发出请求
并在请求完成后进行了页面跳转，或者请求完成设置storage，并在onLoad页面中使用？
这种情况的出现，会导致在请求时间过长时，首页的onLoad已经执行了，此时就会出现BUG。
对于这个问题，有的人会用定时器去判断是否完成这个操作，但是我的建议是尽量避免在onLaunch中进行这些操作。
如果一定要有，那么最好的方式就是做一个加载页面去承载这些功能。
4.首页数据的初始化
一般是放在onLoad中执行。当然总是有些特殊的需求是要放在onShow里面的。
关于onLoad和onShow，最常见的处理区别就在跳转页面时。
当载入首页时，先触发onLoad，再触发onShow。
此时通过wx.navigateTo 的方式跳转到页面A，这个时候首页并没有被关闭，那么从页面A再返回首页时，onLoad就不会触发，但onShow会触发。
通常在加载数据时，一般会用到onLoad。
但是如果说页面A更新了数据，然后返回首页时，首页的相关数据也需要更新。
那么初始化数据就不能放在onLoad里，而需要放在onShow里。
（当然还有一种方式是通过getCurrentPages的方式在页面A中调用首页的方法。但是这里极不推荐这种方式，属于某个页面的事情一定要给这个页面。最好不要将页面间的职责通过这种方式打乱，容易引起代码混乱，不易维护。）
退出重进（启动小程序后，退出小程序，再次进入小程序）
这种场景实际上是对第一种场景的扩展。
而所谓的退出小程序不管你是点右上角的退出按钮还是Home键直接切出都算是这类退出。
但是退出后再立即进入小程序的时候，依然会进入你退出小程序时所在的页面，而不会触发onLaunch，也不会触发这个页面的onLoad，不过onShow是肯定会触发的。
这一场景下，首先我们需要明白发生了什么：
再次进入小程序 => 进入退出小程序时所在页面 触发onShow
在这个场景下，只需要注意onShow中是否有不可重复执行的操作。
例如onShow中会获取用户喜欢吃的食物，加载到页面的列表中，在这种场景下，如果不清空之前的列表或者加个判断的话，就会出现重复数据。
退出重进首页（启动小程序后，退出小程序，通过扫二维码再次进入小程序）
这种场景实际上是对第二种场景的扩展。
我们通常给二维码配置的是一个无参数的小程序首页地址，当我们退出小程序，通过扫二维码再次进入小程序时会进入首页。
这一场景下，首先我们需要明白发生了什么：
再次进入小程序 => 进入退出小程序时所在页面A 不触发onShow => 触发页面A onHide => 触发页面A onUnload=> 进入首页 onLoad => 首页onShow
在这个场景下，除了需要注意第二种场景存在的问题，还需要注意页面A的onHide事件中是否会触发奇怪的操作，例如页面跳转。
启动并进入指定页面（从小程序的分享卡片或者微信发送的通知消息进入小程序）
这块场景常见于邀请他人进入小程序，需要注意的是他们往往被赋予了更多的业务功能，也就往往增大了小程序的实现难度。
这一场景下，首先我们需要明白发生了什么：
下载小程序 => 启动小程序 onLaunch事件触发 => 加载指定页面 onLoad事件触发 =>指定页面 onShow事件
这里就可以看出，并不是进入小程序就一定会进入首页的onLoad。
所以这就是为什么之前强调不要将登录判断放在首页的onLoad中，而一定要放在onLaunch里。
但是这里又和扫二维码不同，扫二维码的链接一般都是指定的首页。
而这里通常跳转到的是非首页的页面，而且可能还多了复杂的业务功能。
我们在需求分析和设计阶段应该更多地考虑到这里可能会引发的复杂问题，而尽量将此处的业务逻辑简化，或者加大估时。
接下来，我们将根据业务从简单到复杂，慢慢讲解这个场景下可能存在的问题。
最简单的邀请函（进入小程序首页）
和第一种场景差不多，这里略过
进阶邀请函（进入小程序指定页面，带参数，需要根据参数初始化页面）
这种情况下，需要考虑以下几个问题：
1.首先在onLaunch阶段会判断是否登录
没登录那么就需要跳转到登录页面，登录页面登录之后，肯定要跳转到这个页面，而不是首页。
所以之前说过登录页面设计的时候需要传入一个url参数，来明确登录成功后跳转到哪个页面。
2.这种跳转到指定页面的情况通常都需要一个回到首页的按钮
就比如邀请某人查看一篇文章，点击邀请卡片后会进入小程序内的文章详情。
一般在小程序内通常是通过点击文章列表跳转到文章详情，那么这个时候可以逐级返回到首页。
但是在点击邀请函进入的情况是没有返回功能的，此时如果没有回到首页功能，那么用户可能就永远没法回到首页。
（其实是可以的，但是小程序的的这个功能藏得比较深，不要指望所有用户都那么热爱摸索）
3.这里一定要特别注意第一种场景的第三个应该注意的问题
对于第一种场景而言那个问题因为启动次数很多容易出现，但是在当前的场景下可能很容易被忽略掉。
涉及身份的邀请函（进入小程序指定页面，带参数，需要根据参数切换身份，更可能涉及到登录）
为了更好地说明这种情况，我们来列举一个场景。
如果有一个打车软件，进入这个软件后有两种身份，一种是乘客，一种是司机。
用户是司机，那么看到的是页面A或者选定了TabA，如果是乘客，那么看到的是页面B或者选定了TabB。
而且还有一个需求，用户上次登陆时什么身份，这次登陆也是什么身份。
考虑到换手机的场景，那么这个信息肯定是存储在服务端的，所以进入小程序的时候会去请求服务端进行判断。