直接上结论：如果你是正在做Java方向毕设、或者想快速搞一个前后端分离商城练手接单的人，这套“基于Springboot+Vue的数码产品购物商城”属于非常典型、又特别实用的一类项目。它不搞花哨的微服务、不强行上分布式中间件，就是老老实实地把电商最核心的几条链路——商品浏览、用户登录、购物车、订单结算、后台管理——用主流技术栈做完整，还附带源码、论文（lw是“论文”的拼音缩写）、部署文档和讲解视频。我前段时间正好完整复现并部署过同类项目，把整个设计思路、核心代码细节、部署踩坑过程都捋了一遍，这篇就把最有价值的经验写透，给需要的人省时间。
1. 项目整体设计与技术选型逻辑
1.1 为什么是SpringBoot+Vue，而不是别的
先说大家最关心的选型问题。很多人在搭建电商项目时第一反应是“上Spring Cloud”“用微服务”“搞Redis集群”，但放到课设、毕设、外包交付这类场景里，这些其实是给自己挖坑。单体应用加上前后端分离，这个组合是性价比最高的方案，没有之一。
后端用SpringBoot，核心原因有三点。第一，内置Tomcat，war包和jar包都能跑，部署时一个java -jar命令就完事，对写论文和录部署视频的人来说非常友好。第二，生态太成熟，MyBatis-Plus做持久层、Spring Security或JWT做鉴权、Hutool做工具类，几乎都能找到现成封装，开发效率极高。第三，也是最实际的：市面上的参考代码、博客教程、答辩问题集几乎都围绕SpringBoot展开，你遇到任何坑都能快速查到解决方案。
前端选Vue，是因为它相比传统JSP、FreeMarker模板渲染，能真正实现前后端并行开发。商城这种页面交互密度高的项目，用Vue的响应式和组件化开发体验很舒服——商品列表、购物车角标、状态切换这些交互，在Vue里都是数据驱动，不需要手动操作DOM。Vue相比React学习曲线更平缓，对国内学生来说资料也更全，中文社区活跃度高，遇到问题搜一下就有答案。如果你的Node环境装的是Vue CLI或者Vite，创建项目、跑开发服务器都顺手很多。
有人可能纠结：用Vue 2还是Vue 3？我的建议是看交付要求。如果论文里参考资料较多、教程大多是Vue 2写法，或者依赖组件库（比如Element UI）更稳，用Vue 2完全没问题。如果是从零开始学、想兼顾以后工作使用，直接Vue 3加Pinia加Element Plus。这俩在商城这个体量下性能差异感知不出来，关键是选一个你熟练的。
1.2 数码产品商城的特性决定了功能边界
既然定位是数码产品购物商城，商品类型就决定了功能设计要求。数码产品有几个显著特点：一是SKU属性多，比如手机有颜色、内存版本、套餐类型；二是价格较高，用户下单决策周期长，购物车和收藏功能必须好用；三是商品信息展示要求细致，参数规格（CPU、屏幕、电池、摄像头）需要专门的结构来承载。
所以，紧贴数码产品这个场景，核心功能应该这样划分。
用户端：
- 商品浏览：首页轮播图推荐、商品分类导航、商品搜索、商品详情参数展示。
- 购物车：加入购物车、修改数量、删除、选中结算。
- 订单：订单确认页（收货地址、商品清单、金额明细）、下单、支付模拟（没有真实支付通道，一般用“余额支付”或“模拟支付”代替）、订单列表、订单详情、取消订单。
- 个人中心：注册登录、收货地址管理（增删改查、设置默认地址）、修改个人信息。
管理端：
- 商品管理：商品的增删改查、上下架、库存修改、商品图片上传。
- 分类管理：一级/二级分类维护。
- 订单管理：订单列表、发货（修改订单状态）、查看订单详情、退款处理。
- 用户管理：用户列表、启用禁用账号。
- 数据统计（可选）：简单的用户数、订单数、销售额展示。
这里有一个容易犯的错误，就是“我想做得更多”，然后加了一堆用不上的功能。比如秒杀、优惠券、积分商城、直播带货。这些功能并不是不能做，而是每一块都会带来额外的数据表设计、接口开发、前端页面和答辩讲解成本。设计阶段就应该克制，把主链路打磨完整，比堆砌一堆残缺模块更能在答辩时加分。
1.3 数据库设计的核心思路
商城类项目的数据表设计，有一个经典的心智模型：一切围绕“订单”转。用户下单，订单里有商品快照（下单时商品名称、价格、缩略图，防止商品之后改价影响历史订单），订单由多条订单明细组成。这决定了表结构必须以订单和订单项为核心展开。
具体的表设计建议如下：
user用户表：id、用户名、密码（MD5或BCrypt加密存储）、昵称、头像、手机号、邮箱、注册时间、状态。category分类表：id、父级id、名称、排序、图标。用父级id实现二级分类，比如“手机数码”下面是“手机”“耳机”“充电器”。product商品表：id、分类id、名称、主图、轮播图（可存多个路径，用逗号分隔）、价格、原价、库存、销量、商品详情富文本、状态（上架/下架）、创建时间。product_param或直接在product表加字段：数码产品需要展示参数，我建议单独建一张product_param表，字段用通用做法，参数名和参数值成对存储，或者在product_detail中存富文本。学生项目更常用后者，简单直接。cart购物车表：id、用户id、商品id、商品数量、选中状态、加入时间。也可以不加购物车表，用Redis的Hash存储，Redis挂掉就麻烦，为了稳妥和好答辩，建议用MySQL表。order订单表：id、订单编号、用户id、收货人姓名、手机号、地址、订单金额、实际支付金额、订单状态（待付款、待发货、待收货、已完成、已取消）、创建时间、支付时间。order_item订单明细表：id、订单id、商品id、商品名称、商品图片、商品单价、购买数量、小计金额。address收货地址表：id、用户id、收货人、手机号、省市区、详细地址、是否默认。banner轮播图表：id、图片路径、跳转链接、排序。
订单编号生成需要注意。不要用自增id直接暴露给用户，也不要每次查库生成，常见做法是“时间戳+随机数”或“时间戳+用户id尾号”，保证唯一性即可。生成的编号要适合打印在订单详情页和快递面单上，位数控制在16-20位比较合适。
2. 核心功能模块与接口设计详解
2.1 登录鉴权：JWT方案落地
商城项目登录鉴权，最主流也最方便答辩解释的方案是JWT（JSON Web Token）。原理不复杂：用户登录成功后，后端签发一个token返回给前端，前端存在localStorage里，之后每次请求在请求头带Authorization: Bearer token，后端通过拦截器或过滤器校验token，解析出用户信息。
具体实现里，我建议在pom.xml引入jjwt依赖。然后写一个JwtUtils工具类，里面放三个方法：生成token、解析token、校验token是否过期。生成时把用户id和用户名放进去，设置过期时间（商城场景建议2小时，太短要频繁登录，太长不安全）。拦截器实现HandlerInterceptor接口，在preHandle里取header中的token，调用工具类校验，通过就把用户信息放入ThreadLocal，方便Service层随时获取当前用户。
一个关键设计：登录接口本身不能拦截，商品列表、商品详情、首页轮播这些“公开接口”不需要token也能访问；只有购物车、下单、订单查询这些涉及用户数据的接口才需要校验。这里需要维护一个白名单列表，避免误拦截。第一次做容易把所有接口都加上拦截导致前端一访问就报401，排查半天发现在放行配置里漏了路径。另一个容易忽略的点是：拦截器放行后，Controller里获取用户id的方式，建议用@RequestHeader传递，或者用ThreadLocal，不要每次从token里解析一遍，代码会清爽很多。
2.2 商品分页搜索与分类联动
商品模块是商城门面，接口设计直接影响前端页面好不好调。我的建议是做这4个接口就够了，不用一个接口查所有东西：
GET /product/list?pageNum=1&pageSize=8&categoryId=xx&keyword=xx——商品分页列表，支持分类筛选和关键词模糊搜索。GET /product/detail/{id}——商品详情，返回基本信息+参数详情。GET /category/tree——分类树，首页侧边栏或顶部导航用。GET /banner/list——轮播图。
分页直接用MyBatis-Plus的Page对象加QueryWrapper，代码不到10行。关键点是搜索排序的稳定性：如果按product_sales降序排列，遇到销量相同的商品，分页时会出现同一商品在不同页重复出现或漏掉的情况，解决办法是排序条件加上id desc作为次级排序，给数据库一个确定的顺序。
分类这块，建议一次性加载分类树，前端直接渲染，不要每次点击分类都调接口查分类。商品列表按分类过滤时，注意一个细节：如果你选了一级分类“手机数码”，要能把它的所有二级分类（手机、耳机、充电器）下的商品都查出来。后端处理方式是根据一级分类id查出所有子分类id列表，用in条件查询，而不是只查一级分类下直接挂载的商品。
2.3 购物车：状态设计与批量操作
购物车的实现，如果只做“增删改查”，答辩时很容易被问“那你怎么处理购物车里商品后来下架了？”为了应对这类问题，设计购物车接口时建议考虑以下状态场景：
- 加入购物车时，校验商品是否存在、是否上架、库存是否充足。
- 购物车列表返回时，关联查询商品当前的上下架状态和实时库存，前端在下架商品上打标“失效”。
- 结算时，只算选中的商品。
- 修改数量的上限不超过库存，下限为1。
购物车接口建议这样设计：
POST /cart/add——传入商品id、数量，后端校验后加入，如果已存在则数量累加。GET /cart/list——返回当前用户的购物车列表，带上商品主图、名称、单价、库存、是否失效。PUT /cart/update——更新购物车项的数量或选中状态。DELETE /cart/delete/{id}——删除单项。POST /cart/clear——清空失效商品。
实际开发中，更新数量与选中状态最好是分开的两个接口，或者用同一个接口加一个type参数区分。为什么？因为前端购物车页面的交互是“点加减号调数量”“点复选框切换选中”，每一次操作调用接口时，如果接口参数太复杂，前后端联调容易出误解。接口设计保持单一职责，前端调起来简单，后端也好写。
2.4 订单流程：事务与库存扣减
订单是商城项目里最体现功力的模块，也是答辩环节老师最爱深挖的部分。核心流程分三步：核对购物车、生成订单、扣减库存。
生成订单时，后端要做的事：
- 接收前端传来的地址id、购物车选中的商品id列表、备注。
- 校验购物车商品是否都还在售且库存足够。
- 计算订单总金额（拿数据库里的商品价格乘数量，不要信任前端传的金额）。
- 生成订单主表和订单项表，用事务包裹。
- 删除已经下单的购物车项。
- 扣减商品库存。
这里最关键的“扣减库存”有两个做法需要考虑。第一种是普通做法：UPDATE product SET stock = stock - #{num} WHERE id = #{id} AND stock >= #{num}，通过SQL层面的条件判断来防止超卖，简单可靠，学生项目足够。第二种是用乐观锁，在商品表加version字段，更新时带着version判断，失败则重试或提示。对于答辩，建议先掌握第一种，如果被追问“高并发下怎么防止超卖”，再引出第二种，这个回答层次会显得你有真思考。
订单表的状态流转必须设计清楚。我见过有些项目订单状态五花八门，把“待付款”“未支付”“已支付”混着写，后面统计一锅粥。推荐统一用数字状态码：0=待付款，1=待发货（已付款），2=待收货（已发货），3=已完成，4=已取消。状态流转规则：下单成功=0；用户付款或模拟支付后=1；管理员发货后=2；用户确认收货或自动确认=3；用户取消或管理员关闭=4。如果做退款，建议增加5=已退款，和取消分开，退款是发生在支付之后的逆向流程，语义不一样。
为了方便回答“那取消订单之后库存恢复吗”这类问题，代码里处理取消订单时，要把订单明细里的商品数量逐个回补库存。这也是一个非常容易漏掉的功能点，很多低价毕设源码里根本没有恢复库存的逻辑，属于典型的功能缺陷。要做到这才算一个完整的订单闭环。
3. 前后端关键实现与代码组织
3.1 后端工程结构：三层架构加工具层
后端工程的包结构，是阅卷老师和答辩评委第一眼看的东西，别随手乱写。我推荐一个通用的分层结构：
com.example.mall ├── common // 通用类：统一返回结果、异常处理、JWT工具、常量 ├── config // 配置类：跨域配置、拦截器注册、文件上传配置 ├── controller // 控制层：只做参数接收和结果返回 ├── entity // 数据库实体类 ├── mapper // MyBatis-Plus的Mapper接口 ├── service // 业务层接口 │ └── impl // 业务层实现 ├── vo // 视图对象：专门给前端返回的数据结构 └── utils // 工具类统一返回结果Result<T>这个类值得单独说一下。前后端对接时最怕各写各的，后端有的返回Map，有的返回裸对象，前端取数据就要写一堆判断。规范做法是统一包装成{ code: 200, message: "success", data: {} }，code为200表示成功，非200表示业务失败，data是真正的业务数据。前端封装一层Axios拦截器后，直接拿res.data.data就行，省去大量重复代码。
全局异常处理也要做。用@RestControllerAdvice配合@ExceptionHandler，把参数校验异常、业务异常、空指针异常分别捕获，返回对应的错误信息。这个类看起来不起眼，但能够防止用户看到一大段英文堆栈，同时也让代码看起来更专业。
3.2 前端工程结构：按页面组织组件
前端Vue工程的组织方式直接决定你后期改代码的效率。我见过整篇代码堆在App.vue里的项目，也见过一个页面写几千行逻辑的。虽然功能上都能跑，但可维护性很差，答辩被问模块划分时也讲不清楚。
推荐的页面结构这样区分：
views：每个页面一个目录。首页、商品列表、商品详情、购物车、订单确认、订单列表、订单详情、登录注册、个人中心、后台管理。components：公共组件。商品卡片、分页组件、数量选择器、头部导航、脚部组件、图片懒加载组件。router：前端路由配置，包含动态路由和路由守卫。store：Vuex或Pinia状态管理，存用户信息、购物车数量。api：按模块拆分的接口请求文件，比如api/product.js里放所有商品相关接口。utils：Axios封装、工具函数。
这里重点说一下Axios封装。统一在utils/request.js里创建一个Axios实例，配置baseURL、超时时间、请求拦截器（自动携带token）、响应拦截器（统一处理code：为200时返回data，为401时跳到登录页，为其他code时弹出错误提示）。这样可以避免每个页面重复写错误处理，也是前后端分离项目中比较核心的基础设施。
购物车数量做全局状态管理也是一个容易被忽略的细节。用户登录后，顶部导航栏显示购物车商品总数，添加购物车后这个数字要立即发生变化。实现方式是用Vuex/Pinia存cartCount，登录成功后调用一次购物车列表接口统计总数，加入购物车成功后this.$store.commit('updateCartCount', 新数量)。要是没有这一步，购物车角标就会傻傻不动，体验很差。
3.3 富文本与图片上传：文件存储方案
商品详情一般要支持富文本编辑器（比如wangEditor或UEditor），而富文本里不可避免要插入图片。图片上传有两种方案可选：一种是传base64字符串直接存在数据库里，简单，但数据库会非常庞大，详情页加载慢；另一种是上传到本地磁盘或云OSS，返回URL，富文本里引用URL。
对部署到云服务器或本地演示的课设项目来说，推荐存本地磁盘。具体做法是配置一个虚拟路径映射：application.yml里配置file.upload-path指向某个磁盘目录，比如D:/mall/upload/。然后在配置类里注册ResourceHandler，把/images/**映射到那个物理路径，这样访问http://你的域名:8080/images/xxx.jpg就能显示图片。
这个方案里最常见的坑是：配置了但图片不显示。排查思路很简单——先看物理路径下文件是否真实存在，再看映射路径和前端请求路径是否一致。另一个常见的坑是：本地开发用的是Windows路径，部署到Linux服务器后路径变成了/root/mall/upload/，如果代码里写死了Windows路径就完蛋。建议在application.yml里用外部配置覆盖默认路径，部署时改配置文件即可，不要改代码。
3.4 订单超时未支付：定时任务的简单实现
如果项目里希望加一个小亮点，最简单又稳妥的是加一个“超时自动取消订单”的定时任务，用Spring自带的@Scheduled就能实现。每30秒扫描一次订单表，找出创建时间超过30分钟且状态为0（待付款）的订单，把它们状态置为4（已取消），同时恢复库存，删除或失效相关的购物车记录。
为什么推荐加这个？一是实现成本极低，二是答辩时能顺势展示你对“电商订单生命周期完整性”的理解。用@Scheduled时记得在主启动类或配置类上加@EnableScheduling，否则定时任务不会生效。如果被追问“生产环境用这个方案有什么问题”，可以回答“单机定时任务够用；高并发场景会考虑延迟队列或消息中间件”，这个回答既诚实又加分。
4. 部署全流程：从源码到可访问的商城
4.1 本地开发环境搭建
部署之前，先把开发环境理清。后端需要的软件：JDK 8或11（推荐8，兼容性最好）、Maven 3.6+、MySQL 5.7或8.0（再低版本容易踩时区问题）、IDEA（社区版够用）。
前端需要的软件：Node.js 14或16（Vue 2项目建议Node 14，Vue 3项目建议Node 16+）、npm或cnpm、VS Code或WebStorm。
拿到源码的第一步，是先把数据库脚本导入MySQL。一般的源码包里会提供mall.sql，里面建库、建表、插入初始数据都写好了。用Navicat或命令行执行导入，注意导入前先核对数据库字符集是不是utf8mb4。如果源码包里没有SQL文件，要看部署文档或论文的数据库设计章节，自己手工建表加初始数据，这个工作量不小，所以拿到源码先确认带不带SQL脚本很重要。
4.2 后端配置修改与打包
后端打包前，需要改两个文件：application.yml和pom.xml。
application.yml里改四项：
datasource.url：改成你自己的数据库地址，注意加serverTimezone=Asia/Shanghai&useUnicode=true&characterEncoding=utf8。datasource.username/password：改成自己的数据库账号密码。- 文件上传路径：改成自己机器的绝对路径。
- 服务端口：默认8080，如果被占用改成其他端口。
pom.xml里要注意的是打包插件。SpringBoot项目里如果配置了spring-boot-maven-plugin，在打包时需要配置mainClass，否则打出来的jar可能启动时报“没有主清单属性”。如果用了MyBatis-Plus的代码生成器或分页插件，记得确认依赖版本兼容，常见的坑是MyBatis-Plus 3.4和3.5的API有差异，代码从网上复制时容易混淆。
打包命令很简单：mvn clean package -DskipTests。skipTests一定要加，因为很多课设项目里的测试代码可能依赖本地环境，跑测试大概率失败，卡半天结果发现只是测试用例路径写错了。打包完成后，target目录下会生成mall-0.0.1-SNAPSHOT.jar，这就是可运行的后端包。
启动有两种方式。开发阶段直接在IDEA里点运行按钮更方便调试；部署到服务器用java -jar mall.jar即可。建议在服务器上使用nohup java -jar mall.jar > mall.log 2>&1 &方式后台启动，并把日志重定向到文件，方便排查问题。第一次启动后观察mall.log，看到“Started Application in xx seconds”就说明启动成功，然后浏览器访问http://localhost:8080/api/product/list测试接口是否通。
4.3 前端构建与Nginx部署
前端部署流程不复杂，但细节比较多。先在源码前端目录下执行npm install安装依赖。这里有个常见问题：有些源码的package.json里依赖版本很旧，用最新Node安装会报错，建议按部署文档指定的Node版本安装。如果npm下载慢，可以临时切换为官方镜像源安装依赖。
依赖装完后，改vue.config.js或.env文件里的接口地址。开发环境一般配置成http://localhost:8080，部署时改成http://你的服务器IP:8080。一定要记得这里不是在拦截器里改，不同项目的配置方式不一样，有的在utils/request.js里写死，有的在.env.production里配置环境变量，改之前先看一下源码结构。
然后执行npm run build，生成dist目录。这个目录里是纯静态文件，可以扔到Nginx的html目录下。最推荐的做法是使用Nginx托管的方案，官方给过标准配置模板，把dist里的文件放到Nginx的/usr/share/nginx/html目录下，并做如下配置：
server { listen 80; server_name 你的域名或IP; # 前端静态资源 location / { root /usr/share/nginx/html; index index.html; try_files $uri $uri/ /index.html; } # 后端接口反向代理 location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }这个配置里最关键的是try_files $uri $uri/ /index.html;这行。因为前端路由用的history模式，用户如果在购物车页面按F5刷新，浏览器会请求/cart这个路径，但静态目录下根本没有这个文件，不加这行Nginx就返回404。加了这行后，所有未知路径都回退到index.html，由前端路由接管，刷新就正常了。这是前后端分离部署最经典的一个坑，很多人在这一步卡到怀疑人生。
4.4 部署文档与演示视频的配套准备
如果是作为课设或毕设交付，部署文档和讲解视频跟源码同等重要。这部分经验常被忽略，但实际上它往往是评分时区分“认真完成”和“应付了事”的关键。
部署文档建议按这样的结构写：环境要求、数据库初始化、后端部署步骤、前端部署步骤、访问地址和账号密码、常见问题。每一步都要对应到具体的菜单和命令，不要只写“配置环境”，要把application.yml哪一行改成什么写清楚。最好截图配合文字，打包成PDF，方便评委快速复现。
讲解视频或答辩PPT的节奏，建议控制在10分钟左右：先讲项目背景和技术选型，再切实际运行页面展示功能（用户端逛一圈、下一单、后台管理改个商品状态），最后将代码结构和核心接口调出来讲几十秒，全程不要背论文、不要念PPT，用“演示+极简讲解”的方式最容易拿高分。很多人答辩紧张，念稿子反而暴露对代码不熟，演示流程走下来反而顺利。
5. 常见问题与排错经验实录
5.1 后端接口访问404或跨域报错
这是前后端分离项目最常遇到的第一个问题。前端访问http://localhost:8080/api/product/list时控制台报错，排查顺序建议先直接在浏览器地址栏访问这个URL，如果浏览器直接显示JSON数据，说明后端接口本身没问题，问题出在跨域。
跨域报错的信息一般是“Access to XMLHttpRequest at ... has been blocked by CORS policy”。解决办法是在后端写一个配置类实现WebMvcConfigurer，重写addCorsMappings方法，允许所有来源、所有请求头、所有方法访问。配置类大约不到10行，网上搜一下就能找到。需要注意的坑是：如果你既用了CORS配置又加了Spring Security，跨域配置可能会被安全过滤器拦截，这类项目里如果没引入Security，直接写CORS配置类就行，别画蛇添足。
另一种情况是：后端接口在浏览器访问也404。这时候看启动日志，检查Controller的@RequestMapping路径是否和前端请求路径一致。常见的低级错误是Controller上写了类级路径/api，方法上又写了/product/list，但前端请求用的是/product/list，整个少了一层，自然404。
5.2 前端部署后页面正常但接口502
这个场景很典型：前端部署到Nginx后，打开页面能加载HTML和静态资源，但一调用接口就502 Bad Gateway。原因几乎都是proxy_pass配置里的代理地址不对，或者后端服务没有启动。
排查方法：先在服务器上执行curl http://localhost:8080/api/product/list，如果返回JSON说明后端活着。那么问题在Nginx的proxy_pass指向是否正确，检查proxy_pass后面有没有端口号、IP是不是写成了外网IP（localhost就够了），以及Nginx配置改动后有没有执行nginx -s reload。
还有一个容易忽略的坑：很多云服务器安全组默认不放行8080端口。如果你从浏览器访问http://服务器IP:8080/api/product/list被拒绝，那就是防火墙或安全组规则问题，需要在云控制台的防火墙规则里放行8080或直接让Nginx代理8080，业务上不让8080暴露也可以，但调试期放行更省事。
5.3 图片上传后无法显示
图片问题在商城项目中的出现频率高得惊人，而且表现形式都一样：上传成功后，页面上的图片区域显示一个小裂图或破图标。我用下面这个排查清单帮不少人解决过问题，你自己遇到也可以照着走：
- 看浏览器开发者工具Network面板，找图片的请求URL，确认状态码是200还是404。
- 如果是404，检查后端资源映射配置：
registry.addResourceHandler("/images/**").addResourceLocations("file:D:/mall/upload/")，注意物理路径最后的斜杠不能漏，少了会拼接出错。 - 确认数据库里存的图片路径到底是什么。如果你上传后存的URL是
/images/aaa.jpg，部署到服务器后请求http://域名/images/aaa.jpg，Nginx如果劫持了这个路径，需要额外配置一个location指向后端。如果直接暴露8080端口访问，一般能通。 - 部署到Linux时，注意路径大小写和权限问题。Linux路径区分大小写且对权限敏感，上传目录要给
chmod 755，确保应用进程有写入权限。
5.4 中文乱码：从数据库到页面的一条链排查
中文乱码通常有三处源头，需要按链路排查。第一，数据库连接URL没有characterEncoding=utf8参数；第二，表或字段的字符集不是utf8mb4，导入SQL时建表语句里如果没有指定字符集，MySQL可能默认用latin1；第三，前端页面没有声明UTF-8。
如果是打包成jar部署到Linux，还可能是启动脚本里没有指定-Dfile.encoding=UTF-8，导致文件读取乱码。建议在nohup java -jar mall.jar -Dfile.encoding=UTF-8层面强制指定，同时保证数据库连接、SQL文件字符集、前端HTML<meta charset="utf-8">三处一致。按这个链条逐段排查，中文乱码问题基本都能解决。
5.5 前端刷新404：history路由模式的经典问题
这个问题在4.3节里提过，具体表现是：用户从首页点进商品详情页，再按F5刷新，页面白屏或显示404。根本原因是vue-router用了history模式，刷新时浏览器用真实路径请求服务器，而服务器没有对应文件。
解决方案虽然简单（Nginx配置回退到index.html），但很多人卡住是由于心态问题：以为是代码写错了，在路由配置和打包配置之间来回翻。实际操作时，改完Nginx配置记得先测试：nginx -t检查语法，然后nginx -s reload重载配置，再刷新页面验证。
如果不用Nginx，只在开发环境出现这个问题，那就是webpack devServer的historyApiFallback没有配置，在vue.config.js里加historyApiFallback: true即可。
6. 一些扩展思路与经验总结
做这种项目，在保证核心链路完整以后，如果有余力，我建议在下面几个方向做一点深化，投入产出比很高，而且答辩时绝对能成为亮点。
一是接入真实支付模拟。微信和支付宝的正式商户接口需要营业执照和相关资质，学生项目做不了，但很多项目会用“支付宝沙箱环境”作为替代方案。沙箱接口和真实接口的调用逻辑几乎一致，只是用测试账号和测试密钥。如果能在订单模块里接入支付宝沙箱，答辩时的技术展示度会明显提升，论文里也能多写几千字。
二是把部署方式升级为Docker Compose。写一个docker-compose.yml，把MySQL、后端jar包、前端Nginx三个容器编排起来，一条命令部署整个商城。这个扩展对于阐述“可移植性”和“环境一致性”是很好的素材，也会让你的部署文档显得专业不少。如果服务器配置不高，不用硬上，本地虚拟机里跑也可以。
三是给订单模块加一个简单的统计报表页面。用ECharts做一个柱状图，展示最近7天或30天的订单量、销售额变化趋势。做这个功能不需要单独引入重量级报表框架，写一个GET /admin/statistics/order接口，查订单表按日期分组求和即可。图表带来的视觉冲击力，在答辩演示环节是很加分的。
四是如果源码里自带微信小程序端，那么支付模拟、登录鉴权、商品列表这些模块都要额外适配小程序的接口风格。不过这类改动工作量较大，如果交付文档里没要求，不要轻易中途变大需求。先用一个完整跑通的商城拿下及格或优秀，比追求全面覆盖却处处半成品更稳妥。
就我个人这几年的经验来说，这类“源码+lw+部署文档+讲解”的交付模式，真正拉开差距的地方往往不在代码本身，而在“你能否把它讲清楚”。把每一张表为什么这样设计、每一个接口为什么这样写、部署时踩了哪些坑又怎么解决，心里都理清楚，代码是谁写的不重要，答辩的时候它们就变成了你的东西。希望这篇拆解能让你少走几步弯路，三五天之内把环境和部署理顺，留出更多时间打磨论文和准备演示。最后再分享一个小技巧：无论从哪里拿到的源码，第一件事永远是先在本地完整跑通一遍，再谈修改和优化。跑通之前所有代码都是纸老虎，这一点比任何部署技巧都重要。
