HTML期末大作业购物商城实战：布局、购物车状态与答辩

做前端这十来年，每年临近期末都会收到一堆类似的问题：“老师布置了个 HTML 期末大作业，要做个购物商城，我该从哪下手？”标题里挂着的那个商城案例名字，其实是国内教学圈里流传很广的一套演示体系，练手价值确实高：它把 HTML 结构、CSS 布局、JavaScript 交互三块最基础的能力全串起来了，还顺带逼你思考数据怎么组织、页面之间怎么通信。这篇文章我想把它彻底讲透——从老师到底在看什么、目录怎么分、版心和卡片间距怎么算，到购物车状态怎么做、轮播图定时器怎么不打自己脸，最后再聊聊答辩时怎么把设计讲明白。无论你是刚学完三大件、只会写几个 div 的新手，还是想拿这个作业当复习提纲的老手，都能从里面抄到能直接用的东西。

1. 先把这个题目看透：期末大作业到底在考什么

1.1 评分逻辑：老师真正在意的三件事

很多人拿到题目第一反应是“赶紧找模板”，找完发现模板跑不通，改又不敢改，最后交上去的东西自己都讲不清。问题出在没搞清楚评分点。这类作业的评分维度其实很稳定，基本就是三块：界面还原度、代码规范性、功能完整度，再加上答辩时的表达。

界面还原度不是说你做得多花哨，而是“看起来像个真商城”——顶部有 logo 和搜索框，中间有导航和轮播，下面有商品网格，底部有版权信息。这种结构感比配色重要得多。代码规范性看的是命名、缩进、注释、有没有把样式写成一坨行内 style，CSS 是不是按“基础样式 → 公共组件 → 页面私有”分层。功能完整度则是看你有没有真正跑通一条链路：从列表点进详情、加购、购物车里改数量、算总价、删商品，这条链路哪怕只用一个页面加 JS 模拟，也比五个页面全是死链强得多。

我见过不少作业界面很漂亮，但一点“加入购物车”就 alert 一个“添加成功”，数据根本没存下来，一刷新页面购物车就空了。这种在答辩环节一被追问就露馅。所以从第一天起就要有个意识：你写的不是静态页面，而是一个有状态的小应用，状态怎么存、怎么同步，是这个作业真正的分水岭。

1.2 需求拆解：从标题里能拆出几类页面

把“购物商城”这四个字拆开，落到页面上其实就五六张：首页（含轮播、楼层商品）、商品列表页（分类筛选、排序）、商品详情页（主图、参数、加购）、购物车页（勾选、加减、合计）、登录/注册页（表单校验），有余力再加个订单确认页。

每一页的难度不一样。首页是布局难度最高的，因为元素最多、对齐要求最细；列表页是交互难度中等，主要考验渲染和筛选；购物车页是逻辑难度最高的，因为涉及状态计算；登录页是细节最多的，各种校验和提示。建议的推进顺序是：先首页把整体视觉定下来，再详情页复用头部尾部，然后列表页练渲染，最后啃购物车。这个顺序的好处是，首页确定下来的公共样式和组件，后面三页能直接拿过去用，越写越快。

这里有个常见的误判：很多人觉得详情页最简单，随便堆点文字就行。实际上详情页是老师最可能点开细看的一页，因为它体现你对“图片 + 文字信息 + 操作按钮”这种经典布局的理解。主图区和信息区左右分栏怎么分、参数表怎么排、加入购物车按钮放哪，都有讲究。

1.3 技术选型：为什么不用框架反而更考验人

题目限定 HTML+CSS+JavaScript，很多人心里嘀咕：现在谁还手写这些，用个组件库半小时就搞定了。这话没错，但在这个场景下，纯原生反而更锻炼人，原因有三个。

第一，没有抽象兜底。用框架时，列表渲染是v-for一行搞定，你不用关心 DOM 怎么更新；原生环境里，你得自己决定是拼接 innerHTML 还是 createElement，得自己处理字符串转义、事件绑定。这个过程逼你把“数据怎么变成界面”这件事想清楚，而这个认知是框架学得再溜也换不来的。

第二，样式没有预设。组件库自带间距、圆角、阴影，你只要摆位置；手写 CSS 时，一行商品列表里卡片宽度和间距怎么分配、最后一行不满怎么对齐，全得自己算。这些计算看着琐碎，但正是从“会写页面”到“会做布局”的分界线。

第三，答辩好讲。用框架做出来的东西，老师一句“这行代码为什么这么写”就能问住；原生代码每一行都是你自己的决定，讲起来底气足。而且这套项目规模不大，原生完全扛得住，性能上没有任何问题。

提醒一句：别在这个项目里引入需要构建工具的东西。老师本地打开你的文件夹，双击 HTML 最好能直接跑起来。任何需要命令行启动的依赖，都是给自己挖坑。

2. 项目整体骨架与文件组织

2.1 目录结构：三天后你会感谢现在的自己

我见过最惨的作业是把所有东西堆在一个文件夹里，图片叫1.jpg、2.jpg，样式全塞在 HTML 的<style>里，五个页面各写一份。这种结构在写到第三页时就会崩盘——改个导航颜色要动五个文件，漏一个就不一致。

合理的结构大概是这样：

mall/ ├── index.html 首页 ├── list.html 商品列表 ├── detail.html 商品详情 ├── cart.html 购物车 ├── login.html 登录注册 ├── css/ │ ├── base.css 重置样式 + 变量 + 通用类 │ ├── common.css 头部、底部、按钮等公共组件 │ ├── index.css 首页私有样式 │ ├── list.css │ └── cart.css ├── js/ │ ├── data.js 模拟商品数据 │ ├── common.js 公共方法：格式化价格、读取存储 │ ├── index.js │ └── cart.js ├── images/ │ ├── banner/ 轮播图 │ ├── goods/ 商品图，按 id 命名 │ └── icon/ 图标 └── README.md 简单说明：页面清单、功能点

这个结构有两个隐含的设计决定值得说一下。一是base 和 common 分开：base.css放的是跟业务无关的东西（盒模型重置、字体、通用间距类、CSS 变量），common.css放的是跟业务相关但多页共用的东西（头部、底部、商品卡片骨架）。分开的好处是，将来换皮或者复用到别的项目，base.css可以直接拿走。

二是data.js 独立。把商品数据从页面逻辑里抽出来单独一个文件，是所有改动的起点。后面列表页渲染、详情页读取、购物车查商品信息，全靠它。这一步做了，后面省一半力气。

2.2 页面与模块的对照表

动手前先画一张表，把每页包含哪些模块列清楚，写代码时按表推进，不容易漏。我当时整理的大概是这样：

这张表还有个用处：它直接就是你答辩时的功能清单。你按表逐项演示，逻辑清清楚楚，比临场想到哪点到哪强太多。

2.3 公共部分的复用：三种方案和我的选择

头部和底部要在五个页面出现，怎么复用是个绕不开的问题。常见三种做法，各有代价。

第一种是直接复制粘贴。最土，但最稳，双击就能跑，不依赖任何环境。缺点是改一次要改五处。我的做法是复制，但在每份头部代码的前后加上醒目的注释标记<!-- ===== 公共头部 开始 ===== -->，改的时候全局搜索这个标记，一处处改，改完对着标记数一遍是五处就对了。

第二种是JS 动态注入。写个header.js，里面用document.write或者innerHTML把头部结构塞进去。好处是真正的一处维护，坏处是页面加载瞬间会有闪烁，而且如果用户本地直接双击打开，某些浏览器对本地文件的一些限制可能让脚本行为不一致，答辩现场出问题就尴尬了。

第三种是iframe 嵌套。看起来最“组件化”，实际上样式隔离、高度自适应、SEO 全是坑，而且老师一看就知道你在回避问题，反而扣分。

所以我一般选第一种，但会在答辩时主动说明：“公共部分我用了复制的方式保证离线可运行，同时在注释里做了同步标记，如果后续接入构建工具，这部分可以抽成模板或者组件。”这句话说出来，老师会认为你想过这个问题，而不是没想过。

3. HTML 结构：语义化和可维护性怎么兼顾

3.1 首页骨架的搭建顺序

首页元素最多，一定要按顺序搭，从外到内、从上到下。我的顺序是：先写整体的几个大块（头部、导航、轮播、楼层、底部），每块先用带背景色的空 div 占位，把高度和位置定下来；确认整体比例舒服了，再往里填内容。

这么做的好处是，你能在十分钟内看到整页的“骨架比例”，不至于写了一百行发现轮播区太矮、楼层太挤，然后推倒重来。很多新手一上来就从 logo 开始精雕细琢，写到一半发现整体节奏不对，前面的功夫全白费。

具体到标签选择，能用语义标签就别用 div：头部用<header>，导航用<nav>，主体内容用<main>，每个商品卡片用<article>或者<li>，底部用<footer>。这些东西视觉上没区别，但能体现你学过 HTML5。列表类的商品一定是ul > li，不要用一堆 div 平铺，这在语义和可维护性上都是硬伤。

<header class="header"> <div class="w header-inner"> <a class="logo" href="index.html">商城</a> <form class="search" action="list.html"> <input type="text" name="keyword" placeholder="搜索商品"> <button type="submit">搜索</button> </form> </div> </header>

这段代码里有两个细节值得说。一是搜索用了form加action="list.html"，而不是一个 input 加一个 button 然后用 JS 跳转——原生表单提交天然支持回车触发，代码还少。二是 logo 用<a>包起来指向首页，这是全站导航的默认习惯，用户点 logo 回首页是肌肉记忆，别省。

3.2 列表页和详情页的结构差异

列表页的核心是“一组同构元素”，所以结构上要保证每个商品卡片的 DOM 层级完全一致，只有这样 CSS 才能一套写完。卡片的典型结构是：图片链接、标题、价格、销量、加购按钮。

<ul class="goods-list"> <li class="goods-item"> <a class="goods-link" href="detail.html?id=1001"> <img class="goods-img" src="images/goods/1001.jpg" alt="商品名称"> <h3 class="goods-name">商品名称占位</h3> </a> <p class="goods-price"><em>¥</em>129.00</p> <p class="goods-sale">已售 328 件</p> <button class="btn-add"><div class="form-item"> <label for="phone">手机号</label> <input type="tel" id="phone" name="phone" maxlength="11" placeholder="请输入11位手机号"> <span class="err"></span> </div>

还有个小细节：autocomplete="off"建议加上，不然浏览器弹出历史记录下拉，截图和演示都难看。这种细节没人会因为你加了指出来夸你，但少了会显得不专业。

4. CSS 布局：从版心计算到响应式取舍

4.1 版心宽度和卡片间距的数学

商城类页面几乎都用一个固定版心居中，最常见的是 1200px。为什么是 1200 而不是 1000 或者 1400？因为要兼顾主流笔记本（1366 和 1440 宽）和 1920 大屏，1200 在 1366 屏上左右各留 83px，视觉上不局促；在 1920 屏上留白多一点，但内容不会被拉得太散。而且 1200 能被 4、5、6、8、10 整除，做网格计算很友好。

版心的写法就一行：

.w { width: 1200px; margin: 0 auto; }

接下来是卡片宽度的计算，这是很多人卡住的地方。假设一行放 5 个卡片，卡片之间间距 10px，那么 4 个间隙共 40px，可用宽度 1200 - 40 = 1160px，每个卡片 1160 / 5 = 232px。这个数能整除，很舒服。如果一行放 4 个，间距 16px，则是 (1200 - 48) / 4 = 288px，也整除。放 6 个的话，(1200 - 50) / 6 = 191.67px，除不尽，浏览器会做亚像素渲染，某些缩放下可能出现 1px 错位——这就是为什么不推荐一行 6 个。

经验之谈：卡片宽度尽量算成整数，间距尽量用偶数。这样在 125%、150% 缩放下不容易出现最后一行对不齐的诡异现象。

4.2 Flex 和浮动的取舍：最后一行是检验标准

做商品网格时，justify-content: space-between配合flex-wrap: wrap是最顺手的写法，但它有个致命的坑：最后一行不满时会被撑开。比如一行 5 个、一共 8 个商品，第二行的 3 个会被均匀分布到两端和中间，看起来像故意错位。

这个坑我踩过不止一次。解决办法有三个：

1. 用gap加上justify-content: flex-start，最后一个卡片的右间距手动补或者干脆不补（因为版心右边界对齐问题不大）；
2. 给卡片设margin-right，再用:nth-child(5n)把每行最后一个的 margin 清掉；
3. 在数据层面补齐占位元素，让总数凑成 5 的倍数。

我一般选第 2 种，因为它同时解决了“卡片之间间距”和“最后一行对齐”两个问题，可控性最好：

.goods-list { display: flex; flex-wrap: wrap; } .goods-item { width: 232px; margin: 0 10px 20px 0; } .goods-item:nth-child(5n) { margin-right: 0; }

至于什么时候还用浮动：头部的 logo 和搜索框、底部的多栏链接、详情页的左右分栏，这些“一左一右”的经典场景，浮动依然简单直接。但如果要做垂直居中或者等高布局，浮动就得靠 hack，这种时候果断上 flex。判断标准很简单：一行内元素要垂直居中的，用 flex；单纯左右贴边的，浮动和 flex 都行，看心情。

4.3 让页面“贵”一点的几个样式细节

同样的结构，有人做出来像作业，有人做出来像产品，差别往往在几个小地方。

字号的阶梯。不要满屏 14px 和 16px，要有层级：商品标题 14px，价格 22px 且加粗，辅助信息（销量、规格）12px 且用灰色。价格的数字部分建议用font-family里带等宽特性的字体栈，或者至少保证数字不被挤在一起。

颜色不要用纯黑纯灰。正文用#333，辅助文字用#999，分割线用#eee。纯黑#000在屏幕上会显得刺眼，纯灰#ccc又太淡。主色建议选一个红或者橙，全局统一，所有按钮、价格、促销标签都用它。

:root { --main-color: #e1251b; --text-main: #333; --text-sub: #999; --line: #eee; --gap: 10px; }

用 CSS 变量管颜色，改主题只要动一行。注意这是教学环境，主流浏览器都支持，不用担心兼容。但要在答辩时提一句“变量是为了统一维护”，这是加分项。

阴影和圆角要有节制。卡片加 2px 的圆角和一层淡阴影（0 2px 8px rgba(0,0,0,.06)）就够了，别加那种 20px 模糊的大黑影，看着像十年前的设计。

hover 状态一定要有。商品图 hover 放大（transform: scale(1.05)加overflow: hidden）、按钮 hover 变色、链接 hover 加下划线。这些是“有没有用心”的直接体现。

4.4 动画性能：别让 hover 卡住整页

做图片放大效果时，记得给容器加overflow: hidden，并且用transition: transform .3s，不要用width或者margin做动画——后者会触发重排，商品一多就掉帧。

另外提醒：transform: scale()在父级有overflow: hidden时可能被裁切，如果遇到图片放大后边缘被切，检查一下是不是这个原因。还有个常被忽略的点，transition要写在基础状态上而不是 hover 里，否则移入有动画、移出瞬间跳回，体验很怪。

5. JavaScript 功能实现：把状态管起来

5.1 数据先行：用一份数组撑起三个页面

在写任何交互之前，先把商品数据整理成结构化的数组，单独放data.js：

const GOODS = [ { id: 1001, name: "商品名称占位一", price: 129, origin: 199, img: "images/goods/1001.jpg", sale: 328, cate: "数码" }, { id: 1002, name: "商品名称占位二", price: 89, origin: 129, img: "images/goods/1002.jpg", sale: 1204, cate: "家电" }, // ... ];

字段设计要提前想好：id是唯一标识，后面购物车、详情页全靠它；price用数字不用字符串，方便计算；origin存原价，用来做划线价；img存相对路径；cate用来做列表页的分类筛选。

有了这份数据，列表页的渲染就是一句话的事——遍历、拼字符串、塞进容器。详情页则是根据 URL 上的?id=1001去数组里find出对应的对象。这就是为什么说“数据先行”，三个页面共用一份数据源，改一次全站生效。

渲染函数我建议写成这样，用模板字符串：

function renderList(list) { const html = list.map(item => ` <li class="goods-item"> <a class="goods-link" href="detail.html?id=${item.id}"> <img class="goods-img" src="${item.img}" alt="${item.name}"> <h3 class="goods-name">${item.name}</h3> </a> <p class="goods-price"><em>¥</em>${item.price.toFixed(2)}</p> <button class="btn-add">// 购物车核心方法 const CART_KEY = "mall_cart"; function getCart() { return JSON.parse(localStorage.getItem(CART_KEY) || "[]"); } function saveCart(cart) { localStorage.setItem(CART_KEY, JSON.stringify(cart)); } function addToCart(id, num = 1) { const cart = getCart(); const item = cart.find(i => i.id === id); if (item) { item.count += num; } else { cart.push({ id, count: num, checked: true }); } saveCart(cart); updateBadge(); }

注意JSON.parse那里必须给个兜底"[]"。如果本地存储里是空字符串或者之前存过脏数据，JSON.parse会直接抛错，整个页面脚本停摆。这个坑我见过太多次，标红的控制台报错十有八九是这句。

还有一个隐藏的坑：金额计算的浮点误差。19.9 * 3在 JS 里等于59.699999999999996，直接toFixed(2)能糊弄过去，但做减法的时候可能出问题。更稳的做法是内部用“分”做单位存整数，显示时再除以 100。如果嫌麻烦，至少在每次计算后用toFixed(2)格式化。

5.3 数量控件和总计刷新

购物车里每行的加减按钮、复选框、删除按钮，元素数量是动态的，如果给每个按钮单独绑事件，每次重新渲染都要重新绑一遍，既啰嗦又容易内存泄漏。正确的姿势是事件委托：把监听器挂在父容器上，靠event.target判断点到了谁。

cartBody.addEventListener("click", function (e) { const btn = e.target.closest("[data-act]"); if (!btn) return; const act = btn.dataset.act; const id = +btn.closest(".cart-item").dataset.id; const cart = getCart(); const item = cart.find(i => i.id === id); if (act === "plus") item.count++; if (act === "minus") item.count = Math.max(1, item.count - 1); if (act === "del") { if (!confirm("确定删除该商品吗？")) return; cart.splice(cart.indexOf(item), 1); } saveCart(cart); renderCart(); });

closest这个方法在原生开发里是神器，能省掉一堆parentNode.parentNode的链条。用它配合>function calcTotal() { const cart = getCart(); return cart.filter(i => i.checked).reduce((sum, i) => { const g = GOODS.find(g => g.id === i.id); return sum + (g ? g.price * i.count : 0); }, 0); }

那个g ? ... : 0的判断别省——万一你手动改了data.js删了某个商品，而用户购物车里还留着那个 id，不做判断就会整页白屏。

5.4 轮播图：定时器和人为操作的和解

轮播图几乎是每份作业都会做的，也是最容易写出 bug 的。常见问题是：定时器自动切，用户一鼠标移上去还在切，移开之后节奏乱了；或者连点右侧按钮，索引越界，图没了。

我的实现思路是这样：维护一个index，定时器每 2 秒让index自增并取模。鼠标移入容器时clearInterval，移出时重新setInterval。左右按钮点击时，先清定时器，改index，重绘，再重新起定时器。关键点是每次重新起定时器前，务必确保上一次的定时器真的被清掉了，否则会出现“越点越快”的鬼畜效果。

let index = 0; let timer = null; const total = 4; function go(n) { index = (n + total) % total; // 取模保证循环 track.style.transform = `translateX(-${index * 100}%)`; dots.forEach((d, i) => d.classList.toggle("active", i === index)); } function start() { stop(); timer = setInterval(() => go(index + 1), 2000); } function stop() { if (timer) { clearInterval(timer); timer = null; } } banner.addEventListener("mouseenter", stop); banner.addEventListener("mouseleave", start);

(n + total) % total这个写法是为了处理负数。点左按钮时n是index - 1，如果index是 0，就变成 -1，直接取模在 JS 里还是 -1，加上 total 再取模才能得到 3。这种边界情况是自己测出来的，不实际点几下根本发现不了。

至于“无缝滚动”，标准做法是克隆首尾两张图，滑到最后一张时瞬间跳回第一张。但说实话，淡入淡出或者平移加透明度，视觉效果已经够用了，而且代码量少一半，出 bug 的概率也低。教学项目里我建议选简单方案，把精力花在购物车上。

5.5 跨页面通信：localStorage 的用法和坑

从列表页加购，跳到购物车页要能看到，这就是跨页面通信。方案只有那么几种：URL 传参、localStorage、cookie。购物车数据量稍大且要持久保存，localStorage 是最合适的。

用的时候注意三点。一是统一 key 前缀，比如都叫mall_开头，避免和其他页面冲突；二是读写都要 try-catch 包一层，隐私模式下有些浏览器写不进去会抛异常，虽然作业场景不常见，但包一下不亏；三是存对象必须 JSON 序列化，localStorage 只能存字符串，直接存对象会变成[object Object]。

还有一个隐蔽的坑：file://协议下，不同浏览器对 localStorage 的隔离策略不一样。有的浏览器把本地所有 HTML 视为同一个源，有的按目录隔离。如果你发现“在列表页加购了，购物车页读不到”，先别怀疑代码，检查一下是不是这个原因，或者干脆用本地服务器打开测试。答辩前一定要在自己电脑上按老师的打开方式（大概率是双击）完整跑一遍。

6. 常见问题与排查实录

6.1 布局类问题的快速定位法

布局问题看着杂，其实排查有套路：先看是不是元素没设高度导致塌陷，再看是不是浮动没清，最后看盒模型有没有算错。我踩过的几个典型：商品列表用了浮动但没清除，父容器高度变成 0，下面的楼层直接叠上来；图片不设宽高，加载前是 0，加载后撑开，导致页面闪一下；box-sizing忘了设border-box，加了 padding 之后宽度超出。

推荐的排查动作是给可疑元素临时加outline: 1px solid red，比背景色好用，因为它不占空间也不影响布局。outline能直接告诉你这个盒子的真实边界在哪，比盯着屏幕猜快十倍。

6.2 JavaScript 常见故障速查

JS 的问题更隐蔽，因为不报错但结果不对。我把遇到过的高频问题整理成了一张表：

表格里最后一条值得展开说。详情页要读?id=1001，很多人用字符串切割location.search.split("=")[1]，一旦以后加了第二个参数就废了。用URLSearchParams一行搞定，可读性和健壮性都好得多：

const id = +new URLSearchParams(location.search).get("id");

如果没有 id 或者 id 找不到对应商品，要给个友好提示而不是白屏，比如显示“商品不存在，返回列表”。这种容错处理是加分项。

6.3 我踩过的三个印象最深的坑

第一个是图片路径的坑。当时本地测试一切正常，拷到 U 盘拿去机房演示，图全裂了。原因是文件名里有大写字母和中文，机房那台机器解压后编码不一样。从那以后我所有资源文件名一律小写英文加下划线，这条规矩沿用至今。

第二个是事件重复绑定。购物车每次重新渲染后，我又给新生成的按钮绑了一次事件，但容器上的委托监听器没清，导致点一次加号数量加 2。现象特别诡异，改了半天才发现是监听器叠加。后来养成习惯：委托只绑一次，绑在容器初始化时。

第三个是定时器泄漏。轮播的定时器在页面切换时没清，回到首页发现轮播速度是原来的两倍。这个问题的根源是单页应用的思维没建立起来，页面离开时该做的事（清定时器、解绑事件）没做。虽然这个项目是多页面跳转，跳转本身会销毁，但如果你用 iframe 或者做弹窗，就得注意。

一句实在话：这三个坑没有一个是从教程里学来的，全是自己撞出来的。所以别怕改坏，改坏了才知道边界在哪。

7. 答辩与验收：怎么把设计讲清楚

7.1 演示脚本：按一条主线走

答辩时间通常只有三五分钟，别从头到尾滚页面，那样老师记不住。要设计一条主线：从列表页开始，筛选一个分类，点进详情，切换主图，加入购物车，跳转购物车，改数量看总价变化，勾选看合计变化，删除一项，刷新页面证明数据还在。这条线完整覆盖了渲染、跳转、状态、存储四个能力点，讲完基本就说明白了。

演示前务必做的事：清空 localStorage 跑一遍完整流程，确认没有死链，把浏览器缩放调回 100%，关掉所有插件和书签栏。这些细节会影响老师对你“工程素养”的判断。

7.2 会被追问的几个问题及回答思路

老师最爱问的几类问题，提前准备好答案会从容很多。

“为什么购物车数据存在本地而不是服务器？”——答：这个项目是纯前端，没有后端环境，所以用 localStorage 模拟持久化；如果要接后端，会把购物车结构原样提交给接口，前端只保留一份缓存。

“为什么用 flex 不用 grid？”——答：商品网格这种等宽多列布局，grid 其实更合适；我用 flex 是为了兼容旧思路，同时头部、底部这些一维布局本来就更适合 flex。如果重写，网格部分我会换成grid-template-columns: repeat(5, 1fr)。

“多个页面头部重复，你怎么维护？”——答：目前是复制加注释标记，权衡的是离线可运行；如果允许工程化，会拆成公共模板或者用构建工具做 include。

这些问题不需要答得多高深，关键是要表现出你想过取舍，而不是碰巧这么写的。这也是我在前面反复强调“每个选择都要能说出理由”的原因——同一个作业，讲得出理由和讲不出理由，分数差得很远。

最后再分享一个小技巧：交作业前，把整个项目文件夹复制一份，改个名字，然后在另一台电脑（或者换个盘符路径）打开跑一遍。这一步能抓出 90% 的路径问题和环境问题，成本只要五分钟，但能避免答辩当场社死。这个习惯我从学生时代一直保留到现在，任何要交付的东西，都先在“干净环境”里验证一次再说。