# 最佳实践
# 1. 避免JS异常
出现 JavaScript 异常可能导致程序的交互无法进行下去，我们应当追求零异常，保证程序的高鲁棒性和高可用性。
得分条件：不出现任何JS异常
# 2. 避免网络请求异常
请求失败可能导致程序的交互无法进行下去，应当保证所有请求都能成功。
得分条件：所有已授权网络请求都正常返回，未授权网络请求需要给出 401 或 403 这两种状态码
# 3. 不使用废弃接口
使用即将废弃或已废弃接口，可能导致小程序运行不正常。一般而言，接口不会立即去掉，但保险起见，建议不要使用，避免后续小程序突然运行异常。
得分条件：不使用任何文档中提示废弃的接口
# 4. 使用HTTPS
使用HTTPS，可以让你的小程序更加安全，而HTTP是明文传输的，存在可能被篡改内容的风险
得分条件：所有网络请求都使用HTTPS
# 5. 避免setData数据冗余
setData操作会引起框架处理一些渲染界面相关的工作，一个未绑定的变量意味着与界面渲染无关，传入setData会造成不必要的性能消耗。
得分条件：setData传入的所有数据都在模板渲染中有相关依赖
# 6. 最低基础库版本
当使用的组件/API 的支持版本大于配置的线上最低基础库版本时，可能导致相应功能不可用。开发者可通过调整最低基础库版本或在代码上兼容的方式解决该问题。
由于用户可以通过代码兼容的方式解决该问题，因此该指标仅作为评分的提醒项，不计入总分中。
判断标准：不存在使用的组件/API 的支持版本大于配置的线上最低基础库版本
# 7. 移除不可访问到的页面
小程序的包大小会影响加载时间，应该尽量控制包体积大小，避免将不会被使用的文件打包进去。
由于该项指标依赖开发者的操作路径，因此仅作为评分的提醒项，不计入总分中。
判断标准：不存在访问不到的页面被打包到小程序中
# 8. WXSS使用率
我们应该按需引入 wxss 资源，如果小程序中存在大量未使用的样式，会增加小程序包体积大小，从而在一定程度上影响加载速度。
由于该项指标依赖开发者的操作路径，因此仅作为评分的提醒项，不计入总分中。
判断标准：每个 wxss 资源的未使用部分不超过 2KB
# 9. 及时回收定时器
定时器是全局的，并不是跟页面绑定的，当小程序从一个页面路由到另一个页面之后，前一个页面定时器应注意手动回收。
由于该项指标依赖开发者的操作路径，因此仅作为评分的提醒项，不计入总分中。
判断标准：所有定时器的回调执行时所在的页面都与设置定时器的页面一致