1. iOS9和iOS10 所使用的运行环境并没有完全的兼容到 ECMAScript 6 标准，小程序IDE提供语法转码工具帮助开发者，将 ECMAScript 6代码转为 ECMAScript 5代码，从而在所有的环境都能得到很好的执行。
开发者需要在项目设置中，勾选 ES6 转 ES5 开启此功能。
2. 当需要使用全局变量的时，通过使用全局函数 getApp() 获取全局的实例，并设置相关属性值，来达到设置全局变量的目的，
// a.js
// 获取全局变量
var global = getApp()
global.globalValue = 'globalValue'
3. 由于小程序的渲染层和逻辑层分别在两个线程中运行，所以setData传递数据实际是一个异步的过程，所以setData的第二个参数是一个callback回调，在这次setData对界面渲染完毕后触发。
此外需要注意以下3点：
a. 直接修改 Page实例的this.data 而不调用 this.setData 是无法改变页面的状态的，还会造成数据不一致。
b. 由于setData是需要两个线程的一些通信消耗，为了提高性能，每次设置的数据不应超过1024kB。
c. 不要把data中的任意一项的value设为undefined，否则可能会有引起一些不可预料的bug。
4. wx.navigateTo后的页面栈，小程序宿主环境限制了这个页面栈的最大层级为10层 ，也就是当页面栈到达10层之后就没有办法再推入新的页面了
5. 小程序提供了原生的Tabbar支持，我们可以在app.json声明tabBar字段来定义Tabbar页（注：更多详细参数见Tabbar官方文档 ）。
6. 小程序宿主环境要求request发起的网络请求必须是https协议请求，因此开发者服务器必须提供HTTPS服务的接口，同时为了保证小程序不乱用任意域名的服务，wx.request请求的域名需要在小程序管理平台进行配置[2]，如果小程序正式版使用wx.request请求未配置的域名，在控制台会有相应的报错。
小程序的开发版和小程序的体验版在某些情况下[3]允许wx.request请求任意域名。
[2] 登录mp.weixin.qq.com，在设置, 开发设置里配置request的服务器域名，同时TLS版本需要支持1.2及以上。
[3] 开发者工具需要勾选不校验可信域名；小程序开发版和体验版需要打开调试模式。
7. HTTP GET请求需要留意的是url是有长度限制的，其最大长度是1024字节，同时url上的参数需要拼接到字符串里，参数的值还需要做一次urlEncode。向服务端发送的数据超过1024字节时，就要采用HTTPPOST的形式
8. 在使用wx.request接口我们会经常遇到无法发起请求或者服务器无法收到请求的情况，我们罗列排查这个问题的一般方法：
a. 检查手机网络状态以及wifi连接点是否工作正常。
b. 检查小程序是否为开发版或者体验版，因为开发版和体验版的小程序不会校验域名。
c. 检查对应请求的HTTPS证书是否有效，同时TLS的版本必须支持1.2及以上版本，可以在开发者工具的console面板输入showRequestInfo()查看相关信息。
d. 域名不要使用IP地址或者localhost，并且不能带端口号，同时域名需要经过ICP备案。
e. 检查app.json配置的超时时间配置是否太短，超时时间太短会导致还没收到回报就触发fail回调。
f. 检查发出去的请求是否302到其他域名的接口，这种302的情况会被视为请求别的域名接口导致无法发起请求。
9. 刚刚说到开发者需要真机调试开发版本时，可以点击开发者工具的预览按钮，此时开发者工具会打包当前项目，并上传到微信服务器生成一个二维码，开发者使用当前开发身份的微信扫描二维码就可以在手机上体验对应的开发版本。
10. 天生的延时
既然小程序是基于双线程模型，那就意味着任何数据传递都是线程间的通信，也就是都会有一定的延时。这不像传统Web那样，当界面需要更新时，通过调用更新接口UI就会同步地渲染出来。在小程序架构里，这一切都会变成异步。
除了逻辑层与渲染层之间的通信有延时，各层与客户端原生交互同样是有延时的。以逻辑层为例，开发者的代码是跑在逻辑层这个线程之上，而客户端原生是跑在微信主线程（安卓上是线程）之上，所以注册给逻辑层有关客户端能力的接口，实际上也是跟微信主线程之间的通信，同样意味着有延时。这也是我们看到大部分提供的接口都是异步的原因。
11. 原生组件
原生组件脱离在WebView渲染流程外，这带来了一些限制。最主要的限制是一些CSS样式无法应用于原生组件，例如，不能在父级节点使用overflow:hidden来裁剪原生组件的显示区域；不能使用transformrotate让原生组件产生旋转等。
开发者最为常见的问题是，原生组件会浮于页面其他组件之上（相当于拥有正无穷大的z-index值）使其它组件不能覆盖在原生组件上展示。想要解决这个问题，可以考虑使用cover-view和cover-image组件。这两个组件也是原生组件，同样是脱离WebView的渲染流程外，而原生组件之间的层级就可以按照一定的规则控制。
12. 分包加载流程
一般情况下，小程序的代码将打包在一起，在小程序启动时一次性下载完成。采用分包时，小程序的代码包可以被划分为几个：一个是“主包”，包含小程序启动时会马上打开的页面代码和相关资源；其余是“分包”，包含其余的代码和资源。这样，小程序启动时，只需要先将主包下载完成，就可以立刻启动小程序。这样就可以显著降低小程序代码包的下载时间。
13. WebView层有两种方法可以捕捉JS异常：
a. try, catch方案。你可以针对某个代码块使用try,catch包装，这个代码块运行时出错时能在catch块里边捕捉到。
b. window.onerror方案。也可以通过window.addEventListener("error", function(evt){})，这个方法能捕捉到语法错误跟运行时错误，同时还能知道出错的信息，以及出错的文件，行号，列号。
14. 逻辑层不存在window对象，因此逻辑层AppService侧无法通过window.onerror来捕捉异常。
所以小程序基础库在WebView侧使用window.onerror方案进行捕捉异常，在逻辑层AppService侧通过把App实例和Page实例的各个生命周期等方法包裹在try-catch里进行捕捉异常。同时在App构造器里提供了onError的回调，当业务代码运行产生异常时，这个回调被触发，同时能够拿到异常的具体信息，开发者自己根据业务情况处理对应的容错逻辑