简介这是一份基于HTML5、CSS3与jQuery实现的静态购物网站前端源码包含登录注册、轮播图、三级菜单和购物车等常见电商模块适合前端初学者、网页设计课程学员以及需要快速搭建电商页面的开发者参考。资源共48个文件压缩包大小5.28MB其中HTML文件定义页面结构CSS文件完成布局美化与响应式适配JS文件含jQuery库、轮播脚本、三级菜单、详情页与购物车逻辑负责交互处理另配多张PNG/JPG图片素材和1个JSON文件整体可直接在浏览器中打开预览。目前已有1041人学习下载。代码注释与目录组织清晰可重点学习HTML5表单验证与本地存储、CSS3动画与Flexbox/Grid布局、jQuery事件绑定与AJAX无刷新更新等知识点购物车模块基于localStorage实现商品增删与总价计算适合作为课程设计或前端实训的参考项目也可基于它继续扩展后端接口。 做html5购物网站带登录这种练手项目我见过太多人把精力全砸在商品卡片和轮播图上最后卡在登录模块上。点登录没反应、刷新就掉线、换个浏览器账号直接消失这些问题看起来不大可一旦轮到答辩演示或者上线检查每一个都能让你当场下不来台。这篇文章我按自己做购物网站的真实流程把登录相关的页面搭建、数据校验、登录态管理、失败排查和功能扩展整体过一遍适合正在做课程设计、个人作品集以及第一次尝试前后端分离开发的同学参考。1. 为什么说登录模块才是购物网站的地基1.1 登录状态牵着一整条业务数据链购物网站表面上是商品展示实际上一旦涉及购买用户身份就成了所有业务数据的锚点。比如购物车游客往购物车加了三件商品登录后购物车还在吗要不要做合并再比如订单订单明细必须挂在用户ID下面否则用户刷新页面就找不到自己买过什么。收货地址、优惠券、收藏夹每一块都依赖一个稳定的用户标识。所以登录不是弹个框让你填账号密码那么简单它是在给整站数据建立归属关系。如果你只是做一个纯静态页面作业这个归属关系可能看不出来但只要你接上了localStorage甚至接上后端接口第一件要做的事就是确定数据归属的key。我的经验是哪怕只是练手也先设计一个简单的userId概念把所有业务数据都挂上去后面接后端的时候会轻松很多。不要把用户数据散落在各个页面模块里不然后面想统一改标识会改到怀疑人生。1.2 能跳转不等于登录成功很多同学理解的登录成功是点完登录按钮页面跳转到首页。这在纯前端demo里特别常见但实际上它只是完成了前端跳转并没有建立真正的会话状态。理想的登录流程是前端把账号密码提交给服务端服务端校验通过后发放一个凭证session或token前端保存这个凭证后续每个需要身份的请求都携带它服务端认凭证不认页面跳转。如果项目里暂时没有后端至少也应该在本地保存一个已登录状态并在页面刷新后重新读取。最怕的就是把登录状态存在某个全局变量里一刷新页面就回到未登录状态。这个问题的本质是搞不清状态应该存在哪里我在第4部分会专门讲localStorage和token的演进路径那里会把这句话展开。1.3 动手之前先判断你做的到底是Demo还是带后端项目开始写代码之前先想清楚这个购物网站最终以什么形态交付因为这会直接决定登录模块的写法。第一种是纯前端demo用于课程作业或作品集展示。这种方案可以用localStorage模拟用户库登录注册都能正常演示数据刷新不丢但换浏览器、换设备就没了属于过程正确结果本地化。第二种是前后端分离项目有Node、PHP或Python任意一个后端。这种就要走真实的用户表和身份凭证JWT或session二选一。第三种是接第三方BaaS服务比如云开发、Firebase这类登录可以大幅简化直接调SDK就好。我的建议是第一次做先按纯前端方案把页面、校验、状态管理、退出登录整条链路跑通再花一两天切换到JWT方案。两次迭代下来你才能真正理解登录模块的难点不在页面而在状态和凭证。2. 用HTML5语义化标签搭登录/注册页表单结构的取舍2.1 登录和注册放一起还是分开常见的有两种做法一种是左右两个Tab点击切换登录/注册表单另一种是独立两个页面。我推荐在购物网站里用Tab切换方式因为用户的使用心理是我要么登录要么注册不想来回跳页面。操作上同一个容器里放两个form用CSS控制显隐即可。这里有个细节容易忽略切换Tab的时候要清空另一个表单的输入内容和校验状态。不然用户A在注册表单填了一半切到登录再切回来原来填的内容还在浏览器还以为用户要提交体验会很奇怪。我最初做的时候没管这个测试时连续切换了几次发现两个表单的校验值串了排查了半天。2.2 字段设计遵循最少够用原则登录表单只需要用户名或者手机号加密码最多再加一个忘记密码入口。注册表单也别一上来就要求填十几项资料。购物网站的注册核心就是账号 密码 确认密码最多加一个验证码其他资料留到个人中心再补。字段越多用户流失越严重这个结论在真实业务里已经被反复验证过。我见过一些课程作业把注册表单设计成三四列的大表格姓名、性别、生日、地址、兴趣爱好全都要填这种页面放到真实场景里用户大概率直接放弃。数据收集要放在用户已经产生信任之后而不是在注册环节就把人吓跑。2.3 用HTML5原生属性做第一道关卡HTML5给表单提供了很多免费能力值得充分利用。required让空表单无法提交typeemail会触发浏览器格式校验typetel在移动端能唤起数字键盘pattern可以用正则约束密码格式autocomplete配合浏览器密码管理器能省掉用户手动输入。下面是一个登录表单的示例form idloginForm label forusername用户名/手机号/label input typetext idusername nameusername required autocompleteusername placeholder请输入用户名或手机号 label forpassword密码/label input typepassword idpassword namepassword required minlength8 maxlength20 autocompletecurrent-password placeholder8-20位包含字母和数字 button typesubmit登 录/button /form这里没有堆一堆自定义校验因为原生属性已经挡掉了大部分非法输入。剩余的前端加强校验比如密码必须同时包含字母和数字放到JS里处理并给出明确的错误提示。等用户把所有原生校验都过了再触发表单的submit事件。2.4 响应式和无障碍容易被忽视但很加分的点登录页通常作为单独页面或弹窗出现。在移动端输入框的font-size要大于16px否则iOS会自动唤起页面缩放用户填到一半页面突然放大体验很不舒服。表单控件的点击区域也不宜小于44px这是手指触控的舒适范围。用label的for属性关联输入框点击文字即可聚焦这既是可用性优化也是无障碍的基本要求。如果登录框是弹窗形态还需要处理Escape键关闭和背景点击关闭避免用户被卡在弹窗里出不去。这些细节不会直接写进功能清单但演示的时候别人会用手指去点、会按键盘体验好坏一下子就分出来了。3. 密码处理与前端校验从正则规则到不可逆存储3.1 密码规则怎么定才不劝退用户密码规则的本质是安全与易用的平衡。我自己做项目总结的一套规则是长度8-20位至少包含字母和数字允许特殊字符。错误提示必须具体比如密码至少8位密码需包含数字而不是笼统的密码格式不正确。用户看到具体的提示才知道怎么改抽象的提示只会让人反复试错然后放弃。JS端可以在失焦时用正则做校验这样用户不用等表单提交才知道错const passwordInput document.getElementById(password); passwordInput.addEventListener(blur, () { const value passwordInput.value; if (value.length 8 || value.length 20) { showError(密码长度需在8到20位之间); } else if (!/[A-Za-z]/.test(value) || !/\d/.test(value)) { showError(密码需同时包含字母和数字); } else { clearError(); } });注意这里的正则校验只是提升用户体验不能作为安全边界。真正安全的校验发生在服务端前端校验只是让用户早点发现问题。3.2 前端加密的认知误区很多人习惯在前端对密码做MD5再提交以为这就是加密。实际上MD5和SHA1这类哈希算法速度极快在GPU算力面前破起来跟吃豆子一样作为密码存储方案早就不够看了。真正合理的做法是服务端用bcrypt或argon2这一类带盐的慢哈希算法。前端能做的是在HTTPS传输下提交密码明文由服务端完成哈希。如果非要前端先做一次hash那只是防止密码明文出现在后端访问日志里完全不能替代服务端的加盐哈希。很多教程为了演示方便列出的前端哈希代码并不适合生产环境看的时候要心里有数。3.3 纯前端项目的密码存储替代方案如果只是做一个课程作业或个人作品集没有后端但你不想让用户密码裸奔可以把用户信息存进localStorage但密码绝不能存明文。浏览器提供了crypto.subtle.digest可以做一次SHA-256哈希再把哈希后的字符串连同用户名一起存。示例逻辑async function hashPassword(password) { const encoder new TextEncoder(); const data encoder.encode(password); const digest await crypto.subtle.digest(SHA-256, data); return Array.from(new Uint8Array(digest)) .map(b b.toString(16).padStart(2, 0)) .join(); } // 注册时const hashed await hashPassword(password); // 登录时比对输入的哈希值和存储的哈希值这个方案依然不具备真正的安全性因为懂技术的人打开DevTools就能看到源码和存储结构但它已经能证明你理解密码不能明文存储这个原则放在作业和演示场景里是加分项。真要上线必须替换成服务端加盐哈希这一点没有商量余地。4. 从本地存储到JWT登录态管理的完整演进4.1 第一阶段用localStorage模拟登录态纯前端方案里注册时写入用户数据登录时比对输入和存储的数据。比对通过后在localStorage里写入一个标记比如loginState { userId: xxx, loginAt: Date.now() }。所有页面在加载时读取这个标记决定显示欢迎你xxx还是登录按钮。这一步的关键在于登录状态必须持久化不能只存在于JS变量里。很多demo刷新后登录状态消失就是因为状态被放在全局变量里页面一刷新变量就重置了。localStorage和sessionStorage的区别也要搞清楚localStorage不设过期时间关浏览器再开还在sessionStorage在标签页关闭后清除。对购物网站来说用户一般希望下次打开还在登录状态所以用localStorage更合适但要同时提供退出登录的按钮让用户主动清除。4.2 第二阶段接入JWT做真正的登录校验当你有后端接口时推荐用JWTJSON Web Token做身份凭证。整个交互流程是前端提交用户名和密码到/api/login后端校验通过后签发一个JWT返回给前端前端把它存到localStorage或内存加refreshToken的组合方案后续请求在Authorization: Bearer token请求头中携带它后端验证token有效后返回业务数据JWT由Header、Payload、Signature三部分组成Signature部分由服务端密钥签名所以用户不能伪造。常见的错误有两个一个是不加过期时间导致token永久有效用户账号被盗后长期处于风险中另一个是把密码、身份证号这类敏感信息放进PayloadJWT的Payload只是Base64编码并不是加密任何人把token拿去解码就能看到内容。Payload里只放用户ID、昵称这种非敏感信息。4.3 过期、刷新与登录失效的处理几乎每个用过JWT的人都会遇到token过期。token里应该有一个exp声明前端可以用下面这段逻辑读取过期时间但这只用于展示真正校验还是以后端为准function parseToken(token) { const payload token.split(.)[1]; return JSON.parse(atob(payload.replace(/-/g, ).replace(/_/g, /))); }生产中更合理的做法是accessToken短过期比如30分钟配合refreshToken长过期比如7天。accessToken用于请求refreshToken用于无感续期。对购物网站来说用户在购物车里挑了半天结果付款时被强制踢回登录页体验非常糟糕。就算不做refreshToken机制至少要保证重新登录后还能回到原来的页面即在跳转登录页之前把当前URL记下来登录成功后再跳回去。5. 登录失败排查与防坑真实项目里最容易翻车的细节5.1 高频登录失败原因清单登录失败的原因五花八门但高频问题其实非常集中。我把平时排查的经验整理成一张表现象常见原因处理方式登录按钮点击无反应form默认提交导致刷新或JS报错中断在submit回调里执行preventDefault打开控制台看报错请求返回401token缺失或过期检查Authorization请求头确认token过期时间按过期流程处理后端能调通但前端拿不到响应跨域CORS后端配置CORS中间件开启credentials选项刷新后登录态丢失状态只存在内存变量改用localStorage存储页面加载时重新读取密码含特殊字符导致登录失败未编码或后端解析错误使用application/json让后端按JSON解析避免表单编码问题5.2 一次典型的登录报错排查链路我自己的项目里出现过注册成功但登录永远失败的问题。当时第一反应是打开控制台发现登录请求返回了200但后端日志里显示查不到这个用户。继续查看请求体发现密码字段名是pwd而注册时存的是password字段名不一致导致登录查询条件为空后端自然查不到人。这种错误在前后端联调时特别常见而且往往要到真实对接时才会暴露。排查的顺序建议是先看请求有没有发出、再看请求参数和后端预期是否一致、再看后端返回了什么、最后看登录状态有没有正确存储。按这个链路一步步来90%的问题都能在五分钟内定位。5.3 安全退出与购物车合并退出登录不是删掉前端token就完事。如果是纯前端方案需要清除本地登录状态回到未登录页面如果接了后端最好调用/api/logout让服务端把refreshToken拉黑。用localStorage.removeItem和sessionStorage.clear()要一起处理避免下次打开页面时残留旧状态。购物网站还有一个经常被忽略的细节游客购物车和登录后购物车的合并。用户在未登录状态下加了几件商品登录后购物车应该把本地临时数据和账号下的数据合并起来而不是直接清空否则用户会觉得我刚加的东西怎么不见了。这个逻辑建议在登录成功后触发一次合并在作业里把这个点做出来比多做两个花哨页面更能体现你对业务的理解。6. 进阶方向扫码登录、短信验证码和第三方一键登录怎么选6.1 扫码登录的本质是客户端授权扫码登录更适用于有配套APP或小程序的场景。用户在PC端看到一个二维码二维码里承载的是一个临时会话ID手机端扫码后确认授权PC端通过轮询或WebSocket不断问后端这个临时会话有没有被确认确认后就下发token。所以扫码登录的前端部分并不复杂难点在后端维护临时会话状态、二维码过期处理以及防止同一二维码被重复扫描。如果你在课程设计里想做一个扫码登录但还没有APP可以用小程序配合测试账号来做或者退一步做二维码加验证码的替代方案。不要为了炫技硬塞一个扫码登录进去如果没有真实的APP配合演示效果反而很尴尬。6.2 第三方一键登录的操作前提与流程第三方一键登录常见的有微信、QQ、GitHub、Google这类流程基本都是OAuth2授权码模式的变体先到对应开放平台注册应用拿到clientId和clientSecret并配置回调地址前端发起授权跳转用户同意后平台回调携带授权码后端用授权码换取accessToken再换取用户基础信息后端根据第三方唯一ID查找或创建本地用户最后签发自己的登录token这里有两个容易踩的坑。一是回调地址必须在开放平台登记过本地开发时经常要配127.0.0.1而且不能和localhost混着用有时明明看着是同一个地址就是回调失败其实是端口或者路径大小写不一致。二是不要依赖第三方返回的头像和昵称作为关键业务字段第三方平台随时可能因为隐私政策调整导致这些字段拿不到代码里要做空值兜底。6.3 小型项目的合理选型建议如果你是练手项目我建议优先选支持测试模式或沙箱的第三方平台这样可以省掉买短信服务的费用。短信验证码虽然体验好但要买短信服务还要处理发送频率限制、图形验证码防刷这些问题对初学者来说成本偏高。核心原则是登录方式不是越多越好而是要和你手头的资源匹配。课程作业里把账号密码登录做好、做得完整再配一个第三方登录已经足够展示能力了。省下来的时间多打磨购物车和结算流程反而更能让评委或者面试官眼前一亮。我在做购物网站练手项目的过程中最大的感受是登录模块看起来是个入口实际上是整个项目里业务逻辑密度最高的部分之一。你把它当成一个表单来写它就会用刷新丢状态、字段不一致、token过期这些方式给你上眼药你把它当成一套完整的身份与状态管理流程来做从页面、校验到凭证管理都理清楚了整站都会顺很多。希望这篇文章能帮你少踩几个我当年踩过的坑。本文还有配套的精品资源点击获取 HTML5购物网站登录模块开发指南：从表单校验到JWT登录态管理
简介这是一份基于HTML5、CSS3与jQuery实现的静态购物网站前端源码包含登录注册、轮播图、三级菜单和购物车等常见电商模块适合前端初学者、网页设计课程学员以及需要快速搭建电商页面的开发者参考。资源共48个文件压缩包大小5.28MB其中HTML文件定义页面结构CSS文件完成布局美化与响应式适配JS文件含jQuery库、轮播脚本、三级菜单、详情页与购物车逻辑负责交互处理另配多张PNG/JPG图片素材和1个JSON文件整体可直接在浏览器中打开预览。目前已有1041人学习下载。代码注释与目录组织清晰可重点学习HTML5表单验证与本地存储、CSS3动画与Flexbox/Grid布局、jQuery事件绑定与AJAX无刷新更新等知识点购物车模块基于localStorage实现商品增删与总价计算适合作为课程设计或前端实训的参考项目也可基于它继续扩展后端接口。 做html5购物网站带登录这种练手项目我见过太多人把精力全砸在商品卡片和轮播图上最后卡在登录模块上。点登录没反应、刷新就掉线、换个浏览器账号直接消失这些问题看起来不大可一旦轮到答辩演示或者上线检查每一个都能让你当场下不来台。这篇文章我按自己做购物网站的真实流程把登录相关的页面搭建、数据校验、登录态管理、失败排查和功能扩展整体过一遍适合正在做课程设计、个人作品集以及第一次尝试前后端分离开发的同学参考。1. 为什么说登录模块才是购物网站的地基1.1 登录状态牵着一整条业务数据链购物网站表面上是商品展示实际上一旦涉及购买用户身份就成了所有业务数据的锚点。比如购物车游客往购物车加了三件商品登录后购物车还在吗要不要做合并再比如订单订单明细必须挂在用户ID下面否则用户刷新页面就找不到自己买过什么。收货地址、优惠券、收藏夹每一块都依赖一个稳定的用户标识。所以登录不是弹个框让你填账号密码那么简单它是在给整站数据建立归属关系。如果你只是做一个纯静态页面作业这个归属关系可能看不出来但只要你接上了localStorage甚至接上后端接口第一件要做的事就是确定数据归属的key。我的经验是哪怕只是练手也先设计一个简单的userId概念把所有业务数据都挂上去后面接后端的时候会轻松很多。不要把用户数据散落在各个页面模块里不然后面想统一改标识会改到怀疑人生。1.2 能跳转不等于登录成功很多同学理解的登录成功是点完登录按钮页面跳转到首页。这在纯前端demo里特别常见但实际上它只是完成了前端跳转并没有建立真正的会话状态。理想的登录流程是前端把账号密码提交给服务端服务端校验通过后发放一个凭证session或token前端保存这个凭证后续每个需要身份的请求都携带它服务端认凭证不认页面跳转。如果项目里暂时没有后端至少也应该在本地保存一个已登录状态并在页面刷新后重新读取。最怕的就是把登录状态存在某个全局变量里一刷新页面就回到未登录状态。这个问题的本质是搞不清状态应该存在哪里我在第4部分会专门讲localStorage和token的演进路径那里会把这句话展开。1.3 动手之前先判断你做的到底是Demo还是带后端项目开始写代码之前先想清楚这个购物网站最终以什么形态交付因为这会直接决定登录模块的写法。第一种是纯前端demo用于课程作业或作品集展示。这种方案可以用localStorage模拟用户库登录注册都能正常演示数据刷新不丢但换浏览器、换设备就没了属于过程正确结果本地化。第二种是前后端分离项目有Node、PHP或Python任意一个后端。这种就要走真实的用户表和身份凭证JWT或session二选一。第三种是接第三方BaaS服务比如云开发、Firebase这类登录可以大幅简化直接调SDK就好。我的建议是第一次做先按纯前端方案把页面、校验、状态管理、退出登录整条链路跑通再花一两天切换到JWT方案。两次迭代下来你才能真正理解登录模块的难点不在页面而在状态和凭证。2. 用HTML5语义化标签搭登录/注册页表单结构的取舍2.1 登录和注册放一起还是分开常见的有两种做法一种是左右两个Tab点击切换登录/注册表单另一种是独立两个页面。我推荐在购物网站里用Tab切换方式因为用户的使用心理是我要么登录要么注册不想来回跳页面。操作上同一个容器里放两个form用CSS控制显隐即可。这里有个细节容易忽略切换Tab的时候要清空另一个表单的输入内容和校验状态。不然用户A在注册表单填了一半切到登录再切回来原来填的内容还在浏览器还以为用户要提交体验会很奇怪。我最初做的时候没管这个测试时连续切换了几次发现两个表单的校验值串了排查了半天。2.2 字段设计遵循最少够用原则登录表单只需要用户名或者手机号加密码最多再加一个忘记密码入口。注册表单也别一上来就要求填十几项资料。购物网站的注册核心就是账号 密码 确认密码最多加一个验证码其他资料留到个人中心再补。字段越多用户流失越严重这个结论在真实业务里已经被反复验证过。我见过一些课程作业把注册表单设计成三四列的大表格姓名、性别、生日、地址、兴趣爱好全都要填这种页面放到真实场景里用户大概率直接放弃。数据收集要放在用户已经产生信任之后而不是在注册环节就把人吓跑。2.3 用HTML5原生属性做第一道关卡HTML5给表单提供了很多免费能力值得充分利用。required让空表单无法提交typeemail会触发浏览器格式校验typetel在移动端能唤起数字键盘pattern可以用正则约束密码格式autocomplete配合浏览器密码管理器能省掉用户手动输入。下面是一个登录表单的示例form idloginForm label forusername用户名/手机号/label input typetext idusername nameusername required autocompleteusername placeholder请输入用户名或手机号 label forpassword密码/label input typepassword idpassword namepassword required minlength8 maxlength20 autocompletecurrent-password placeholder8-20位包含字母和数字 button typesubmit登 录/button /form这里没有堆一堆自定义校验因为原生属性已经挡掉了大部分非法输入。剩余的前端加强校验比如密码必须同时包含字母和数字放到JS里处理并给出明确的错误提示。等用户把所有原生校验都过了再触发表单的submit事件。2.4 响应式和无障碍容易被忽视但很加分的点登录页通常作为单独页面或弹窗出现。在移动端输入框的font-size要大于16px否则iOS会自动唤起页面缩放用户填到一半页面突然放大体验很不舒服。表单控件的点击区域也不宜小于44px这是手指触控的舒适范围。用label的for属性关联输入框点击文字即可聚焦这既是可用性优化也是无障碍的基本要求。如果登录框是弹窗形态还需要处理Escape键关闭和背景点击关闭避免用户被卡在弹窗里出不去。这些细节不会直接写进功能清单但演示的时候别人会用手指去点、会按键盘体验好坏一下子就分出来了。3. 密码处理与前端校验从正则规则到不可逆存储3.1 密码规则怎么定才不劝退用户密码规则的本质是安全与易用的平衡。我自己做项目总结的一套规则是长度8-20位至少包含字母和数字允许特殊字符。错误提示必须具体比如密码至少8位密码需包含数字而不是笼统的密码格式不正确。用户看到具体的提示才知道怎么改抽象的提示只会让人反复试错然后放弃。JS端可以在失焦时用正则做校验这样用户不用等表单提交才知道错const passwordInput document.getElementById(password); passwordInput.addEventListener(blur, () { const value passwordInput.value; if (value.length 8 || value.length 20) { showError(密码长度需在8到20位之间); } else if (!/[A-Za-z]/.test(value) || !/\d/.test(value)) { showError(密码需同时包含字母和数字); } else { clearError(); } });注意这里的正则校验只是提升用户体验不能作为安全边界。真正安全的校验发生在服务端前端校验只是让用户早点发现问题。3.2 前端加密的认知误区很多人习惯在前端对密码做MD5再提交以为这就是加密。实际上MD5和SHA1这类哈希算法速度极快在GPU算力面前破起来跟吃豆子一样作为密码存储方案早就不够看了。真正合理的做法是服务端用bcrypt或argon2这一类带盐的慢哈希算法。前端能做的是在HTTPS传输下提交密码明文由服务端完成哈希。如果非要前端先做一次hash那只是防止密码明文出现在后端访问日志里完全不能替代服务端的加盐哈希。很多教程为了演示方便列出的前端哈希代码并不适合生产环境看的时候要心里有数。3.3 纯前端项目的密码存储替代方案如果只是做一个课程作业或个人作品集没有后端但你不想让用户密码裸奔可以把用户信息存进localStorage但密码绝不能存明文。浏览器提供了crypto.subtle.digest可以做一次SHA-256哈希再把哈希后的字符串连同用户名一起存。示例逻辑async function hashPassword(password) { const encoder new TextEncoder(); const data encoder.encode(password); const digest await crypto.subtle.digest(SHA-256, data); return Array.from(new Uint8Array(digest)) .map(b b.toString(16).padStart(2, 0)) .join(); } // 注册时const hashed await hashPassword(password); // 登录时比对输入的哈希值和存储的哈希值这个方案依然不具备真正的安全性因为懂技术的人打开DevTools就能看到源码和存储结构但它已经能证明你理解密码不能明文存储这个原则放在作业和演示场景里是加分项。真要上线必须替换成服务端加盐哈希这一点没有商量余地。4. 从本地存储到JWT登录态管理的完整演进4.1 第一阶段用localStorage模拟登录态纯前端方案里注册时写入用户数据登录时比对输入和存储的数据。比对通过后在localStorage里写入一个标记比如loginState { userId: xxx, loginAt: Date.now() }。所有页面在加载时读取这个标记决定显示欢迎你xxx还是登录按钮。这一步的关键在于登录状态必须持久化不能只存在于JS变量里。很多demo刷新后登录状态消失就是因为状态被放在全局变量里页面一刷新变量就重置了。localStorage和sessionStorage的区别也要搞清楚localStorage不设过期时间关浏览器再开还在sessionStorage在标签页关闭后清除。对购物网站来说用户一般希望下次打开还在登录状态所以用localStorage更合适但要同时提供退出登录的按钮让用户主动清除。4.2 第二阶段接入JWT做真正的登录校验当你有后端接口时推荐用JWTJSON Web Token做身份凭证。整个交互流程是前端提交用户名和密码到/api/login后端校验通过后签发一个JWT返回给前端前端把它存到localStorage或内存加refreshToken的组合方案后续请求在Authorization: Bearer token请求头中携带它后端验证token有效后返回业务数据JWT由Header、Payload、Signature三部分组成Signature部分由服务端密钥签名所以用户不能伪造。常见的错误有两个一个是不加过期时间导致token永久有效用户账号被盗后长期处于风险中另一个是把密码、身份证号这类敏感信息放进PayloadJWT的Payload只是Base64编码并不是加密任何人把token拿去解码就能看到内容。Payload里只放用户ID、昵称这种非敏感信息。4.3 过期、刷新与登录失效的处理几乎每个用过JWT的人都会遇到token过期。token里应该有一个exp声明前端可以用下面这段逻辑读取过期时间但这只用于展示真正校验还是以后端为准function parseToken(token) { const payload token.split(.)[1]; return JSON.parse(atob(payload.replace(/-/g, ).replace(/_/g, /))); }生产中更合理的做法是accessToken短过期比如30分钟配合refreshToken长过期比如7天。accessToken用于请求refreshToken用于无感续期。对购物网站来说用户在购物车里挑了半天结果付款时被强制踢回登录页体验非常糟糕。就算不做refreshToken机制至少要保证重新登录后还能回到原来的页面即在跳转登录页之前把当前URL记下来登录成功后再跳回去。5. 登录失败排查与防坑真实项目里最容易翻车的细节5.1 高频登录失败原因清单登录失败的原因五花八门但高频问题其实非常集中。我把平时排查的经验整理成一张表现象常见原因处理方式登录按钮点击无反应form默认提交导致刷新或JS报错中断在submit回调里执行preventDefault打开控制台看报错请求返回401token缺失或过期检查Authorization请求头确认token过期时间按过期流程处理后端能调通但前端拿不到响应跨域CORS后端配置CORS中间件开启credentials选项刷新后登录态丢失状态只存在内存变量改用localStorage存储页面加载时重新读取密码含特殊字符导致登录失败未编码或后端解析错误使用application/json让后端按JSON解析避免表单编码问题5.2 一次典型的登录报错排查链路我自己的项目里出现过注册成功但登录永远失败的问题。当时第一反应是打开控制台发现登录请求返回了200但后端日志里显示查不到这个用户。继续查看请求体发现密码字段名是pwd而注册时存的是password字段名不一致导致登录查询条件为空后端自然查不到人。这种错误在前后端联调时特别常见而且往往要到真实对接时才会暴露。排查的顺序建议是先看请求有没有发出、再看请求参数和后端预期是否一致、再看后端返回了什么、最后看登录状态有没有正确存储。按这个链路一步步来90%的问题都能在五分钟内定位。5.3 安全退出与购物车合并退出登录不是删掉前端token就完事。如果是纯前端方案需要清除本地登录状态回到未登录页面如果接了后端最好调用/api/logout让服务端把refreshToken拉黑。用localStorage.removeItem和sessionStorage.clear()要一起处理避免下次打开页面时残留旧状态。购物网站还有一个经常被忽略的细节游客购物车和登录后购物车的合并。用户在未登录状态下加了几件商品登录后购物车应该把本地临时数据和账号下的数据合并起来而不是直接清空否则用户会觉得我刚加的东西怎么不见了。这个逻辑建议在登录成功后触发一次合并在作业里把这个点做出来比多做两个花哨页面更能体现你对业务的理解。6. 进阶方向扫码登录、短信验证码和第三方一键登录怎么选6.1 扫码登录的本质是客户端授权扫码登录更适用于有配套APP或小程序的场景。用户在PC端看到一个二维码二维码里承载的是一个临时会话ID手机端扫码后确认授权PC端通过轮询或WebSocket不断问后端这个临时会话有没有被确认确认后就下发token。所以扫码登录的前端部分并不复杂难点在后端维护临时会话状态、二维码过期处理以及防止同一二维码被重复扫描。如果你在课程设计里想做一个扫码登录但还没有APP可以用小程序配合测试账号来做或者退一步做二维码加验证码的替代方案。不要为了炫技硬塞一个扫码登录进去如果没有真实的APP配合演示效果反而很尴尬。6.2 第三方一键登录的操作前提与流程第三方一键登录常见的有微信、QQ、GitHub、Google这类流程基本都是OAuth2授权码模式的变体先到对应开放平台注册应用拿到clientId和clientSecret并配置回调地址前端发起授权跳转用户同意后平台回调携带授权码后端用授权码换取accessToken再换取用户基础信息后端根据第三方唯一ID查找或创建本地用户最后签发自己的登录token这里有两个容易踩的坑。一是回调地址必须在开放平台登记过本地开发时经常要配127.0.0.1而且不能和localhost混着用有时明明看着是同一个地址就是回调失败其实是端口或者路径大小写不一致。二是不要依赖第三方返回的头像和昵称作为关键业务字段第三方平台随时可能因为隐私政策调整导致这些字段拿不到代码里要做空值兜底。6.3 小型项目的合理选型建议如果你是练手项目我建议优先选支持测试模式或沙箱的第三方平台这样可以省掉买短信服务的费用。短信验证码虽然体验好但要买短信服务还要处理发送频率限制、图形验证码防刷这些问题对初学者来说成本偏高。核心原则是登录方式不是越多越好而是要和你手头的资源匹配。课程作业里把账号密码登录做好、做得完整再配一个第三方登录已经足够展示能力了。省下来的时间多打磨购物车和结算流程反而更能让评委或者面试官眼前一亮。我在做购物网站练手项目的过程中最大的感受是登录模块看起来是个入口实际上是整个项目里业务逻辑密度最高的部分之一。你把它当成一个表单来写它就会用刷新丢状态、字段不一致、token过期这些方式给你上眼药你把它当成一套完整的身份与状态管理流程来做从页面、校验到凭证管理都理清楚了整站都会顺很多。希望这篇文章能帮你少踩几个我当年踩过的坑。本文还有配套的精品资源点击获取