全选与列表项状态须双向同步，全选按钮绑定计算属性allChecked，点击时统一设置item.isSelected；checkbox-group需包裹全部选项且value唯一；总价计算应转整数运算防浮点误差；长列表需稳定key并冻结非响应式数据。
全选状态和列表项状态必须双向同步，不能只靠 isAllChecked 控制渲染
很多人写全选逻辑时，直接把 checkbox 的 :checked 绑定到 item.checked，但“全选按钮”的状态却只读取一个独立变量 isAllChecked，再手动遍历列表去改 item.checked。这会导致数据流断裂：用户点某一项取消后，item.checked 变了，但 isAllChecked 没自动更新；再次点全选时，代码可能只设 isAllChecked = true，却忘了重置所有 item.checked = true —— 那几个被手动取消的项就“卡死”了。
实操建议：
- 列表项的 checked 状态必须是响应式字段（比如 item.isSelected），不能是计算属性或临时值
- 全选按钮的 :checked 应该绑定到一个计算属性，比如 allChecked，它实时判断 list.every(i => i.isSelected)
- “全选点击”事件里，不要只改 isAllChecked，而是统一执行 this.list.forEach(i => i.isSelected = !this.allChecked)
checkbox-group 必须套住所有可选项，且每个 checkbox 的 value 要唯一可识别
uni-app 的 checkbox 本身不触发 change，必须用 checkbox-group 包裹才能监听变化。常见错误是：顶部“全选”单独放一个 checkbox-group，下面列表又套一个——结果两个组完全隔离，状态无法联动。
实操建议：
- 把“全选”和所有商品项放在**同一个** checkbox-group 内
- “全选”项的 value 设为特殊字符串，比如 "__ALL__"，避免和商品 id 冲突
- 在 @change 回调中，先判断 e.detail.value 是否包含 "__ALL__"，再决定是全选还是单选操作
- 商品项的 value 必须是字符串类型（哪怕 id 是数字，也要 String(item.id)），否则在某些小程序平台会匹配失败
总价计算要用 computed，但注意 toFixed(2) 不是防精度问题的万能解
直接对浮点数做乘加再 toFixed(2)，看似解决了小数位数问题，但底层仍是 JS 浮点误差。比如 0.1 + 0.2 === 0.30000000000000004，如果单价是 99.99、数量是 3，累加过程就可能出偏差。
实操建议：
- 总价计算前，先把单价和数量转成整数运算（如单位改为“分”）：total += item.unitPrice * 100 * item.count
- 最后再除以 100 并 toFixed(2)：(total / 100).toFixed(2)
- 不要依赖 map 或 forEach 中的副作用修改变量，一律用 reduce 显式返回结果
- 如果用了 Vuex/Pinia，记得总价计算逻辑写在 getters 或 computed，别放在 methods 里重复执行
小程序端 checkbox 渲染慢？检查是否误用 v-for key 或未做列表缓存
长列表（比如 50+ 商品）下频繁切换选中状态时，页面卡顿、勾选延迟，不是框架性能差，大概率是 Vue 响应式追踪开销过大或 DOM 重建太猛。
实操建议：
- v-for 的 :key 必须是稳定唯一值，禁止用 :key="index"（排序/增删后会复用错元素）
- 商品数据量大时，考虑用 Object.freeze() 冻结原始数据结构，只让 isSelected 等交互字段可响应
- 不要在 checkbox 标签上绑定大量动态 class 或内联样式，提取成计算属性或 class 对象
- 微信小程序真机调试时，打开“调试器 → WXML 面板”，观察 checkbox 节点是否频繁新增/销毁 —— 如果是，说明 key 或数据结构不稳定
实际项目里最常被忽略的，是“全选状态”这个变量到底该不该存进 store。它看起来只是个 UI 状态，但一旦涉及多 tab 切换、页面缓存（keep-alive）、或者购物车跨页面共享，这个看似简单的布尔值就会变成状态同步的裂缝源头。
