1. 用数据驱动状态：在data里定义一个isActive: false，点击时this.setData({isActive: !this.data.isActive})。这比直接操作DOM更符合小程序“数据流单向”的哲学。你以后做任何开关、折叠、选中状态，都用这个模式，代码可维护性翻倍。

2. 注意setData的性能细节：不知道，setData传递的数据量越大，页面渲染越慢。如果只是切换一个布尔值，直接传{isActive: newValue}就好，千万别把整个对象或数组都传进去。我在一个电商项目中，看到有人把整个商品列表（几百条）每次点击都重新setData，结果页面卡成PPT。后来改成只更新变化的那条数据，瞬间流畅。

3. 对比wx:if和hidden：觉得它们差不多，但wx:if是“销毁/重建”，适合切换频率低的场景（比如登录/未登录两个完全不同的页面块）；hidden只是“显示/隐藏”，适合频繁切换（比如tab切换内容）。选错了，轻则浪费性能，重则导致组件状态丢失（比如输入框里的内容随着隐藏被清空）。

二、列表渲染：你以为只是循环？不，这是“数据与视图同步”的核心战场

《100例》里大量案例涉及列表，比如商品列表、新闻列表、聊天记录。写wx:for时只关注循环本身，但真正决定项目质量的，是下面这些细节：

1. wx:key必须给：这个属性不是可选项，而是必选项。如果不给，小程序会报警告，而且列表数据变化时，整个列表会重新渲染，导致性能灾难。我见过一个做社区论坛的开发者，没加wx:key，每次用户点赞（只改了一个字段），整个列表几百条数据全部重新渲染，手机发烫。加上wx:key="id"后，只有变化的那一行重绘。记住：任何列表，只要数据可能变化，必须绑定唯一标识。

2. 复杂列表的“局部更新”技巧：比如一个聊天列表，每条消息有“已读/未读”状态。如果用户读了某条消息，你不需要重新请求整个列表，只需在本地找到那条消息的索引，this.setData({['list[' + index + '].status']: 'read'})。这种路径式更新，比重新赋值整个list数组高效得多。很多教程不教这个，但实际开发中，这就是优化性能的杀手锏。

3. 列表的“空状态”处理：很多新手只写循环，忘了wx:if判断列表是否为空。《100例》里有个很好的习惯：在列表组件外面套一层<block wx:if="{{list.length === 0}}">显示“暂无数据”的占位图，再用wx:else显示真实列表。用户体验差距巨大——空白的页面会让用户以为app坏了，而一个友好的空状态提示，能留住用户。

三、页面传参：别再只用url传字符串了，试试这些更安全的方案

从列表页点击进入详情页，最基础的做法是wx.navigateTo({url: '/pages/detail?id=123'})。但《100例》会告诉你，这远远不够：

1. 参数编码问题：如果参数里包含中文或特殊符号（比如商品名称里有个“&”），直接拼在url里会导致解析错误。正确做法是encodeURIComponent编码，在目标页面用decodeURIComponent解码。我见过一个做旅游小程序的，用户搜索“三亚&海口”，因为没编码，页面直接白屏，用户流失了一大批。

2. 复杂对象的传递：有时候你需要传递一个对象（比如用户信息、商品配置）。别用JSON.stringify塞进url，因为url有长度限制（不同平台不一样，但一般不超过2KB）。更好的方案是用wx.setStorageSync临时存储，或者用getCurrentPages获取页面栈直接操作前一个页面的数据。比如详情页需要修改列表页的某个状态，可以在详情页onUnload时，通过const pages = getCurrentPages(); const prevPage = pages[pages.length - 2]; prevPage.setData({...})。这个方法虽然有点“绕”，但能解决很多复杂交互问题，而且不用写全局变量。

3. 页面栈的深度管理：做多级跳转（比如首页→分类→列表→详情→支付→结果），结果返回时发现页面栈爆了（小程序限制最多10层）。《100例》里有个案例专门讲“页面栈优化”：用wx.redirectTo代替navigateTo（比如从登录页跳首页，登录页不需要保留），或者用wx.reLaunch清空栈重新打开（适合支付结果页）。这个思维能避免很多“返回异常”的bug。

四、网络请求：别只写wx.request，要建立“请求层”的工程思维

《100例》里每个涉及网络请求的案例，都会强调一件事：不要在每个页面里直接写wx.request，要封装一个统一的请求模块。具体怎么做：

1. 封装request函数：在utils文件夹里创建api.js，统一处理baseURL、请求头（比如token）、超时时间、错误码。比如服务端返回401时，自动跳转登录页；返回500时，弹出“服务器繁忙”的toast。这样所有页面都不用重复写错误处理逻辑。

2. 请求和响应的拦截：类似axios的拦截器。在请求发出前，检查是否过期（比如token是否有效），如果过期则先刷新token再继续请求。在响应回来后，统一解析数据格式（比如服务端返回{code: 0, data: {...}}，你只需要在拦截器里判断code !== 0时抛出错误，页面层只处理成功数据）。

3. 防重复提交：很多新手做“提交表单”时，用户手快点了两次，就会发出两个请求，导致重复下单。《100例》里有个技巧：在请求函数里维护一个pending对象，每次请求前检查是否已有相同url+参数的请求正在等待，如果有则直接返回上次的promise，或者干脆阻止第二次请求。这个细节在支付类、注册类场景中至关重要。

五、生命周期：onLoad、onShow、onReady的区别，用错了就是灾难

很多教程只是简单列了生命周期函数的名字，但《100例》会通过具体场景告诉你：选错了生命周期，轻则数据不更新，重则内存泄漏。

1. onLoad vs onShow：onLoad只在页面第一次加载时执行一次，适合放页面初始化数据请求（比如商品详情）。但如果你在onLoad里请求了列表数据，然后用户通过tab切换到了其他页面，再切回来时，列表数据不会刷新（因为页面没有被销毁重建）。这时候就需要把请求放到onShow里，因为每次页面显示都会触发。比如一个“我的订单”页面，用户从支付页返回后，应该看到最新的订单状态，所以用onShow请求。

2. onUnload的清理作用：在页面里设置了定时器（比如倒计时）、订阅了全局事件（比如wx.onSocketMessage），但忘记在onUnload里清除。结果页面跳走了，定时器还在跑，事件还在触发，导致内存泄漏甚至crash。我见过一个做直播的小程序，因为没清理定时器，用户切换了几个页面后，手机直接卡死。《100例》里每个涉及定时器的案例，都会在onUnload里写clearInterval或clearTimeout，这是好习惯。

3. onReachBottom和onPullDownRefresh的配合：做列表页时，只写下拉刷新或只写上拉加载。但用户习惯是“下拉刷新最新数据，上拉加载更多历史数据”。《100例》里有个案例完美结合两者：下拉时重置页码为1，重新请求并替换列表数据；上拉时页码+1，把新数据追加到列表后面。注意：onReachBottom触发后，要设置一个loading状态防止重复触发（比如if(this.data.loading) return），否则用户快速滑动时会发出N个重复请求。

六、组件化：别等到项目大了才重构，一开始就要用“组件思维”

《100例》里有很多自定义组件的案例，比如“星级评分组件”、“搜索框组件”、“商品卡片组件”。觉得组件化麻烦，但如果你做过一个超过20个页面的项目，就知道不组件化有多痛苦：同样的搜索框，在10个页面里复制粘贴了10遍，后来需求改了（比如增加语音搜索），你得改10个地方，漏掉一个就出bug。

1. 组件的通信：父组件传数据给子组件用properties，子组件传事件给父组件用triggerEvent。比如一个“数量选择器”组件，用户点击加号，子组件通过this.triggerEvent('change', {value: newCount})把新数量传给父组件。父组件在标签上写bind:change="handleCountChange"接收。这个模式比用全局变量或页面栈更清晰。

2. 组件样式隔离：发现组件里的样式不生效，或者影响了父页面。因为小程序默认开启了样式隔离（styleIsolation: 'isolated'）。如果你需要组件样式可以被外部覆盖（比如主题颜色），可以用styleIsolation: 'apply-shared'。或者更推荐的做法：在组件里用class命名规范（比如my-component__title），避免冲突。

3. 组件复用性设计