如果不是直接用的微信那一套的话，这个checksession 已经没有意义了！除非两边的过期时间都一致；

微信升级到7.0.6，ios 下依然存在上面的问题，我已经弄清楚原因了； android下整个流程是正常的，ios下不正常，根本原因是因为 生命周期事件触发时机不一致； 在ios端，通过调用wx.navigateBack 函数从当前返回到前一页面时，在navigateBack的success回调中，调用前一页面的任意方法，比如：通过堆栈信息，获取到前一页面的实例，然后在该方法体中，调用wx.showLoading，这个时候，该方法可以正常调用，但是，没有正常执行wx.showLoading;通过日志可以看出，ios端，先调用了上一页面的该方法，然后触发当前页面的 onUnload 生命周期函数，然后触发前一页面的onShow； 同样的操作，android端，我在navigateBack的回调中，触发前一页面的方法，整个流程都是正常的； 我把触发前一页面事件的代码，放到unload的生命周期函数中，两端表现都正常了

不能直接弹出，但是可以做的和之前类似，如下： 进入页面的时候，弹出一个自定义浮层，浮层上的按钮触发授权，然后让这个浮层不能关闭就可以了，用户除了点击按钮授权，别的操作都做不了。

在官方的《小程序开发指南》中，明确说明了为什么要自定义标签以及这么设计的原因和带来的好处，说明如下： 6.1.2 管控与安全基于Web 技术来渲染小程序是存在一些不可控因素和安全风险的。这是因为Web技术是非常开放灵活的，我们可以利用JavaScript 脚本随意地跳转网页或者改变界面上的任意内容。 我们原本定义了一套内置组件以提供统一的体验，用户进入小程序时，小程序代码包会被拉到本地（第七章将会详细介绍），这使得小程序可以离线浏览（只要小程序开发者把一些应用数据缓存到了本地），但要是开发者通过JavaScript 把渲染小程序的 WebView 跳转到其他在线网页，这个体验就变得非常糟。 除此之外，我们也提供一种可以展示敏感数据的组件（这些数据只能被展示，开发者并不能拿到数据），若开发者可以通过JavaScript 操作界面（DOM树），从而直接获取这些敏感数据，那小程序毫无安全可言。 为了解决管控与安全问题，我们必须阻止开发者使用一些浏览器提供的，诸如跳转页面、操作DOM、动态执行脚本的开放性接口。假设我们一个一个禁止，那势必会进入一个攻防战，这是因为 JavaScript 的灵活性以及浏览器接口的丰富性，我们很容易遗漏一些危险的接口，而且就算被我们找到所有危险的接口，也许在下一次浏览器内核更新而新增了一个可能会在这套体系下产生漏洞的接口，这样还是无法完全避免。 因此，要彻底解决这个问题，我们必须提供一个沙箱环境来运行开发者的JavaScript 代码。这个沙箱环境不能有任何浏览器相关接口，只提供纯JavaScript 的解释执行环境，那么像HTML5中的ServiceWorker、WebWorker特性就符合这样的条件，这两者都是启用另一线程来执行 JavaScript。但是考虑到小程序是一个多 WebView 的架构，每一个小程序页面都是不同的WebView 渲染后显示的，在这个架构下我们不好去用某个WebView中的ServiceWorker去管理所有的小程序页面。 得益于客户端系统有JavaScript 的解释引擎（在iOS下是用内置的 JavaScriptCore框架，在安卓则是用腾讯x5内核提供的JsCore环境），我们可以创建一个单独的线程去执行 JavaScript，在这个环境下执行的都是有关小程序业务逻辑的代码，也就是我们前面一直提到的逻辑层。而界面渲染相关的任务全都在WebView线程里执行，通过逻辑层代码去控制渲染哪些界面，那么这一层当然就是所谓的渲染层。这就是小程序双线程模型的由来。 6.2 组件系统 小程序的视图是在WebView里渲染的，那搭建视图的方式自然就需要用到HTML语言。如果我们直接提供HTML的能力，那前面章节所介绍的为解决管控与安全而建立的双线程模型就成为摆设了。开发者可以利用A标签实现跳转到其它在线网页，也可以动态执行JavaScript等。除管控与安全外，还有一些的不足之处： l 标签众多，增加理解成本； l 接口底层，不利于快速开发； l 能力有限，会限制小程序的表现形式。 因此，我们设计一套组件框架——Exparser。基于这个框架，内置了一套组件，以涵盖小程序的基础功能，便于开发者快速搭建出任何界面。同时也提供了自定义组件的能力，开发者可以自行扩展更多的组件，以实现代码复用。 总结：为了管控和安全，建立一套自己的生态体系，以提供最大限度的控制，遇到问题，处理起来也会更及时； 这和经常问的另外一个问题类似：为什么我不选择开源框架，而选择自研？

最近的审核周期好像变长了，我之前的审核时间，最快的时候是几分钟，慢一点是2，3个小时，最近一次是1一天半

这个问题，可是把我坑够呛； 我在小程序端通过接口下载图片存储到本地，然后用canvas生成自定义的图片；按照10mb的存储空间，正常使用绝对是够的； 最近几天，遇到问题：有开发权限、体验权限的用户，提示存储空间不够了； 然后查看该用户手机的存储情况，一共只用了不到3mb空间；百思不得其解，来来回回看了好几遍和文件系统相关的文档，也没发现问题；一度都准备，把生成图片的功能移到服务端去做； 最后，在这发现了官方的回答，然后删除了开发版和体验版，线上版本的功能恢复正常； 建议官方文档中，把这个写进去；

在本地调试的时候，超过10mb，确实可以继续保存，而且还不触发fail回调，会在成功回调之后，在控制台打印出错误提示； 另外，文件系统分为3种，如下： 本地临时文件：临时产生，随时会被回收的文件。不限制存储大小。 本地缓存文件：小程序通过接口把本地临时文件缓存后产生的文件，不能自定义目录和文件名。除非用户主动删除小程序，否则不会被删除。跟本地用户文件共计，普通小程序最多可存储 10MB，游戏类目的小程序最多可存储 50MB。 本地用户文件：小程序通过接口把本地临时文件缓存后产生的文件，允许自定义目录和文件名。除非用户主动删除小程序，否则不会被删除。跟本地缓存文件共计，普通小程序最多可存储 10MB，游戏类目的小程序最多可存储 50MB 在我自己的小程序中，我一开始使用的是本地缓存文件，后来改造为“本地用户文件”，都遇到了存储空间不足的问题；据我收集上的日志来看，用户本地只使用了3mb左右的空间，也提示存储空间不足；不知道剩下的7mb空间是被什么占据了，通过小程序API获取的临时文件，也共享这10mb存储空间么？

为什么小程序“小打卡”可以付费加入分组，在分组里还还有契约金的玩儿法，玩儿法和楼主描述的模式基本一致？