很多读到Web开发第六章的同学，都会卡在同一个地方：前面的标签会用、样式会写、基础语法也眼熟，但一碰到综合案例就不知道怎么下手。我带了这几年课程，几乎每一批都会有人拿着同一个问题来找我——老师，单个知识点我都懂，串到一起就乱。这篇web第六章案例（含源代码）的文章，就是想把这个坎迈过去。案例本身不复杂，是一个购物车结算页面，但它把DOM操作、事件绑定、数组方法、数据驱动重绘这些第六章的核心知识点全部串在了一条线上。适合刚学完JavaScript基础、正在做第一个综合练习的初学者，也适合带学生的老师拿去当课堂范例。

下面我会把这个案例从需求拆解、源代码主干，到难点深挖、调试排错，一条完整链路讲透。代码不是贴出来就完事，每一段我都会告诉你为什么这么写，以及实际运行中会出现哪些坑。

1. 第六章的卡点：单点知识都懂，综合案例就懵

1.1 前五章都学了什么

按照常规的Web开发课程进度，第六章之前，你已经接触过这些东西：

• HTML的常用标签、表单元素、语义化结构
• CSS的选择器、盒模型、flex布局、基础样式美化
• JavaScript的数据类型、变量、函数、循环、条件判断
• 数组和对象的定义、遍历、常用方法

听起来每个都会，对吧？但实际上，前五章的知识是"点状"的，每一章内部自成体系，章节和章节之间没有强关联。于是就会出现一种很典型的割裂状态：写HTML的时候只用HTML，写CSS的时候只用CSS，写JavaScript的时候基本上就是console.log打几个输出。

到了第六章，情况变了。这一章通常要求学生把前面学的所有东西融合起来，做一个小型完整应用。这时候才发现，HTML、CSS、JavaScript三者之间不是"三张独立的纸"，而是一张网。任何一个环节出问题，整个页面都不转。

我遇到过一个A同学，作业是做一个用户注册表单的交互验证。他单写验证函数时，控制台什么都是对的，一放到页面上，按钮怎么点都没反应。排查了很久才找到原因——函数定义了，但HTML里按钮的id写错了，事件监听绑到了一个不存在的元素上。这就是典型的"章节知识没打通"。

1.2 为什么购物车案例适合做收口

第六章选案例，要有几个标准：功能不能太复杂，但交互能够覆盖核心知识点；数据要有变化，能体现JavaScript的优势；界面要有反馈，能把三端串起来。

购物车结算页面几乎是完美答案。它天然包含一个数据集合（商品列表），需要把数据渲染到页面上；它有不止一个交互动作（增加、减少、删除、选中、结算），需要多个事件处理；它有实时计算（总价、数量、优惠），需要把计算结果更新回视图。

而且，购物车这个场景大家太熟悉了。熟悉意味着你不需要花时间解释业务逻辑，可以把全部注意力放在"代码怎么组织"上。这个优势在教学中非常明显。

所以这个案例的价值不只是做一个页面，而是帮你建立一种思维方式：在动手敲代码之前，先把数据和交互理清楚。前端不是写标签，是在操作数据。

2. 案例需求拆解：一个购物车结算页面要处理哪些交互

2.1 页面结构与交互清单

先把这个购物车到底要做成什么样说清楚。不追求花哨，但交互要完整。

我设计的页面结构是三段式：

1. 商品列表区域：展示每个商品的图片（可以用背景色块代替）、名称、单价、数量、小计，以及每行的选择和删除操作
2. 结算汇总区域：显示已选商品总数、总价、结算按钮
3. 顶部的全选开关：一键切换所有商品的选中状态

交互需求列出来，一共是六项：

• 点击单个商品行的小计区域旁边的加号，数量加一
• 点击减号，数量减一；如果数量本身是1，再减就删除该商品或者置灰（我这里用的是数量减到1不可再减）
• 点击单选框，切换该商品的选中状态，并更新汇总金额
• 点击全选框，所有商品的选中状态跟着变
• 点击删除按钮，移除该商品
• 金额区域实时刷新

这六项交互看起来简单，但每一项目背后都对应一个或多个JavaScript知识点。加号减号是事件监听和数据修改；选中状态是数据属性驱动样式变化；金额实时刷新是数据变化后重新计算并更新DOM。

2.2 数据对象的设计：先定数据结构再写页面

这是这个案例里我认为最重要的一个环节，也是很多初学者最容易跳过的环节——直接上手写HTML，然后在JavaScript里到处查找元素、乱改内容。最后代码是能跑，但加了几个功能后就失控了。

正确做法是先设计数据。这个案例的数据结构，我用了最直观的方案：一个数组，数组里的每一个元素就是一个商品对象。

const goodsList = [ { id: 1, name: '无线鼠标', price: 89, count: 1, selected: true }, { id: 2, name: '机械键盘', price: 299, count: 1, selected: false }, { id: 3, name: 'USB-C扩展坞', price: 159, count: 2, selected: true }, { id: 4, name: '显示器支架', price: 129, count: 1, selected: false } ];

每个商品对象包含五个字段：id是唯一标识，name是商品名，price是单价，count是当前数量，selected是选中状态。

我习惯把所有数据集中放在一个数组里，而不是分散在页面的各个角落。原因很简单：页面是数据的一种"投影"，数据变了页面跟着变；如果反过来，页面是唯一数据源，那你每次要获取某个值都得去操作DOM，又慢又容易出错。

这就是数据驱动的基本思想，第六章阶段不需要你理解得很深，但要开始养成"改数据，不直接改页面"的习惯。

2.3 渲染策略：用模板字符串还是DOM拼接

数据设计好了，下一个问题是：怎么把数组变成页面上的商品行？

初学者最常见的是document.createElement逐个创建节点，或者用innerHTML拼接字符串。两种都能用，我推荐后者，因为代码更紧凑，可读性更高，而且模板字符串是ES6的核心特性，第六章学的就是它。

function renderList() { const listContainer = document.querySelector('.goods-list'); let html = ''; goodsList.forEach(item => { html += ` <div class="goods-item ${item.selected ? 'active' : ''}"><main class="cart-wrapper"> <div class="cart-header"> <label class="check-all-wrap"> <input type="checkbox" id="checkAll"> 全选 </label> <span>已选商品：<strong id="selectedCount">0</strong> 件</span> </div> <div class="goods-list"> <!-- 由 JavaScript 渲染 --> </div> <div class="cart-footer"> <span>合计：<strong id="totalPrice">¥0</strong></span> <button class="settle-btn" id="settleBtn">去结算</button> </div> </main>

我特意把goods-list容器留空，目的就是让JS全权负责内容渲染。页面初始状态下，这个容器里没有任何商品行。

容器划分的原则很简单：哪些区域的内容会变化，就给它一个独立的容器；哪些区域只显示不变的信息，直接写死就行。这里商品行会变，所以要放在list容器里；底部的合计金额会变，所以给totalPrice这个id去标识那个元素，但不用单独容器。

3.2 CSS状态：选中、禁用、金额强调

CSS部分我只说关键状态，不贴太多代码，因为这一章重点不是样式。

• 商品行在选中状态下，背景色变化，比如浅蓝底的active类
• 数量按钮在禁用状态下，灰色、不可点，视觉上要有区分
• 合计金额要醒目，字号大一些，颜色强调一下

.goods-item { display: flex; align-items: center; padding: 14px 16px; border-bottom: 1px solid #eee; } .goods-item.active { background: #f0f7ff; } .count-btn:disabled { opacity: 0.4; cursor: not-allowed; } .cart-footer strong { font-size: 20px; color: #e8392e; }

CSS自身不是难事，但初学者容易忽略一个点：样式要配合状态类名来写。active类加到商品行上，视觉立刻变化；disabled加到按钮上，鼠标悬停的效果也要跟着变。这些状态不是凭空来的，都是JavaScript在数据变化后加到DOM上的。

3.3 JavaScript主逻辑：初始化、渲染、事件绑定

这是整个案例的心脏。我把JS的主流程拆成三个部分：初始化、渲染函数、事件绑定。

初始化要做的事情有两个：渲染列表、更新汇总。

function init() { renderList(); updateSummary(); bindEvents(); } init();

渲染函数就是上面写的renderList。更新汇总的逻辑是：筛选出所有selected为true的商品，计算总件数和总价。

function updateSummary() { const selectedItems = goodsList.filter(item => item.selected); const totalCount = selectedItems.reduce((sum, item) => sum + item.count, 0); const totalPrice = selectedItems.reduce((sum, item) => sum + item.price * item.count, 0); document.getElementById('selectedCount').textContent = totalCount; document.getElementById('totalPrice').textContent = `¥${totalPrice.toFixed(2)}`; }

这里用了两个高阶函数filter和reduce，这正好是第六章数组方法的核心考点。filter负责筛选，reduce负责把数组累计成一个单一的数值。

事件绑定是最容易写乱的部分。每个商品行里都有按钮，如果给每个按钮都单独绑一个事件处理器，代码会非常冗余，而且动态渲染出来的元素，在渲染之前根本不存在，你怎么绑？

正确的解法是事件委托——把事件监听绑定到父容器上，通过事件对象的target属性判断点击的是哪个具体子元素。这一步是整个案例的第二个关键点，我在下一节详细展开。

4. 难点深挖：事件代理、闭包陷阱与数据视图分离

4.1 事件代理为什么在这个案例里是关键

事件代理（事件委托）的原理很简单：事件不是直接绑定在目标元素上，而是绑定在它的父元素上。当子元素触发事件时，事件会冒泡到父元素，父元素的事件处理器通过event.target来判断点击的对象是谁，然后执行对应的逻辑。

这个案例的情况是：列表是动态渲染的。假如你直接给每一个加号按钮绑定事件，那么渲染一次就要重新绑定一次，而且还要等元素存在才能绑。事件代理完美解决了这个问题：你只需要在goods-list容器上绑定一次click事件，所有后渲染出来的按钮点击，都会冒泡到这个容器上被捕获。

document.querySelector('.goods-list').addEventListener('click', function (e) { const target = e.target; const itemElement = target.closest('.goods-item'); if (!itemElement) return; const id = Number(itemElement.dataset.id); const goods = goodsList.find(item => item.id === id); if (target.classList.contains('plus-btn')) { goods.count += 1; } else if (target.classList.contains('minus-btn')) { if (goods.count > 1) { goods.count -= 1; } } else if (target.classList.contains('del-btn')) { const index = goodsList.findIndex(item => item.id === id); goodsList.splice(index, 1); } else if (target.classList.contains('item-check')) { goods.selected = target.checked; } renderList(); updateSummary(); });

这段代码里有几个我在教学时会专门强调的细节：

第一，closest方法的作用。它从当前元素向上找，一直找到匹配选择器的祖先元素。这样即使你点的是按钮里的span文字，也能正确向上找到整个商品行，拿到data-id属性。

第二，dataset.id拿到的字符串，所以要Number转成数字，再和数组里的id做严格比较。不做转换的话，可能会因为类型不一致而find不到数据。

第三，所有操作完成之后，统一调用renderList和updateSummary。这样保证视图始终和数据保持一致，这就是数据驱动修改的核心套路：改数据，重新渲染，不要零零碎碎地手动改DOM。

4.2 闭包陷阱：循环绑定事件的经典翻车现场

事件代理能避开的坑，你又会在另一种写法里踩回去。我在课堂上见过太多次这样的错误了：看到事件代理觉得"那我不放在列表容器上了，我直接给每个按钮绑"，于是写了个循环。

// 初学者常见错误示范 for (let i = 0; i < goodsList.length; i++) { document.querySelectorAll('.plus-btn')[i].addEventListener('click', function () { goodsList[i].count += 1; // 这里 i 的值是多少？ }); }

这段代码有三个问题。

第一个，渲染时机。如果商品行还没渲染出来，querySelectorAll拿到的是空集合，根本绑不上事件。

第二个，也是更经典的问题——闭包陷阱。如果循环用的是var，那么循环结束之后，所有回调函数引用的i都指向同一个循环变量，最后点击任何按钮，i都是goodsList.length，越界。

用let可以解决这个单独的问题，因为let每次循环都会创建一个新的绑定。但即便用let，这种写法的代码量也远大于事件代理，而且每次渲染都需要重新绑定事件，很容易出bug。

所以我在这个案例里始终坚持：动态列表的事件一律用事件代理。这从根本上限定了事件绑定的代码只写一次，永远不会因为渲染次数增多而重复绑。

想深入理解闭包的同学，可以把上面的错误示范粘贴到浏览器控制台跑一下，看看点击之后到底发生什么，会比听我讲印象深得多。

4.3 数据与视图分离：状态变更后怎么重绘

这个案例里最核心的编程思维，是你要建立"数据和视图分离"的直觉：数据是唯一的事实来源，视图只是数据的展示层。

还是用购物车举例。初始状态下，某个商品selected是true，页面显示它的复选框勾上、行背景高亮。用户取消勾选后，数据变成false，页面怎么变？我的做法是修改data，然后调用renderList重新渲染整个列表。

简单粗暴，但有效。注意renderList里面已经用item.selected推倒了当前行的渲染结果，所以不需要额外写"如果selected是false就去掉active类"——每次渲染都是根据最新数据从零生成，不存在"状态残留"。

对比一下错误示范：有人会这样做：

// 错误做法：直接去改DOM checkbox.addEventListener('change', function () { this.parentElement.parentElement.classList.add('active'); });

这种写法的问题是，你只在DOM层面改了状态，数据goodsList里的selected字段并没有同步更新。一旦后面执行updateSummary，它会读取goodsList里的selected，计算结果就错了。等某次意外刷新渲染后，DOM的状态还会被重置回去，页面表现和数据彻底分家。

所以我的原则是：所有的DOM修改，一律通过"修改数据之后重新渲染"来完成。不要在渲染函数之外的地方手动给元素加类、改内容。这不是教条，是让代码保持可预测性的最简方案。

5. 调试与排错：案例运行不正常的常见原因和定位思路

5.1 点击没反应，第一步不是看JS而是看选择器

我在带学生的过程中，遇到最多的"点击没反应"，最后定位出来都很简单：

• id写错了，JS里用getElementById('totalPrice')，HTML里写的却是id="totalprice"，字母大小写不一致
• 类名写错了，CSS里定义的是.minus-btn，JS事件判断时写的却是.minusclass，没有一个字符对得上
• 元素嵌套错了，点击的是外层div，事件代理判断target.classList时永远不匹配

遇到点击没反应，先别急着怀疑逻辑，打开浏览器的开发者工具，切到Elements面板，对比一下你HTML里实际渲染出的结构，和你JS里querySelector用的选择器是否一一对应。

我的一句话排查心法：选择器对不上，一切皆为空。你能查到元素，才能谈得上绑定事件；查都查不到，后面全是白费。

5.2 金额计算错误：先查类型，再查筛选条件

金额不对，通常两类原因。

第一类是类型问题。从DOM读出来的值全是字符串，如果做加法：

// 错误示范 let total = '89' + '11'; // '8911'，字符串拼接

我的代码里规避了这个问题：价格和数量都来自JS对象，number类型，运算天然正确。但有些人会把单价从界面上重新读出来，再拼接字符串，算出来的结果就是一个长串数字。

第二类是筛选条件不对。updateSummary里用的是filter(item => item.selected)，如果选了状态的字段名不统一，比如某个商品对象里写的是isSelected，筛选就会漏掉它。

调试技巧：在updateSummary里打个断点，或者直接console.log(selectedItems)，看它到底筛出了哪些商品。数据一打印，问题一目了然。

function updateSummary() { const selectedItems = goodsList.filter(item => item.selected); console.log('筛选结果', selectedItems); // 临时调试代码 // ... }

5.3 渲染重复与数据不同步：小心"绑定一次"之外的多处调用

项目越写越复杂的时候，会出现一种怪现象：点一次加号，页面上的商品多出一行，而且商品行总数翻倍了。

原因多半是renderList被调用了多次，并且每次调用都用innerHTML追加而非覆盖。比如有人会把renderList误写成：

listContainer.innerHTML += html;

加号赋值在每次渲染时都会把旧内容保留，再拼上新生成的行，于是列表越滚越长。

正确写法是直接用等号赋值：listContainer.innerHTML = html;，每次渲染都是全量覆盖，旧内容全部替换为新内容。

还有一种情况是事件绑定重复。如果你在某个函数里绑定了事件，又在另一个地方再次绑定，同一个按钮点击一次，事件处理函数执行两次。数据被加了两次。这个案例用了事件代理，绑定只发生一次，天然避免了这个问题。如果你用的是普通绑定方式，记得在绑定前先移除旧的事件监听器。

5.4 调试工具的使用习惯：在操作数据的关键位置打点

最后给一个小建议，调试的时候不要只在出问题的地方看。

我的习惯是在数据被修改的地方、计算前的地方、渲染完成后的地方，分别打印状态。比如：

goods.count += 1; console.log('点击加号后', goods); // 看数据 renderList(); console.log('渲染完成'); // 确认渲染执行

这样你能快速判断问题出在数据层还是视图层。数据层出问题，改JS逻辑；视图层出问题，改模板字符串或CSS类名。把问题分层，排查速度会快很多。

6. 从案例到真实项目：还有哪些可以升级的点

6.1 从单一文件到模块化组织

这个案例的源代码全部放在一个HTML文件里，JS写在script标签中。方便是方便，但到了真实项目，不可能这样干。

第六章的案例做完后，我的建议是你自己动手把代码拆开：

• index.html只留结构
• style.css存放全部样式
• script.js存放全部JavaScript

更进一步，script.js内部还可以按职责拆成函数区段：数据定义区、渲染函数区、事件绑定区、工具函数区。你不需要引入任何模块加载器，只要在同一文件里保持清晰的分段注释，就能提高可维护性。

// ===== 数据定义 ===== const goodsList = [ ... ]; // ===== 渲染函数 ===== function renderList() { ... } function updateSummary() { ... } // ===== 事件绑定 ===== function bindEvents() { ... } // ===== 初始化 ===== init();

这种组织方式，就是日后工程化项目里模块拆分的雏形。

6.2 从innerHTML全量渲染到更精细的更新策略

我在前文提到，全量渲染在这个小案例里没问题，但真实项目中性能不行。如果你想深入，可以尝试两种改造路径。

第一种是局部更新：数量变化时，只修改对应商品行里的小计数字和总价，不重建整行。这个优化需要你学会从哪里找到目标元素，以及如何精准更新。

// 示意：只更新小计 const subtotalEl = itemElement.querySelector('.goods-subtotal'); subtotalEl.textContent = '¥' + goods.price * goods.count;

第二种是引入数据驱动框架的思路：把渲染逻辑抽象一下，定义一个render函数作为"数据状态到界面表现"的映射。这一点和Vue、React的理念是一致的，但第六章阶段不需要用框架，你自己实现一次状态变更后重新渲染，会对框架的原理有更深的体感。

6.3 关于代码规范的现实建议

最后说说代码规范。我看到不少初学者的代码里，变量名一会用拼音一会用英文，函数名有动词有名词毫无规律。这个案例里我用的命名方式，你在后续项目里可以直接沿用：

• 数据集合用list结尾：goodsList
• 渲染类函数用render开头：renderList、renderHeader
• 更新类函数用update开头：updateSummary
• 事件处理类函数用handle或on开头：handleItemClick

命名统一后，代码的可读性会大幅提升。哪怕代码结构没那么优雅，只要命名清晰、格式统一，别人接手成本就会低很多。这一点，在团队协作中比任何奇技淫巧都重要。

我个人的体会是，这类综合案例的意义，不在于代码写得多么高级，而在于把"数据驱动视图"这条主线打通。以后你再碰到任何前端交互页面，不管复杂度多高，本质上都在做同一件事：用户操作改变数据，数据改变驱动界面更新。把这个模型刻在脑子里，前端路上的很多困惑都会迎刃而解。