应采用对象数组结构，每项含id、name、price（数字）、quantity（正整数校验）、checked等字段，结算时仅累加checked为true的项，并基于内存状态cartState计算总价，避免依赖DOM或字符串价格。
购物车数据结构怎么设计才方便结算？
结算逻辑依赖购物车数据的清晰性和可扩展性。别用扁平数组硬存商品，容易在数量变更、优惠叠加时出错。用对象数组，每个项带唯一 id、name、price、quantity、checked（是否参与结算），必要时加 skuId 或 discount 字段。
-
price始终存数字（如29.9），别存字符串"29.90元"，否则reduce求和会变成字符串拼接 -
quantity必须校验为正整数，前端用Math.max(1, parseInt(val) || 1)防止输入非法值 -
checked控制勾选状态，结算时只累加checked === true的项，避免用户取消某商品后仍计入总价
HTML 表单结构怎么写才能让 JS 容易取值？
别用一堆独立的 input 和 span 拼凑，用语义化结构绑定数据。每条商品行用 <li class="cart-item"> 包裹，关键字段通过 data- 属性挂载原始数据：
<li class="cart-item" data-id="1002" data-price="89.00"> <label><input type="checkbox" class="item-check" checked></label> <span class="item-name">无线耳机</span> <input type="number" class="item-qty" value="1" min="1"> <span class="item-total">¥89.00</span> </li>
- 所有操作都基于
cart-item元素向上/向下查找，避免全局querySelectorAll('.item-qty')导致顺序错位 -
data-price存原始单价，显示价格用 JS 格式化（new Intl.NumberFormat().format()），不靠 HTML 写死 -
input[type="number"]必须设min="1"，但注意 Safari 对min支持不稳定，仍需 JS 双重校验
结算按钮点击后，JS 怎么安全算出应付金额？
直接遍历 DOM 算价风险高：DOM 可能被手动篡改、价格字段可能被隐藏或格式混乱。正确做法是维护一份内存中的购物车状态（cartState），所有 UI 操作同步更新它，结算时只读这个状态。
- 每次修改数量或勾选状态，触发函数更新
cartState对应项的quantity和checked - 结算时用
cartState.filter(item => item.checked).reduce((sum, item) => sum + item.price * item.quantity, 0) - 最终金额必须用
Number(sum.toFixed(2))保留两位小数，避免浮点误差（如0.1 + 0.2 === 0.30000000000000004） - 不要信任用户输入的
item-total文本内容，它只是展示，不是计算依据
为什么用 localStorage 存购物车反而容易出问题？
存的是原始数据还是渲染后的 DOM？很多人直接 JSON.stringify(cartItems) 存，但漏掉几个关键点：
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
立即学习“前端免费学习笔记（深入）”；
- 没过滤掉临时字段（如
domRef、animationState），导致还原时报错 - 没处理
Date或undefined，JSON.stringify会丢弃它们 - 页面重载后没重新绑定事件，DOM 存在但交互失效
稳妥做法是：只存核心字段（id、quantity、checked），初始化时用这些字段重建 cartState，再调用渲染函数生成 DOM；所有事件监听器在渲染后统一绑定，不依赖存储的数据结构。
真实场景里，勾选状态、库存变化、跨端同步都会让本地存储变得脆弱。优先保证内存状态准确，localStorage 只作降级缓存，不是主数据源。
