详细参考代码和官方文档
- pages 主包
- packageA 分包（应项目大小而定）
- 整个小程序所有分包大小不超过 8M
- 单个分包/主包大小不能超过 2M
开发者工具创建 自动生成
- xxx.wxss 样式
- xxx.wxml 结构
- xxx.js
- xxx.json 页面私有配置
- 开发者工具创建 自动生成
<template is="temp1" data="{{tempName,staffA}}" />
- 一定要 data。
- 存在作用域 只能访问 data 中的数据。
- 按照 750 标准设计稿执行
class="cla1,{{rule?'cla2':'cla3'}}"
style="color:{{color}}"
- 每一个 .wxs 文件和 标签都是一个单独的模块。
- 每个模块都有自己独立的作用域。即在一个模块里面定义的变量与函数，默认为私有的，对其他模块不可见。
- 一个模块要想对外暴露其内部的私有变量与函数，只能通过 module.exports 实现。
- 在.wxs模块中引用其他 wxs 文件模块，可以使用 require 函数。 绝对路径 单例 不引用不解析
- 按照官方文档 数据操作参照 es5
- .json文件不可注释。
- 可用block块结合wx:if/wx:for来实现一块代码的操作，block不翻译，起包裹作用。
- .wxml 中的 {{}} 逻辑（三目） 算术 运算 不能使用一些js对象操作，如Math.,JSON.。
- showToast showLoading hideLoading
- text 元素之间的换行会占空间
##小程序
微信小程序的框架包含两部分 View 视图层、App Service逻辑层。View 层用来渲染页面结构，AppService 层用来逻辑处理、数据请求、接口调用。
它们在两个线程里运行。
视图层使用 WebView 渲染，iOS 中使用自带 WKWebView，在 Android 使用腾讯的 x5 内核（基于 Blink）运行。 逻辑层使用在 iOS 中使用自带的 JSCore 运行，在 Android 中使用腾讯的 x5 内核（基于 Blink）运行。 开发工具使用 nw.js 同时提供了视图层和逻辑层的运行环境。
- 服务端接口返回的头无法执行，比如：Set-Cookie
- 依赖浏览器环境的 JS 库不能使用
- 获取二维码/小程序接口的限制
- 小程序不能发朋友圈（可以通过保存图片到本地，发图片到朋友前。二维码可以使用B接口）
- B 接口 scene 最大32个可见字符
- AC 接口总共生成的码数量限制为 100,000，请谨慎调用
- 小程序推送只能使用“服务通知” 而且需要用户主动触发提交 formId，formId 只有7天有效期。（现在的做法是在每个页面都放入form并且隐藏以此获取更多的 formId。后端使用原则为：优先使用有效期最短的）
- 小程序大小限制 2M，分包总计不超过 8M
- 转发（分享）小程序不能拿到成功结果，原来可以。小游戏造的孽
-
每次 setData 的调用都是一次进程间通信过程，通信开销与 setData 的数据量正相关。
-
setData 会引发视图层页面内容的更新，这一耗时操作一定时间中会阻塞用户交互。
-
setData 是小程序开发使用最频繁，也是最容易引发性能问题的。
-
避免不当使用 setData
- 使用 data 在方法间共享数据，可能增加 setData 传输的数据量。data 应仅包括与页面渲染相关的数据。（可考虑全局对象代替Data共享数据）
- 使用 setData 传输大量数据，**通讯耗时与数据正相关，页面更新延迟可能造成页面更新开销增加。**仅传输页面中发生变化的数据，使用 setData 的特殊 key 实现局部更新。
- 短时间内频繁调用 setData，**操作卡顿，交互延迟，阻塞通信，页面渲染延迟。**避免不必要的 setData，对连续的setData调用进行合并。
- 在后台页面进行 setData，**抢占前台页面的渲染资源。**页面切入后台后的 setData 调用，延迟到页面重新展示时执行。
-
避免不当使用onPageScroll
- 只在有必要的时候监听 pageScroll 事件。不监听，则不会派发。
- 避免在 onPageScroll 中执行复杂逻辑
- 避免在 onPageScroll 中频繁调用 setData
- 避免滑动时频繁查询节点信息（SelectQuery）用以判断是否显示，部分场景建议使用节点布局橡胶状态监听（inersectionObserver）替代
-
在需要频繁更新的场景下，自定义组件的更新只在组件内部进行，不受页面其他部分内容复杂性影响