简介小兔鲜是一个包含登录、购物车等五个页面的前端项目面向正在学习HTML、CSS与JavaScript的初学者可用于理解多页面网站从结构搭建到交互实现的完整过程。压缩包约12.78MB共179个文件以140张JPG和21张PNG图片为主另有7个CSS、6个HTML、4个JS及1个ICO图标文件CSS负责页面样式HTML组织内容结构JS处理登录验证、购物车数量加减等动态操作图片素材用于商品展示和界面装饰。项目参考黑马程序员前端视频教程完成并做了改进扩展覆盖语义化标签、盒模型、Flex布局、表单处理、响应式适配和DOM操作等知识点页面包含登录、购物车等高频场景便于逐一拆解与改版练习。已有4368人学习下载适合前端初学者对照源码梳理多页面开发流程也可作为课程设计或期末作业的参考样例直接借鉴其中的页面结构和交互思路。1. 五页面的信息架构为什么是登录首页列表详情购物车这个组合做小兔鲜这类电商类前端demo我见过太多人一上来就打开编辑器写页面结果做到第三个页面就发现首页要用的数据在列表页没存、详情页要跳转时带不过去参数、购物车刷新一下就清空了。所以我拿到这个标题的第一件事不是写代码而是先把五个页面的关系画在纸上。对于电商项目来说登录、购物车这两个页面是刚性的属于业务闭环里必须存在的节点但只有这两个页面撑不起一个完整流程。你思考一下用户实际逛店的动线从首页看到一个商品分类入口进入列表页筛选浏览点进某个商品查看详情决定购买后加入购物车最后结算时如果登录信息过期会被要求重新登录。所以合理的五个页面应该是首页、商品列表页、商品详情页、购物车页、登录页。登录页看似独立其实是购物车结算和下单行为的前置条件。页面之间的跳转关系也要在设计时就定下来首页可以跳列表页和购物车列表页可以跳详情页详情页有两个出口——加购后留在当前页或者跳购物车结算购物车如果检测到未登录需要引导跳登录页。这个跳转链路一旦在项目初期理顺后面写点击事件和路由逻辑会节省大量返工时间。小兔鲜这个名字听起来更偏向生鲜这种生活化品类所以我给商品数据的构建也多考虑了一点场景感。不同的电商类型决定数据的字段设计一般书城、数码店偏向规格参数而生鲜类demo则更多要考虑单位、库存、标签比如时令、秒杀、满减这些字段会影响列表页的筛选和详情页的信息展示后面写数据的时候会专门聊。2. 登录页看似简单真正花时间的是校验和登录态维持2.1 表单校验别偷懒用浏览器自带提示自己写一套更可控登录页是五个页面里唯一一个表单密集型页面看似只是输入手机号密码点按钮但实际做下来最容易出问题的是校验逻辑。钝刀割肉式的写法是每个输入框单独写一个监听事件校验失败时弹alert这种交互放到demo里非常劝退用户。我用的是统一validate函数 失焦和点击时的双触发机制。手机号在这里用的是 /^1[3-9]\d{9}$/ 这个正则不要觉得简单就跳过。为什么不是更宽松的 /^1\d{10}$/因为13到19开头的号段是目前实际发放的用这个更符合真实业务场景也避免了用户输入12开头的非法号段时白白走一遍接口流程。密码这里我只做了非空和长度6到20位的校验逻辑并不复杂但错误信息的展示方式要注意每个字段下方用独立的错误提示元素而不是统一弹一个提示框。错误信息用轻量的警示色符号并且在校验通过后要即时清除这属于交互细节的加分项。2.2 密码处理和登录态存储方案的选择前端demo里经常有人问密码要不要加密我的答案是需要但要看懂加密的目的。前端加密不是为了防黑客——真正防泄露靠的是后端加盐哈希——而是防止用户在公共网络下被旁观者直接看到明文密码。这个小项目里没有真实后端所以我用最简单的方式给密码做个处理先把密码用固定的盐字符串拼接再做一次SHA-256哈希运算。这里很多新手会误解以为要引入什么加密库其实利用浏览器的crypto.subtle.digest接口就能实现异步处理即可。当然我必须要说明这依然只是模拟登录真实项目首次登录应该走HTTPS由后端完成正式的密码验证与Token签发前端做的这些只是基础卫生习惯。登录成功后需要保存登录态现代前端方案优先级一般是短时效Token存内存或sessionStorage、长期Token存localStorage并配合刷新接口。但小兔鲜既然是纯前端demo没有正经后端接口我选择了localStorage来存模拟的token和用户基本信息。存的字段包括token随机的UUID格式字符串、nickname、loginTime。有一点要提醒不要把密码存进localStorage一旦页面被注入恶意脚本等于把钥匙和锁一起送人。2.3 登录失效的判断和退出机制既然用localStorage存了token就需要想清楚失效这件事怎么做。我在小兔鲜里设了一个经验阈值token存进去的时候同时记录一个expireTime设置为当前时间 24小时。每次进入购物车和结算这类需要身份的动作前读取当前时间与expireTime做对比超过就直接清掉localStorage里的登录信息并跳转登录页。退出功能也别忘了入口放在购物车页面的右上角。退出动作要做的不只是清空登录信息还有购物车缓存——你可以选择保留游客购物车也可以清空重来两种都有业务道理。我在这个demo里选择了退出后保留游客购物车因为换账号登录但购物车还在这种情况在一些真实平台也存在比如淘宝但为了不让逻辑复杂化你也可以直接清空能够在代码注释里把那行写清楚是更好维护的。3. 首页和列表页的商品数据组织方式决定了后面所有页面的工作量3.1 用数组模拟数据源提前规划好字段小兔鲜没有后端接口所以我用了一个独立的goodsData.js文件来模拟商品数据。这个文件导出一个数组每个商品对象包含这些字段id、name、category用于分类筛选、price、originalPrice用于展示划线价、unit比如500g/份、stock、sales销量用于排序、tags数组用于展示时令秒杀等标签、isHot是否热门、image。我要强调一下为什么字段要这样规划。电商列表页最常见的需求就是筛选和排序把category、sales、price作为独立字段后面用Array.prototype.filter和sort方法就能非常优雅地实现交互而不需要写一堆if-else嵌套判断。isHot是专门用来实现首页热门推荐板块的标记首页只渲染isHot为true的商品省去再写一套筛选逻辑。模拟数据时有个小建议数量控制在12到16个左右太少了看不出筛选效果太多了页面渲染时滚动条太长不美观。每个商品的图片可以先用占位图服务或者纯色块文字代替把布局跑通后再替换真实图片这样主次分明。3.2 列表渲染的策略模板字符串还是DOM操作在原生JavaScript实现里渲染商品列表最朴素也最好理解的方式是用模板字符串拼接HTML然后通过innerHTML写入容器。我看到很多人喜欢用createElement逐个节点创建这在元素结构简单时问题不大但商品卡片这种多嵌套结构每个项要创建六七个节点代码量和出错概率都翻倍。我实际用的是map join的方式function renderGoods(list) { const container document.getElementById(goodsList); container.innerHTML list.map(item div classgoods-card>function getFilteredGoods() { let list [...goodsData]; if (currentCategory ! all) { list list.filter(item item.category currentCategory); } if (sortType sales) { list.sort((a, b) b.sales - a.sales); } else if (sortType priceAsc) { list.sort((a, b) a.price - b.price); } else if (sortType priceDesc) { list.sort((a, b) b.price - a.price); } return list; }不管是分类筛选、关键词搜索还是排序状态我都建议用URL参数来拼装而不是用全局变量。原因是URL参数天然支持刷新后状态保留而且从首页跳转到列表页时只需要在链接后面加参数比如list.html?categoryfruit就能决定列表页展示哪个分类这是多页面应用里最简单的页面间通信方式。具体读参逻辑用URLSearchParams就能搞定。有些读者可能会问为什么首页不直接展示所有商品这就回到了产品逻辑问题——首页的定位是导流和推荐列表页才是穷举商品的地方。把小兔鲜做成有区分度的页面信息架构才会清晰用户也不会在首页就被大量信息淹没。这也是为什么我在设计首页时只保留了热门推荐这个板块。4. 购物车模块的完整实现链路从加购到结算4.1 localStorage的存储结构选对数据结构后面少走弯路购物车的核心功能无非是加购、减少、删除、单选、全选、计算总价、结算但真正让我花心思的是数据怎么存放。最省事的存法是把整个购物车数组直接存成JSON比如存的是一条条购物车记录包含商品id、名称、单价、数量、图片等冗余字段。但这样做不仅会让localStorage快速膨胀而且如果商品数据发生变化购物车里的冗余数据就成了没人更新的脏数据。我用的是更轻量的方案localStorage只存商品id到数量的映射比如{1001: 2, 1005: 1, 1023: 3}需要渲染购物车列表的时候从映射里取出每个id和数量再去goodsData里通过find方法查出完整的商品信息。这样做的优势很明显商品名称、价格、图片永远以数据源为准不会出现两边数据不一致的尴尬存储体积小结算时逻辑也更统一。代价是每次渲染都要做一次映射查找但以本地数据这个量级来说性能损耗完全可以忽略。4.2 加购、数量调整、单选全选与总价计算的联动加购按钮的点击逻辑是拿到当前商品的id在购物车映射里找如果已有就数量1没有就新增一条。然后把这个映射写回localStorage同时更新购物车角标的数字。有一个细节需要特别注意加购后不要立刻跳转购物车页应该用加入成功的轻量反馈来替代否则会打断用户浏览商品的连续性。小兔鲜的实现是弹出一个1.5秒自动消失的toast用户想继续逛就继续逛想去购物车就点右下角的角标进入。购物车页面的渲染我把它拆成三个部分左侧是商品勾选框、名称和单价右侧是数量加减按钮和删除按钮。数量加减这里需要限制最小数量为1库存作为最大值超出或低于就直接禁用按钮并给出相应提示。价格联动通常做法是受控更新的方式每次点击加减时重新计算单项小计、已选商品总价和总件数三块内容然后一次性更新视图。总价的实现用reduce把选中的商品逐个累加即可公式就是商品单价 × 数量。全选这个功能的联动很容易写错。我的方案是在渲染列表时根据当前所有商品的选中状态来动态渲染全选按钮。所谓的全选它的本质不是单个按钮驱动所有项二是所有项的状态决定按钮的状态这一点逻辑搞反了就会出现明明全选了按钮却没有打勾的问题。正确习惯是点击全选时把所有商品的selected字段设为true或false而单选时则要反过来检查是否所有项都是true来更新全选按钮的状态。这个双向同步的逻辑不复杂但很考验细心也是面试中容易追问你的点。4.3 结算时的订单数据整理在真实的电商项目中结算前还要经过确认订单这一步但小兔鲜只做了五页面的基础版本所以我直接把结算按钮的点击处理作为模拟提交订单。点击结算时从购物车筛选出所有选中的商品把它们按上面4.1的格式整理成订单数据结构然后写入一个新的localStorage键比如orderList再把购物车里对应的商品移除。这其实就是给后面做我的订单模块埋下的扩展点。对下单前是否必须要登录的判断我放在了结算按钮的点击函数里。判断逻辑就是读取登录状态如果未登录则弹窗提示您还未登录是否前往登录页并跳转到登录页。登录成功后再跳回购物车页而不是直接跳到首页这个细节是保证用户流程顺畅的关键——跳转前记录一下来时的页面路径在需要回跳的时候用历史记录就能做到。5. 跨页面状态同步与登录拦截的几种处理方式5.1 页面间通信不是只有路由一种方案多页面HTML项目里页面之间的数据通信方式主要有三种URL传参、localStorage共享、sessionStorage临时传递。我在小兔鲜里的分工是首页到列表页的分类信息URL参数因为这类参数需要在刷新后保持购物车数据localStorage因为它要跨会话长期存在登录信息localStorage与购物车同理从登录页回跳到来源页URL参数里的redirect字段URL参数传参里有一个常见坑参数值里有中文或特殊字符时直接用location.href拼接后跳转目标页面可能拿到乱码。解决方式是用encodeURIComponent和decodeURIComponent包裹。比如跳列表页的代码location.href list.html?category${encodeURIComponent(水果)};在列表页读取的时候对应的要decodeURIComponent。这个细节的报错不是必现的一旦出现排查起来容易让人困惑所以我提前在这里标出来。5.2 登录拦截的覆盖面不只是进入页面需要拦截很多人做登录拦截时只在页面加载阶段判断一次没有登录就直接跳转。这个思路本身没问题但它漏掉了操作层面的拦截——用户在当前页面停留了一段时间登录态刚好过期这时候再点击结算如果仍然放行业务上就出漏洞了。所以我把拦截逻辑拆成了两层页面级拦截加载购物车页或结算页时检查本地是否存在有效token没有则跳登录页操作级拦截点击结算按钮时再检查一次登录态失效则跳登录页并在登录成功后回跳这样双保险的实现并不会增加多少代码但写出来的体验却扎实很多。需要注意的还有登录成功后的回跳不要直接一律跳首页而是从URL参数里读取redirect字段至少保证用户想去的页面是能直达的。小兔鲜的登录页面在提交成功后会判断redirect参数是否存在存在则跳转到该地址不存在则跳首页。5.3 关于storage事件多标签页同步的进阶方案这个点属于锦上添花的内容如果时间充裕可以加上。使用localStorage的另一个好处是它支持storage事件监听当其他标签页修改了localStorage的数据时当前标签页能立即收到通知。在小兔鲜里如果用户在A标签页加了购物车B标签页打开时可以通过监听storage事件自动刷新购物车角标window.addEventListener(storage, (e) { if (e.key cartMap) { updateCartBadge(); // 如果当前在购物车页重新渲染列表 } });事件里可以直接用e.newValue拿最新数据不需要重新读一遍storage。不过有一点要注意storage事件只在别的标签页触发当前标签页自己是收不到的所以加购完本页的角标更新不能依赖这个事件还得在加购函数里手动调用。这个细节我测试时误踩过值得给大家标记一下。6. 小兔鲜项目里我踩过的坑和优化建议6.1 重复点击加购按钮引发的数量和角标不一致这个坑我做的时候踩得挺猛。第一次写完加购逻辑快速连续点击同一商品的加购按钮发现购物车角标更新正常但打开购物车页看到数量翻了好几倍检查发现是读取旧值、加1、写回这三步之间没有做防抖就像两个人同时抢同一个变量后写的人会覆盖先写的人的结果。解决办法是加一个简单的锁或者通过节流让按钮在一段时间内只能触发一次我采用的是点击后给按钮设置disabled属性300毫秒后再恢复。虽然数值映射的写法比直接改数组更简单但逻辑上依然需要保证操作串行。6.2 每次渲染都全量重绘滚动位置丢失购物车页面做数量加减时我最开始的实现是整个列表重新innerHTML渲染屏幕会闪一下滚动条位置也会回到顶部。这个问题的本质是你本来只改了一个数字前端却把整个列表重绘了成本太高。改进的做法是只更新对应商品那一行的DOM内容。比较简单的实现是给商品行的每个操作按钮的data-id上标记好商品id点击时通过id找到对应的DOM节点只改数量文本和小计文本、总价。实际项目中要用框架的虚拟DOM来避免这种手工DOM定位但原生实现里这种最小范围更新的思路也很值得学习。6.3 登录跳转的循环重定向问题还有一个隐藏较深的坑藏在登录跳转的逻辑里。最开始我没有对redirect做判断登录页一旦被强制访问且redirect参数带上的是login.html本身就会产生登录页跳登录页的死循环。加上我在5.2里说到的操作级拦截逻辑需要判断回跳地址是否为登录页自身如果是就不带redirect。这类边界情况很容易在真实使用中被用户碰到开发阶段却不好模拟所以大家写跳转逻辑的时候一定要多想想如果redirect就是本页怎么办。最后再分享一个我评估这个项目质量时的习惯写完小兔鲜之后我花了不少时间关注那些鼠标路径上看不出来但做了会更好的细节——表单校验字段、加购后的轻反馈、刷新后状态保持、登录失效的感知。一个demo项目如果能把这些细节想清楚你在真实工作中写业务代码时踩坑的概率会低很多。即使是在学校交作业或培训班做项目展示这些细节也是答辩时最能拿得出手的亮点。本文还有配套的精品资源点击获取
小兔鲜电商前端实战：五页面架构与登录购物车状态同步解析
简介小兔鲜是一个包含登录、购物车等五个页面的前端项目面向正在学习HTML、CSS与JavaScript的初学者可用于理解多页面网站从结构搭建到交互实现的完整过程。压缩包约12.78MB共179个文件以140张JPG和21张PNG图片为主另有7个CSS、6个HTML、4个JS及1个ICO图标文件CSS负责页面样式HTML组织内容结构JS处理登录验证、购物车数量加减等动态操作图片素材用于商品展示和界面装饰。项目参考黑马程序员前端视频教程完成并做了改进扩展覆盖语义化标签、盒模型、Flex布局、表单处理、响应式适配和DOM操作等知识点页面包含登录、购物车等高频场景便于逐一拆解与改版练习。已有4368人学习下载适合前端初学者对照源码梳理多页面开发流程也可作为课程设计或期末作业的参考样例直接借鉴其中的页面结构和交互思路。1. 五页面的信息架构为什么是登录首页列表详情购物车这个组合做小兔鲜这类电商类前端demo我见过太多人一上来就打开编辑器写页面结果做到第三个页面就发现首页要用的数据在列表页没存、详情页要跳转时带不过去参数、购物车刷新一下就清空了。所以我拿到这个标题的第一件事不是写代码而是先把五个页面的关系画在纸上。对于电商项目来说登录、购物车这两个页面是刚性的属于业务闭环里必须存在的节点但只有这两个页面撑不起一个完整流程。你思考一下用户实际逛店的动线从首页看到一个商品分类入口进入列表页筛选浏览点进某个商品查看详情决定购买后加入购物车最后结算时如果登录信息过期会被要求重新登录。所以合理的五个页面应该是首页、商品列表页、商品详情页、购物车页、登录页。登录页看似独立其实是购物车结算和下单行为的前置条件。页面之间的跳转关系也要在设计时就定下来首页可以跳列表页和购物车列表页可以跳详情页详情页有两个出口——加购后留在当前页或者跳购物车结算购物车如果检测到未登录需要引导跳登录页。这个跳转链路一旦在项目初期理顺后面写点击事件和路由逻辑会节省大量返工时间。小兔鲜这个名字听起来更偏向生鲜这种生活化品类所以我给商品数据的构建也多考虑了一点场景感。不同的电商类型决定数据的字段设计一般书城、数码店偏向规格参数而生鲜类demo则更多要考虑单位、库存、标签比如时令、秒杀、满减这些字段会影响列表页的筛选和详情页的信息展示后面写数据的时候会专门聊。2. 登录页看似简单真正花时间的是校验和登录态维持2.1 表单校验别偷懒用浏览器自带提示自己写一套更可控登录页是五个页面里唯一一个表单密集型页面看似只是输入手机号密码点按钮但实际做下来最容易出问题的是校验逻辑。钝刀割肉式的写法是每个输入框单独写一个监听事件校验失败时弹alert这种交互放到demo里非常劝退用户。我用的是统一validate函数 失焦和点击时的双触发机制。手机号在这里用的是 /^1[3-9]\d{9}$/ 这个正则不要觉得简单就跳过。为什么不是更宽松的 /^1\d{10}$/因为13到19开头的号段是目前实际发放的用这个更符合真实业务场景也避免了用户输入12开头的非法号段时白白走一遍接口流程。密码这里我只做了非空和长度6到20位的校验逻辑并不复杂但错误信息的展示方式要注意每个字段下方用独立的错误提示元素而不是统一弹一个提示框。错误信息用轻量的警示色符号并且在校验通过后要即时清除这属于交互细节的加分项。2.2 密码处理和登录态存储方案的选择前端demo里经常有人问密码要不要加密我的答案是需要但要看懂加密的目的。前端加密不是为了防黑客——真正防泄露靠的是后端加盐哈希——而是防止用户在公共网络下被旁观者直接看到明文密码。这个小项目里没有真实后端所以我用最简单的方式给密码做个处理先把密码用固定的盐字符串拼接再做一次SHA-256哈希运算。这里很多新手会误解以为要引入什么加密库其实利用浏览器的crypto.subtle.digest接口就能实现异步处理即可。当然我必须要说明这依然只是模拟登录真实项目首次登录应该走HTTPS由后端完成正式的密码验证与Token签发前端做的这些只是基础卫生习惯。登录成功后需要保存登录态现代前端方案优先级一般是短时效Token存内存或sessionStorage、长期Token存localStorage并配合刷新接口。但小兔鲜既然是纯前端demo没有正经后端接口我选择了localStorage来存模拟的token和用户基本信息。存的字段包括token随机的UUID格式字符串、nickname、loginTime。有一点要提醒不要把密码存进localStorage一旦页面被注入恶意脚本等于把钥匙和锁一起送人。2.3 登录失效的判断和退出机制既然用localStorage存了token就需要想清楚失效这件事怎么做。我在小兔鲜里设了一个经验阈值token存进去的时候同时记录一个expireTime设置为当前时间 24小时。每次进入购物车和结算这类需要身份的动作前读取当前时间与expireTime做对比超过就直接清掉localStorage里的登录信息并跳转登录页。退出功能也别忘了入口放在购物车页面的右上角。退出动作要做的不只是清空登录信息还有购物车缓存——你可以选择保留游客购物车也可以清空重来两种都有业务道理。我在这个demo里选择了退出后保留游客购物车因为换账号登录但购物车还在这种情况在一些真实平台也存在比如淘宝但为了不让逻辑复杂化你也可以直接清空能够在代码注释里把那行写清楚是更好维护的。3. 首页和列表页的商品数据组织方式决定了后面所有页面的工作量3.1 用数组模拟数据源提前规划好字段小兔鲜没有后端接口所以我用了一个独立的goodsData.js文件来模拟商品数据。这个文件导出一个数组每个商品对象包含这些字段id、name、category用于分类筛选、price、originalPrice用于展示划线价、unit比如500g/份、stock、sales销量用于排序、tags数组用于展示时令秒杀等标签、isHot是否热门、image。我要强调一下为什么字段要这样规划。电商列表页最常见的需求就是筛选和排序把category、sales、price作为独立字段后面用Array.prototype.filter和sort方法就能非常优雅地实现交互而不需要写一堆if-else嵌套判断。isHot是专门用来实现首页热门推荐板块的标记首页只渲染isHot为true的商品省去再写一套筛选逻辑。模拟数据时有个小建议数量控制在12到16个左右太少了看不出筛选效果太多了页面渲染时滚动条太长不美观。每个商品的图片可以先用占位图服务或者纯色块文字代替把布局跑通后再替换真实图片这样主次分明。3.2 列表渲染的策略模板字符串还是DOM操作在原生JavaScript实现里渲染商品列表最朴素也最好理解的方式是用模板字符串拼接HTML然后通过innerHTML写入容器。我看到很多人喜欢用createElement逐个节点创建这在元素结构简单时问题不大但商品卡片这种多嵌套结构每个项要创建六七个节点代码量和出错概率都翻倍。我实际用的是map join的方式function renderGoods(list) { const container document.getElementById(goodsList); container.innerHTML list.map(item div classgoods-card>function getFilteredGoods() { let list [...goodsData]; if (currentCategory ! all) { list list.filter(item item.category currentCategory); } if (sortType sales) { list.sort((a, b) b.sales - a.sales); } else if (sortType priceAsc) { list.sort((a, b) a.price - b.price); } else if (sortType priceDesc) { list.sort((a, b) b.price - a.price); } return list; }不管是分类筛选、关键词搜索还是排序状态我都建议用URL参数来拼装而不是用全局变量。原因是URL参数天然支持刷新后状态保留而且从首页跳转到列表页时只需要在链接后面加参数比如list.html?categoryfruit就能决定列表页展示哪个分类这是多页面应用里最简单的页面间通信方式。具体读参逻辑用URLSearchParams就能搞定。有些读者可能会问为什么首页不直接展示所有商品这就回到了产品逻辑问题——首页的定位是导流和推荐列表页才是穷举商品的地方。把小兔鲜做成有区分度的页面信息架构才会清晰用户也不会在首页就被大量信息淹没。这也是为什么我在设计首页时只保留了热门推荐这个板块。4. 购物车模块的完整实现链路从加购到结算4.1 localStorage的存储结构选对数据结构后面少走弯路购物车的核心功能无非是加购、减少、删除、单选、全选、计算总价、结算但真正让我花心思的是数据怎么存放。最省事的存法是把整个购物车数组直接存成JSON比如存的是一条条购物车记录包含商品id、名称、单价、数量、图片等冗余字段。但这样做不仅会让localStorage快速膨胀而且如果商品数据发生变化购物车里的冗余数据就成了没人更新的脏数据。我用的是更轻量的方案localStorage只存商品id到数量的映射比如{1001: 2, 1005: 1, 1023: 3}需要渲染购物车列表的时候从映射里取出每个id和数量再去goodsData里通过find方法查出完整的商品信息。这样做的优势很明显商品名称、价格、图片永远以数据源为准不会出现两边数据不一致的尴尬存储体积小结算时逻辑也更统一。代价是每次渲染都要做一次映射查找但以本地数据这个量级来说性能损耗完全可以忽略。4.2 加购、数量调整、单选全选与总价计算的联动加购按钮的点击逻辑是拿到当前商品的id在购物车映射里找如果已有就数量1没有就新增一条。然后把这个映射写回localStorage同时更新购物车角标的数字。有一个细节需要特别注意加购后不要立刻跳转购物车页应该用加入成功的轻量反馈来替代否则会打断用户浏览商品的连续性。小兔鲜的实现是弹出一个1.5秒自动消失的toast用户想继续逛就继续逛想去购物车就点右下角的角标进入。购物车页面的渲染我把它拆成三个部分左侧是商品勾选框、名称和单价右侧是数量加减按钮和删除按钮。数量加减这里需要限制最小数量为1库存作为最大值超出或低于就直接禁用按钮并给出相应提示。价格联动通常做法是受控更新的方式每次点击加减时重新计算单项小计、已选商品总价和总件数三块内容然后一次性更新视图。总价的实现用reduce把选中的商品逐个累加即可公式就是商品单价 × 数量。全选这个功能的联动很容易写错。我的方案是在渲染列表时根据当前所有商品的选中状态来动态渲染全选按钮。所谓的全选它的本质不是单个按钮驱动所有项二是所有项的状态决定按钮的状态这一点逻辑搞反了就会出现明明全选了按钮却没有打勾的问题。正确习惯是点击全选时把所有商品的selected字段设为true或false而单选时则要反过来检查是否所有项都是true来更新全选按钮的状态。这个双向同步的逻辑不复杂但很考验细心也是面试中容易追问你的点。4.3 结算时的订单数据整理在真实的电商项目中结算前还要经过确认订单这一步但小兔鲜只做了五页面的基础版本所以我直接把结算按钮的点击处理作为模拟提交订单。点击结算时从购物车筛选出所有选中的商品把它们按上面4.1的格式整理成订单数据结构然后写入一个新的localStorage键比如orderList再把购物车里对应的商品移除。这其实就是给后面做我的订单模块埋下的扩展点。对下单前是否必须要登录的判断我放在了结算按钮的点击函数里。判断逻辑就是读取登录状态如果未登录则弹窗提示您还未登录是否前往登录页并跳转到登录页。登录成功后再跳回购物车页而不是直接跳到首页这个细节是保证用户流程顺畅的关键——跳转前记录一下来时的页面路径在需要回跳的时候用历史记录就能做到。5. 跨页面状态同步与登录拦截的几种处理方式5.1 页面间通信不是只有路由一种方案多页面HTML项目里页面之间的数据通信方式主要有三种URL传参、localStorage共享、sessionStorage临时传递。我在小兔鲜里的分工是首页到列表页的分类信息URL参数因为这类参数需要在刷新后保持购物车数据localStorage因为它要跨会话长期存在登录信息localStorage与购物车同理从登录页回跳到来源页URL参数里的redirect字段URL参数传参里有一个常见坑参数值里有中文或特殊字符时直接用location.href拼接后跳转目标页面可能拿到乱码。解决方式是用encodeURIComponent和decodeURIComponent包裹。比如跳列表页的代码location.href list.html?category${encodeURIComponent(水果)};在列表页读取的时候对应的要decodeURIComponent。这个细节的报错不是必现的一旦出现排查起来容易让人困惑所以我提前在这里标出来。5.2 登录拦截的覆盖面不只是进入页面需要拦截很多人做登录拦截时只在页面加载阶段判断一次没有登录就直接跳转。这个思路本身没问题但它漏掉了操作层面的拦截——用户在当前页面停留了一段时间登录态刚好过期这时候再点击结算如果仍然放行业务上就出漏洞了。所以我把拦截逻辑拆成了两层页面级拦截加载购物车页或结算页时检查本地是否存在有效token没有则跳登录页操作级拦截点击结算按钮时再检查一次登录态失效则跳登录页并在登录成功后回跳这样双保险的实现并不会增加多少代码但写出来的体验却扎实很多。需要注意的还有登录成功后的回跳不要直接一律跳首页而是从URL参数里读取redirect字段至少保证用户想去的页面是能直达的。小兔鲜的登录页面在提交成功后会判断redirect参数是否存在存在则跳转到该地址不存在则跳首页。5.3 关于storage事件多标签页同步的进阶方案这个点属于锦上添花的内容如果时间充裕可以加上。使用localStorage的另一个好处是它支持storage事件监听当其他标签页修改了localStorage的数据时当前标签页能立即收到通知。在小兔鲜里如果用户在A标签页加了购物车B标签页打开时可以通过监听storage事件自动刷新购物车角标window.addEventListener(storage, (e) { if (e.key cartMap) { updateCartBadge(); // 如果当前在购物车页重新渲染列表 } });事件里可以直接用e.newValue拿最新数据不需要重新读一遍storage。不过有一点要注意storage事件只在别的标签页触发当前标签页自己是收不到的所以加购完本页的角标更新不能依赖这个事件还得在加购函数里手动调用。这个细节我测试时误踩过值得给大家标记一下。6. 小兔鲜项目里我踩过的坑和优化建议6.1 重复点击加购按钮引发的数量和角标不一致这个坑我做的时候踩得挺猛。第一次写完加购逻辑快速连续点击同一商品的加购按钮发现购物车角标更新正常但打开购物车页看到数量翻了好几倍检查发现是读取旧值、加1、写回这三步之间没有做防抖就像两个人同时抢同一个变量后写的人会覆盖先写的人的结果。解决办法是加一个简单的锁或者通过节流让按钮在一段时间内只能触发一次我采用的是点击后给按钮设置disabled属性300毫秒后再恢复。虽然数值映射的写法比直接改数组更简单但逻辑上依然需要保证操作串行。6.2 每次渲染都全量重绘滚动位置丢失购物车页面做数量加减时我最开始的实现是整个列表重新innerHTML渲染屏幕会闪一下滚动条位置也会回到顶部。这个问题的本质是你本来只改了一个数字前端却把整个列表重绘了成本太高。改进的做法是只更新对应商品那一行的DOM内容。比较简单的实现是给商品行的每个操作按钮的data-id上标记好商品id点击时通过id找到对应的DOM节点只改数量文本和小计文本、总价。实际项目中要用框架的虚拟DOM来避免这种手工DOM定位但原生实现里这种最小范围更新的思路也很值得学习。6.3 登录跳转的循环重定向问题还有一个隐藏较深的坑藏在登录跳转的逻辑里。最开始我没有对redirect做判断登录页一旦被强制访问且redirect参数带上的是login.html本身就会产生登录页跳登录页的死循环。加上我在5.2里说到的操作级拦截逻辑需要判断回跳地址是否为登录页自身如果是就不带redirect。这类边界情况很容易在真实使用中被用户碰到开发阶段却不好模拟所以大家写跳转逻辑的时候一定要多想想如果redirect就是本页怎么办。最后再分享一个我评估这个项目质量时的习惯写完小兔鲜之后我花了不少时间关注那些鼠标路径上看不出来但做了会更好的细节——表单校验字段、加购后的轻反馈、刷新后状态保持、登录失效的感知。一个demo项目如果能把这些细节想清楚你在真实工作中写业务代码时踩坑的概率会低很多。即使是在学校交作业或培训班做项目展示这些细节也是答辩时最能拿得出手的亮点。本文还有配套的精品资源点击获取
