搞 Java 后端的人十有八九都动过“抄一个淘宝”的念头。可真把 SpringBoot、Vue3、MyBatis、MySQL 这一套全家桶拼起来再做成 PC 端仿淘宝系统的前后端分离项目你会发现它不像 CRUD 练习那么简单——订单、库存、购物车、登录态、跨域、部署每一个环节都在逼你补课。这篇文章我会围绕这套仿淘宝 PC 端系统的完整实现把技术选型、表结构设计、Mapper 动态 SQL、Vue3 页面搭建、接口联调、MySQL 配置、打包部署以及我实际跑源码时踩过的坑一次说清楚。无论你是拿它做毕设、写进简历还是单纯想把 SpringBoot 和 Vue3 的工程化串联起来这套项目的价值都不小。1. 项目全貌与技术选型思路1.1 仿淘宝仿的到底是“淘宝”的什么很多人看到“仿淘宝系统”第一反应是做一个长得像淘宝官网的前端页面这个理解其实只对了一小半。真正值得模仿的是淘宝在 PC 端沉淀下来的那套电商业务链路用户浏览商品、按关键词和分类搜索、进入详情页选规格加购物车、提交订单、填写收货地址、完成支付、查看订单状态再加上后台的商品管理和订单管理。这套链路几乎覆盖了电商系统里所有核心数据流转比单纯做一个“UI 克隆”值钱得多。所以这套项目的本质是一个把电商主流程完整落地的单体全栈应用。它会包含 C 端用户端和 B 端管理后台C 端用 Vue3 还原淘宝风格的商城页面B 端可以做成一套基于 Element Plus 的后台管理界面。后端则用 SpringBoot 提供 RESTful APIMyBatis 负责持久层操作MySQL 存所有业务数据。前后端通过 JSON 交互真正做到前后端分离。用这个项目能学到什么我总结成三点第一搞清楚一个真实业务系统从前到后的数据流向而不是只停留在 Controller 和 Service 的增删改查第二掌握电商系统中订单、库存这类敏感数据的处理方式包括事务、锁和状态流转第三把 Vue3 的工程化开发包括路由、状态管理、组件复用和 axios 封装真正落到一个完整项目里。它不是一个炫技项目而是一个让你把 Java 全栈知识串起来的整合项目。1.2 为什么这套技术栈是中型项目最稳的搭配先回答一个很多人会问的问题都 2025 年了为什么还有人用 MyBatis而不是直接用 MyBatis-Plus 或者 JPA我的看法是对于仿淘宝这种查询复杂、SQL 可控性要求高的项目原生 MyBatis 反而更合适。商品列表需要多条件动态查询订单查询需要一对多映射这些用 MyBatis 的 XML 写起来非常顺手SQL 完全掌握在你自己手里。JPA 虽然开发快但一旦遇到复杂查询调试 SQL 会让你怀疑人生MyBatis-Plus 虽然方便但如果你刚接触 MyBatis直接上手 Plus 会漏掉对 SQL 映射和动态 SQL 的理解。这套项目用原生 MyBatis恰恰是最好的学习路径。当然如果你后续想提升开发效率在项目里引入 MyBatis-Plus 的IService.saveBatch做批量插入也完全没问题这个我在后面实操部分会说到。SpringBoot 的价值不用多讲它把配置、启动、部署的复杂度降到了很低。Vue3 配合 Vite 和 Element Plus开发体验和打包产物都比 Vue2 时代舒服太多。MySQL 在这个项目体量下也完全够用不会像微服务方案那样引入 Redis、MQ、注册中心一堆中间件反而把简单问题搞复杂。整套技术栈的组合逻辑是单体架构 前后端分离 半自动 ORM 关系型数据库这是中小型电商系统非常务实的一套方案你可以直接抄思路。1.3 前后端分离的工程结构与请求链路工程结构是这套项目最先要理清的部分。后端建议按基础的分层结构走controller只做参数接收和结果返回service处理业务逻辑mapper定义数据库操作接口entity对应表结构dto负责层间数据传递。再加一个common包存放统一返回结果类ResultT、全局异常处理器和工具类。backend ├── pom.xml └── src/main/java/com/example/mall ├── MallApplication.java ├── common // Result、异常处理器、常量 ├── controller // 用户、商品、购物车、订单、后台管理接口 ├── service // 业务层接口与实现 ├── mapper // MyBatis Mapper 接口 ├── entity // 数据库实体 ├── dto // 请求参数与返回参数对象 └── config // 跨域、拦截器、WebMvc 配置前端基于 Vite 创建 Vue3 工程结构上按业务模块划分frontend ├── package.json ├── vite.config.js ├── index.html └── src ├── main.js ├── App.vue ├── api // 每个模块的请求接口封装 ├── assets // 静态资源与全局样式 ├── components // 商品卡片、搜索框、分页等公共组件 ├── router // 路由配置 ├── store // Pinia 状态管理 ├── utils // axios 封装、格式化工具 └── views // 首页、搜索页、详情页、购物车、订单、后台页面数据流的走向也很清晰前端 axios 发起请求后端 Controller 接收Service 处理业务Mapper 访问 MySQL结果通过统一的Result包装成 JSON 返回给前端。前端拿到数据后通过 Vue3 的响应式系统渲染到页面。这个链路看起来简单但真正做到位需要前后端对接口字段、状态码、异常格式都有一致约定这也是我在后文反复强调接口规范的原因。2. 核心业务模块与数据库设计2.1 一张表看清电商核心数据模型理解了项目整体结构后要过的第一关就是数据库设计。仿淘宝系统不需要像淘宝那样搞出几百张表但电商链路中的核心表必须完整。我按最小可用集合给你整理一下。表名核心字段作用userid, username, password, phone, avatar, created_at用户与登录认证categoryid, name, parent_id, sort商品分类productid, category_id, name, subtitle, main_image, detail, price, stock, status商品 SPU 与基础 SKU 信息cart_itemid, user_id, product_id, quantity, checked购物车条目orderid, order_no, user_id, total_amount, status, address_id, created_at订单主表order_itemid, order_id, product_id, product_name, product_image, price, quantity订单明细addressid, user_id, receiver, phone, province, city, district, detail收货地址bannerid, image_url, link_url, sort, status首页轮播图这里面最需要注意的设计点有两个。一个是用逻辑外键而不是物理外键。如果你在建表时给每个表都加上 FOREIGN KEY数据一致性看起来是保证了但后续做分库分表、做订单归档的时候物理外键会成为巨大障碍。在电商这种读多写少、查询路径复杂的场景逻辑外键配合应用层校验是主流做法。另一个是订单表的order_no不要用自增 ID因为订单号会暴露业务数据量而且并发量上来后自增 ID 也不安全。我习惯用时间戳 用户 ID 后四位 随机数生成订单号再给order_no加唯一索引既能保证不重复又不会泄露订单总量。product表的 SPU/SKU 设计在仿淘宝项目里可以做精简。如果你的系统只卖纯规格商品比如一件衣服只有一个价格和一份库存那一张product表就够了。如果要实现颜色、尺码等多规格选择可以在product表之外加一张sku表product表存 SPU 公共信息sku表存规格名称、价格、库存。选择哪种方案取决于你想把项目做多深但核心原则是不要让一张表承担太多职责。2.2 MyBatis 动态 SQL商品搜索与一对多映射数据库设计完了接下来就是 MyBatis 的核心场景商品列表的多条件搜索以及订单详情的嵌套查询。这套项目中 Mapper XML 的质量直接决定接口好不好写。商品搜索是整个系统里最典型的动态 SQL 场景。用户可能只输入关键词也可能同时选分类和价格区间这些条件组合是不确定的。如果用拼接字符串的方式写 SQL 会非常痛苦MyBatis 的where加if就是为这个场景设计的。select idsearchProducts resultTypecom.example.mall.entity.Product SELECT id, category_id, name, subtitle, main_image, price, stock, status FROM product where if testkeyword ! null and keyword ! AND (name LIKE CONCAT(%, #{keyword}, %) OR subtitle LIKE CONCAT(%, #{keyword}, %)) /if if testcategoryId ! null AND category_id #{categoryId} /if if testminPrice ! null AND price gt; #{minPrice} /if if testmaxPrice ! null AND price lt; #{maxPrice} /if AND status 1 /where ORDER BY id DESC LIMIT #{offset}, #{pageSize} /select这里要提醒一个细节和在 XML 里必须写成gt;和lt;否则 XML 解析会直接报错。另一个细节是LIKE查询最好用CONCAT拼接%不要直接在#{}里传%否则容易出现参数注入和格式问题。配合 MyBatisX 插件IDEA 里可以直接从 Mapper 接口跳到 XML还能在 XML 里看到方法说明这算是我强烈建议装上的一类插件。订单详情的一对多查询也是 MyBatis 的经典考题。一个订单对应多个商品明细如果用循环查询会浪费大量数据库往返。正确做法是查一次订单主表再用collection映射明细列表。resultMap idOrderDetailMap typecom.example.mall.dto.OrderDetailDTO id propertyid columnid/ result propertyorderNo columnorder_no/ result propertystatus columnstatus/ result propertytotalAmount columntotal_amount/ collection propertyitems ofTypecom.example.mall.entity.OrderItem id propertyid columnitem_id/ result propertyproductName columnproduct_name/ result propertyprice columnprice/ result propertyquantity columnquantity/ /collection /resultMap select idselectOrderDetail resultMapOrderDetailMap SELECT o.id, o.order_no, o.status, o.total_amount, oi.id AS item_id, oi.product_name, oi.price, oi.quantity FROM order o LEFT JOIN order_item oi ON o.id oi.order_id WHERE o.id #{orderId} /select这段 SQL 是典型的“连表查明细、resultMap 做映射”。需要注意order是 MySQL 的保留字所以表名一定要加反引号。我之前见过不少人在这一步栽跟头SQL 看起来没毛病一执行就报语法错误其实就是保留字没转义。2.3 事务、乐观锁与缓存边界电商系统里最不能出错的环节一定是下单。下单不是一次插入订单表就完事它是一个完整事务校验商品状态、锁定库存、生成订单主表和明细、扣减库存、清空购物车。任何一个环节失败前面所有操作都得回滚。在 SpringBoot 里给 Service 方法加Transactional(rollbackFor Exception.class)是最基本的操作。注意一定要指定rollbackFor因为 Spring 默认只在遇到 RuntimeException 时回滚遇到异常时很容易造成“订单没生成但库存已经扣了”这种数据不一致问题。库存扣减是仿淘宝项目里最值得花时间研究的地方。如果直接用UPDATE product SET stock stock - 1 WHERE id ?在高并发下会出现超卖。解决方案有两种思路第一种是乐观锁方式在product表加version字段更新时带上版本号判断UPDATE product SET stock stock - #{num}, version version 1 WHERE id #{id} AND stock #{num} AND version #{version}第二种是直接利用 SQL 的原子性不查版本号UPDATE product SET stock stock - #{num} WHERE id #{id} AND stock #{num}第二种写法在大多数单体业务里已经够用它保证扣减操作的原子性同时用stock #{num}这个条件从数据库层面挡住了超卖。很多人纠结要不要用 Redis Lua 脚本做库存扣减我的建议是单体项目先别急着上 Redis把数据库方案做到位后面真要扛高并发再演进到预扣库存方案也不迟。缓存这块要特别说一句 MyBatis 的坑。MyBatis 一级缓存是 SqlSession 级别的在 Spring 管理的 Mapper 里每次操作通常是独立的 SqlSession一级缓存作用非常有限。二级缓存默认是关闭的很多人为了性能开启后发现商品数据更新了但查询结果还是旧的这就是缓存脏读。在这个项目里我建议不要开 MyBatis 二级缓存。如果要做缓存购物车数量、热门商品这类数据放到业务层由你手动控制过期时间或者直接引入 Redis。这样既能控制数据一致性又不至于被隐蔽的缓存问题坑到。3. Vue3 Element Plus 的 PC 端实现3.1 从零初始化 Vue3 工程前端部分我们直接从工程初始化开始。创建项目我用 Vite不用 Vue CLI因为 Vite 基于 ESBuild冷启动速度和热更新体验都比 Webpack 时代舒服太多。npm create vitelatest mall-frontend -- --template vue cd mall-frontend npm install npm install element-plus npm install element-plus/icons-vue npm install pinia vue-router axios npm install -D sass这里说一下 Sass 的安装。新版 Vite 只需要装sass依赖不再需要node-sass而且也不需要额外配置就能在style langscss中直接使用。如果发现样式不生效检查一下 Vite 版本和 sass 版本避免 Sass 的 Legacy JS API 警告导致编译失败。Element Plus 建议按官方推荐的方式按需引入直接用unplugin-auto-import和unplugin-vue-components这两个 Vite 插件组件和 API 都能自动导入打包体积会小很多。如果你不想折腾按需引入全局引入也不是不行就是首屏打包产物会到 1MB 以上自己学习无所谓做项目还是建议按需。axios 封装是前端最不能省的一步。我的习惯是创建一个request.js统一设置baseURL、超时时间在请求拦截器里从 Pinia 或 localStorage 拿 token 放到请求头在响应拦截器里统一处理 HTTP 状态码和业务状态码。import axios from axios import { ElMessage } from element-plus const request axios.create({ baseURL: import.meta.env.VITE_API_BASE_URL, timeout: 10000 }) request.interceptors.request.use(config { const token localStorage.getItem(token) if (token) { config.headers.Authorization Bearer ${token} } return config }) request.interceptors.response.use( response { const res response.data if (res.code ! 200) { ElMessage.error(res.message || 请求失败) return Promise.reject(new Error(res.message)) } return res.data }, error { if (error.response?.status 401) { ElMessage.error(登录已过期请重新登录) window.location.href /login } else { ElMessage.error(error.message || 网络异常) } return Promise.reject(error) } ) export default request这里的VITE_API_BASE_URL放到.env.development和.env.production两个环境文件里开发环境指向http://localhost:8080/api生产环境指向你的后端域名。用环境变量而不是硬编码是前后端分离项目的基本修养。3.2 仿淘宝页面的组件化拆分思路仿淘宝 PC 端页面的核心不是像素级还原而是组件抽象。首页、搜索列表页、商品详情页、购物车、结算页、订单列表页这些页面之间大量存在复用逻辑。我在实际项目中通常抽这几个公共组件ProductCard商品卡片、PaginationBar分页栏、NumberInput数量选择器、EmptyState空状态占位。商品卡片在首页、搜索页、推荐位里都会用到所以把它做成接收product对象的组件内部负责跳转详情页。状态管理用 Pinia而不是把所有数据都塞进全局状态。购物车数量、登录用户信息这类跨页面共享的数据适合放 Pinia而商品详情页这种从接口获取的单一页面数据用组件局部状态就够了。如果什么东西都往 Pinia 里放最后就是一个巨大的全局对象组件间耦合会增加调试也会变难。页面路由需要分两套用户端路由和后台管理路由。用户端包括/home、/search、/product/:id、/cart、/checkout、/orders、/login等后台管理要以/admin为前缀配置单独的子路由和布局。路由守卫的逻辑是进入购物车、结算、订单页面之前判断是否登录未登录就跳转/login并附带redirect参数进入后台管理页面之前判断当前用户角色是否为管理员。这里有一个容易忽略的点/login页面本身不能被守卫拦截否则会形成跳转死循环。3.3 跨域、拦截器与登录态控制前后端分离项目最头疼的问题就是跨域这个项目也不会例外。开发环境下浏览器访问http://localhost:5173后端跑在http://localhost:8080两者端口不同浏览器会发起同源策略检查跨域配置没做好前端请求根本发不出去。开发环境最简单的方式是配置 Vite 代理前端把所有/api开头的请求转发到后端// vite.config.js export default defineConfig({ server: { proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } })这样设置之后浏览器访问的是同源地址跨域问题在代理层就解决了。生产环境下你通常会部署 Nginx那就直接把/api反向代理到后端服务。两套方案的核心是一样的让前端请求和后端响应在同一个源下完成。后端这边同时建议加一个全局 CORS 配置作为兜底不然你在本地拿 Postman 调试没问题一接前端就开始报跨域。SpringBoot 里实现一个WebMvcConfigurer配置允许的源、请求头和请求方法即可。这里有个细节配置allowCredentials(true)时allowedOrigins不能是*必须写明确域名否则浏览器会直接拒绝。登录态控制这块我用 JWT不用传统 Session。登录成功后后端返回 token前端存到 localStorageaxios 请求拦截器统一加Authorization头。后端加一个拦截器校验 token放行登录注册接口拦截其他接口。要注意 token 失效时返回统一的 401 状态码前端响应拦截器识别到 401 后清理本地登录态并跳转登录页。如果你追求更完善的安全防护还可以在后端做一个全局过滤器对请求参数中的特殊字符做 HTML 转义和敏感词过滤防止存储型 XSS这本来也是电商后台常见的安全需求。4. MySQL 初始化、连接池与上线部署4.1 MySQL 初始化与连接池参数数据库这块建议直接用 MySQL 8.x原因很简单资料多、默认字符集处理得好、性能比 5.7 有提升。安装 MySQL 时有两个地方必须注意一个是字符集要选utf8mb4不是utf8因为utf8在 MySQL 里最多支持 3 字节存 emoji 表情和生僻字会直接报错另一个是时区问题MyBatis 连接 MySQL 8 时如果 JDBC URL 少了serverTimezoneAsia/Shanghai会直接报 CST 时区识别错误或者查询出来的时间比预期慢 8 小时。连接池我强烈建议用 HikariCPSpringBoot 2.x 之后默认集成性能比 Druid 好配置也少。如果你需要 SQL 监控、慢查询日志这种可视化功能再考虑换 Druid。两者的核心参数你要能看懂配置项HikariCPDruid说明最大连接数maximum-pool-sizemaxActive连接池能提供的最大连接数最小空闲minimum-idleminIdle空闲状态下保留的最小连接数连接超时connection-timeoutmaxWait获取连接的最大等待时间检测语句默认无需配置validationQuery保活检测 SQLDruid 通常配置 SELECT 1HikariCP 默认的maximumPoolSize是 10对仿淘宝这种项目跑单机完全够。如果你用 Druid建议maxActive设 20、initialSize设 5同时开启testWhileIdle和timeBetweenEvictionRunsMillis避免数据库空闲一段时间后连接被 MySQL 服务端切断。数据库初始化用项目自带的 SQL 脚本最省事。导入时要注意排序问题先建用户表、分类表再建商品表、购物车表最后建订单表和订单明细表。如果 SQL 脚本里有外键约束导入顺序反了会直接报错。表结构字段建议统一用下划线命名比如created_at然后 MyBatis 配置mapUnderscoreToCamelCase: true这样数据库字段到 Java 属性的映射就不用手动一个个配resultMap了。4.2 图片与静态资源上传方案商品图片、轮播图、用户头像这三类静态资源需要单独想清楚存储方案。网上很多项目直接把图片转 Base64 存数据库系统演示没问题一旦图片多了数据库会迅速膨胀接口响应也会变慢基本不是能上生产的方案。最简单的做法是本地存储。在application.yml里配置上传路径比如D:/mall/upload后端通过 MultipartFile 接收文件后保存到该目录再把访问 URL 返回给前端。这里有个关键点你需要写一个静态资源配置类把/upload/**映射到本地目录不然前端根本访问不到图片。spring: servlet: multipart: max-file-size: 10MB max-request-size: 50MB mall: upload: path: /data/mall/upload url-prefix: /upload如果你还想做得更有工程化味道推荐集成 MinIO。MinIO 是一个开源对象存储服务项目里集成它并不复杂引入minio依赖写一个配置类和工具类然后上传时调用putObject就能得到文件访问地址。Configuration public class MinioConfig { Value(${minio.endpoint}) private String endpoint; Value(${minio.access-key}) private String accessKey; Value(${minio.secret-key}) private String secretKey; Bean public MinioClient minioClient() { return MinioClient.builder() .endpoint(endpoint) .credentials(accessKey, secretKey) .build(); } }MinIO 的优势是后续做分布式部署、做图片 CDN 加速都比较顺。我的建议是开发阶段用本地存储省事生产部署时无缝切换到 MinIO两边接口保持一致不会造成大量代码改动。4.3 打包部署jar 包加 Nginx 反向代理项目能本地跑通只是第一步部署上线才是完整闭环。后端打包用 Maven注意打包前要跑测试用例的话可能比较耗时直接跳过mvn clean package -DskipTests打包完成后在target目录生成mall-0.0.1-SNAPSHOT.jar。部署时直接扔到服务器上运行nohup java -jar mall-0.0.1-SNAPSHOT.jar --spring.profiles.activeprod app.log 21 前端打包npm run build生成的dist目录就是纯静态文件把它放到 Nginx 的 web 根目录再配置一个反向代理把/api请求转发给后端的 8080 端口server { listen 80; server_name localhost; root /usr/share/nginx/html; index index.html; location / { 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; } location /upload/ { alias /data/mall/upload/; } }Nginx 配置里最容易踩的坑是前端路由。Vue3 使用 history 模式路由后直接刷新/product/123页面Nginx 会去磁盘找这个文件找不到就 404。所以必须加try_files $uri $uri/ /index.html这行让所有刷新请求回退到index.html再交给前端路由去解析。后端接口走/api前缀的好处在这里也体现得特别明显静态文件请求和 API 请求可以干净分离。关于部署还有一个常见的疑问就是拿到一个 jar 包后怎么反编译回源码。Java 程序编译出来的 class 可以通过 CFR、JD-GUI、Procyon 这类工具反编译还原成 Java 代码反编译出来的代码虽然不能 100% 还原注释和泛型信息但作为找回源码片段、学习代码逻辑是完全够用的。不过我要提醒一句反编译只适用于你自己的项目或其他开源项目拿别人有版权的商业软件反编译去复用是侵权行为别干这种事。5. 高频坑位与优化实录5.1 开发期必踩的五个问题这个项目做下来我记录了五个高频问题可以说每个都至少浪费过我半天时间。第一个是 MySQL 8 的时区问题。现象是后端插入的时间数据在数据库里看是对的但接口查询返回给前端的时间比实际时间少了 8 小时。解决办法是在 JDBC URL 里显式加serverTimezoneAsia/Shanghai同时确认 MySQL 服务端时区设置正确。第二个是 axios 请求接口时浏览器控制台报跨域。很多人一看到跨域就去后端配 CORS但如果你已经用了 Vite proxy那问题就不在 CORS而在于请求是否走了/api前缀。检查一下前端 baseURL 是否写成了完整地址如果是http://localhost:8080/api就不会走代理一定要写成/api这种相对路径。第三个是 Element Plus 的图标不显示。按需引入组件时图标需要单独在需要的地方手动注册如果只引入了组件没引入图标页面上的图标就会显示为空白。解决方法是在main.js或某个index.js里统一注册需要的图标import * as ElementPlusIconsVue from element-plus/icons-vue for (const [key, component] of Object.entries(ElementPlusIconsVue)) { app.component(key, component) }第四个是 MyBatis 查询结果某些字段为 null。这个大概率是数据库下划线字段和 Java 驼峰属性没对上。检查application.yml是否配置了map-underscore-to-camel-case: true或者手动写resultMap指定映射关系。第五个是用户快速下单导致重复订单。前端连续点击提交按钮后端生成了多笔订单。这个问题要从两端解决前端点击后给按钮加 loading 状态防止重复提交后端也需要做幂等控制最简单的方式是订单创建接口要求前端提交一个唯一的请求号后端判断该请求号是否已处理过处理过就直接拒绝。5.2 性能与安全加固项目能跑通之后就该考虑它够不够稳、够不够安全。性能这块最立竿见影的是加索引。商品列表按分类查询category_id字段的索引必须加商品状态过滤要覆盖status高频搜索关键词LIKE %xxx%场景下普通索引其实吃不上力只能靠全文检索或搜索引擎来解决这个后面扩展方向里我会说。订单表按用户查询订单列表是最高频操作(user_id, status)联合索引也建议加上。索引不是越多越好但电商这种读写模式清晰的系统订单表和商品表的索引收益是很明显的。安全方面SQL 注入是 MyBatis 必须守住的底线。#{}是预编译占位符${}是字符串拼接。模糊查询、排序字段、拼 SQL 的地方除非你能确认值来自白名单否则一律用#{}这个是原则问题。越权漏洞也非常常见比如用户 A 通过篡改请求参数访问用户 B 的订单这种问题在写接口时必须留意查询购物车和订单时强制带上当前登录用户 ID而不是只依赖前端传的参数来拼 SQL前端传参可以作为辅助但不能作为唯一的查询条件。如果想对自己的后端做一次 XSS 安全加固可以仿照我在前面提到的思路写一个全局过滤器对请求体的文本参数做 HTML 实体编码对富文本字段做白名单标签过滤这样能最大程度减少存储型 XSS 的隐患。5.3 作为学习项目如何让价值翻倍最后聊一聊怎么把这个项目用好。老实说仿淘宝系统的源码并不稀缺真正值钱的不是把代码跑起来而是你能讲清楚每个模块为什么这么设计并且能在项目上做出有区分度的改进。如果你拿去当毕业设计或简历项目我会建议你做以下三到五个改造会让项目的价值和面试含金量立刻提升一个档次。第一个改造是引入 Redis 做热门商品缓存和购物车数量的临时存储可以在简历上写“通过缓存降低数据库访问压力”第二个改造是引入 RabbitMQ 做订单超时未支付自动取消模拟真实电商的延迟消息场景第三个改造是把商品搜索从 MySQL 的 LIKE 查询替换成 Elasticsearch前端搜索体验会明显变好第四个相对轻量集成 HanLP 做商品搜索分词让搜索在中文语境下更聪明效果好的同时实现难度也远低于上 ES第五个是后台管理增加数据导出功能用 EasyExcel 导出商品列表和订单报表比 POI 轻量太多也不会牵扯到 POI 生成图表那些看似高大上、实际落地很鸡肋的问题。做完这些改造项目就不只是一个“仿淘宝”而是一个有优化思路的完整电商系统。面试的时候你要能闭着眼睛讲出几条核心链路。比如用户下单时请求经过前端拦截器加 token、后端 Controller 接收参数、Service 开启事务、Mapper 更新库存、订单表和明细表写入、最后返回订单号——每一步做了什么、失败了怎么回滚、库存扣超了怎么办。能把一条链路的逻辑讲通比背一百个八股文都管用。项目里的难点比如库存防超卖、订单号生成、跨域方案每一个都是可以拿出来深入聊几分钟的话题。我个人在跑完这套项目后最大的体会是这种全栈项目最磨人的不是某一个技术点的深度而是数据在前后端之间流转的“链路感”。你得同时盯着后端日志和浏览器控制台看请求参数、响应结构、字段命名是否对得上耐心反而是最重要的能力。给初学者的建议是不要把全部精力放在“我要做个一模一样的淘宝”上先跑通一个最小闭环用户注册登录、浏览商品、加入购物车、提交订单。这个闭环跑通了后面所有模块都是在给它添砖加瓦。最后再分享一个我一直在用的小技巧写完每个接口都要用 Postman 或者 Apifox 存一个测试用例前后端对接口时能省下大量反复沟通的时间。项目做到最后你积累的不只是代码还有一套属于自己的调试方法这才是这类实战项目最有价值的部分。 SpringBoot+Vue3仿淘宝全栈实战：前后端分离与电商系统构建
搞 Java 后端的人十有八九都动过“抄一个淘宝”的念头。可真把 SpringBoot、Vue3、MyBatis、MySQL 这一套全家桶拼起来再做成 PC 端仿淘宝系统的前后端分离项目你会发现它不像 CRUD 练习那么简单——订单、库存、购物车、登录态、跨域、部署每一个环节都在逼你补课。这篇文章我会围绕这套仿淘宝 PC 端系统的完整实现把技术选型、表结构设计、Mapper 动态 SQL、Vue3 页面搭建、接口联调、MySQL 配置、打包部署以及我实际跑源码时踩过的坑一次说清楚。无论你是拿它做毕设、写进简历还是单纯想把 SpringBoot 和 Vue3 的工程化串联起来这套项目的价值都不小。1. 项目全貌与技术选型思路1.1 仿淘宝仿的到底是“淘宝”的什么很多人看到“仿淘宝系统”第一反应是做一个长得像淘宝官网的前端页面这个理解其实只对了一小半。真正值得模仿的是淘宝在 PC 端沉淀下来的那套电商业务链路用户浏览商品、按关键词和分类搜索、进入详情页选规格加购物车、提交订单、填写收货地址、完成支付、查看订单状态再加上后台的商品管理和订单管理。这套链路几乎覆盖了电商系统里所有核心数据流转比单纯做一个“UI 克隆”值钱得多。所以这套项目的本质是一个把电商主流程完整落地的单体全栈应用。它会包含 C 端用户端和 B 端管理后台C 端用 Vue3 还原淘宝风格的商城页面B 端可以做成一套基于 Element Plus 的后台管理界面。后端则用 SpringBoot 提供 RESTful APIMyBatis 负责持久层操作MySQL 存所有业务数据。前后端通过 JSON 交互真正做到前后端分离。用这个项目能学到什么我总结成三点第一搞清楚一个真实业务系统从前到后的数据流向而不是只停留在 Controller 和 Service 的增删改查第二掌握电商系统中订单、库存这类敏感数据的处理方式包括事务、锁和状态流转第三把 Vue3 的工程化开发包括路由、状态管理、组件复用和 axios 封装真正落到一个完整项目里。它不是一个炫技项目而是一个让你把 Java 全栈知识串起来的整合项目。1.2 为什么这套技术栈是中型项目最稳的搭配先回答一个很多人会问的问题都 2025 年了为什么还有人用 MyBatis而不是直接用 MyBatis-Plus 或者 JPA我的看法是对于仿淘宝这种查询复杂、SQL 可控性要求高的项目原生 MyBatis 反而更合适。商品列表需要多条件动态查询订单查询需要一对多映射这些用 MyBatis 的 XML 写起来非常顺手SQL 完全掌握在你自己手里。JPA 虽然开发快但一旦遇到复杂查询调试 SQL 会让你怀疑人生MyBatis-Plus 虽然方便但如果你刚接触 MyBatis直接上手 Plus 会漏掉对 SQL 映射和动态 SQL 的理解。这套项目用原生 MyBatis恰恰是最好的学习路径。当然如果你后续想提升开发效率在项目里引入 MyBatis-Plus 的IService.saveBatch做批量插入也完全没问题这个我在后面实操部分会说到。SpringBoot 的价值不用多讲它把配置、启动、部署的复杂度降到了很低。Vue3 配合 Vite 和 Element Plus开发体验和打包产物都比 Vue2 时代舒服太多。MySQL 在这个项目体量下也完全够用不会像微服务方案那样引入 Redis、MQ、注册中心一堆中间件反而把简单问题搞复杂。整套技术栈的组合逻辑是单体架构 前后端分离 半自动 ORM 关系型数据库这是中小型电商系统非常务实的一套方案你可以直接抄思路。1.3 前后端分离的工程结构与请求链路工程结构是这套项目最先要理清的部分。后端建议按基础的分层结构走controller只做参数接收和结果返回service处理业务逻辑mapper定义数据库操作接口entity对应表结构dto负责层间数据传递。再加一个common包存放统一返回结果类ResultT、全局异常处理器和工具类。backend ├── pom.xml └── src/main/java/com/example/mall ├── MallApplication.java ├── common // Result、异常处理器、常量 ├── controller // 用户、商品、购物车、订单、后台管理接口 ├── service // 业务层接口与实现 ├── mapper // MyBatis Mapper 接口 ├── entity // 数据库实体 ├── dto // 请求参数与返回参数对象 └── config // 跨域、拦截器、WebMvc 配置前端基于 Vite 创建 Vue3 工程结构上按业务模块划分frontend ├── package.json ├── vite.config.js ├── index.html └── src ├── main.js ├── App.vue ├── api // 每个模块的请求接口封装 ├── assets // 静态资源与全局样式 ├── components // 商品卡片、搜索框、分页等公共组件 ├── router // 路由配置 ├── store // Pinia 状态管理 ├── utils // axios 封装、格式化工具 └── views // 首页、搜索页、详情页、购物车、订单、后台页面数据流的走向也很清晰前端 axios 发起请求后端 Controller 接收Service 处理业务Mapper 访问 MySQL结果通过统一的Result包装成 JSON 返回给前端。前端拿到数据后通过 Vue3 的响应式系统渲染到页面。这个链路看起来简单但真正做到位需要前后端对接口字段、状态码、异常格式都有一致约定这也是我在后文反复强调接口规范的原因。2. 核心业务模块与数据库设计2.1 一张表看清电商核心数据模型理解了项目整体结构后要过的第一关就是数据库设计。仿淘宝系统不需要像淘宝那样搞出几百张表但电商链路中的核心表必须完整。我按最小可用集合给你整理一下。表名核心字段作用userid, username, password, phone, avatar, created_at用户与登录认证categoryid, name, parent_id, sort商品分类productid, category_id, name, subtitle, main_image, detail, price, stock, status商品 SPU 与基础 SKU 信息cart_itemid, user_id, product_id, quantity, checked购物车条目orderid, order_no, user_id, total_amount, status, address_id, created_at订单主表order_itemid, order_id, product_id, product_name, product_image, price, quantity订单明细addressid, user_id, receiver, phone, province, city, district, detail收货地址bannerid, image_url, link_url, sort, status首页轮播图这里面最需要注意的设计点有两个。一个是用逻辑外键而不是物理外键。如果你在建表时给每个表都加上 FOREIGN KEY数据一致性看起来是保证了但后续做分库分表、做订单归档的时候物理外键会成为巨大障碍。在电商这种读多写少、查询路径复杂的场景逻辑外键配合应用层校验是主流做法。另一个是订单表的order_no不要用自增 ID因为订单号会暴露业务数据量而且并发量上来后自增 ID 也不安全。我习惯用时间戳 用户 ID 后四位 随机数生成订单号再给order_no加唯一索引既能保证不重复又不会泄露订单总量。product表的 SPU/SKU 设计在仿淘宝项目里可以做精简。如果你的系统只卖纯规格商品比如一件衣服只有一个价格和一份库存那一张product表就够了。如果要实现颜色、尺码等多规格选择可以在product表之外加一张sku表product表存 SPU 公共信息sku表存规格名称、价格、库存。选择哪种方案取决于你想把项目做多深但核心原则是不要让一张表承担太多职责。2.2 MyBatis 动态 SQL商品搜索与一对多映射数据库设计完了接下来就是 MyBatis 的核心场景商品列表的多条件搜索以及订单详情的嵌套查询。这套项目中 Mapper XML 的质量直接决定接口好不好写。商品搜索是整个系统里最典型的动态 SQL 场景。用户可能只输入关键词也可能同时选分类和价格区间这些条件组合是不确定的。如果用拼接字符串的方式写 SQL 会非常痛苦MyBatis 的where加if就是为这个场景设计的。select idsearchProducts resultTypecom.example.mall.entity.Product SELECT id, category_id, name, subtitle, main_image, price, stock, status FROM product where if testkeyword ! null and keyword ! AND (name LIKE CONCAT(%, #{keyword}, %) OR subtitle LIKE CONCAT(%, #{keyword}, %)) /if if testcategoryId ! null AND category_id #{categoryId} /if if testminPrice ! null AND price gt; #{minPrice} /if if testmaxPrice ! null AND price lt; #{maxPrice} /if AND status 1 /where ORDER BY id DESC LIMIT #{offset}, #{pageSize} /select这里要提醒一个细节和在 XML 里必须写成gt;和lt;否则 XML 解析会直接报错。另一个细节是LIKE查询最好用CONCAT拼接%不要直接在#{}里传%否则容易出现参数注入和格式问题。配合 MyBatisX 插件IDEA 里可以直接从 Mapper 接口跳到 XML还能在 XML 里看到方法说明这算是我强烈建议装上的一类插件。订单详情的一对多查询也是 MyBatis 的经典考题。一个订单对应多个商品明细如果用循环查询会浪费大量数据库往返。正确做法是查一次订单主表再用collection映射明细列表。resultMap idOrderDetailMap typecom.example.mall.dto.OrderDetailDTO id propertyid columnid/ result propertyorderNo columnorder_no/ result propertystatus columnstatus/ result propertytotalAmount columntotal_amount/ collection propertyitems ofTypecom.example.mall.entity.OrderItem id propertyid columnitem_id/ result propertyproductName columnproduct_name/ result propertyprice columnprice/ result propertyquantity columnquantity/ /collection /resultMap select idselectOrderDetail resultMapOrderDetailMap SELECT o.id, o.order_no, o.status, o.total_amount, oi.id AS item_id, oi.product_name, oi.price, oi.quantity FROM order o LEFT JOIN order_item oi ON o.id oi.order_id WHERE o.id #{orderId} /select这段 SQL 是典型的“连表查明细、resultMap 做映射”。需要注意order是 MySQL 的保留字所以表名一定要加反引号。我之前见过不少人在这一步栽跟头SQL 看起来没毛病一执行就报语法错误其实就是保留字没转义。2.3 事务、乐观锁与缓存边界电商系统里最不能出错的环节一定是下单。下单不是一次插入订单表就完事它是一个完整事务校验商品状态、锁定库存、生成订单主表和明细、扣减库存、清空购物车。任何一个环节失败前面所有操作都得回滚。在 SpringBoot 里给 Service 方法加Transactional(rollbackFor Exception.class)是最基本的操作。注意一定要指定rollbackFor因为 Spring 默认只在遇到 RuntimeException 时回滚遇到异常时很容易造成“订单没生成但库存已经扣了”这种数据不一致问题。库存扣减是仿淘宝项目里最值得花时间研究的地方。如果直接用UPDATE product SET stock stock - 1 WHERE id ?在高并发下会出现超卖。解决方案有两种思路第一种是乐观锁方式在product表加version字段更新时带上版本号判断UPDATE product SET stock stock - #{num}, version version 1 WHERE id #{id} AND stock #{num} AND version #{version}第二种是直接利用 SQL 的原子性不查版本号UPDATE product SET stock stock - #{num} WHERE id #{id} AND stock #{num}第二种写法在大多数单体业务里已经够用它保证扣减操作的原子性同时用stock #{num}这个条件从数据库层面挡住了超卖。很多人纠结要不要用 Redis Lua 脚本做库存扣减我的建议是单体项目先别急着上 Redis把数据库方案做到位后面真要扛高并发再演进到预扣库存方案也不迟。缓存这块要特别说一句 MyBatis 的坑。MyBatis 一级缓存是 SqlSession 级别的在 Spring 管理的 Mapper 里每次操作通常是独立的 SqlSession一级缓存作用非常有限。二级缓存默认是关闭的很多人为了性能开启后发现商品数据更新了但查询结果还是旧的这就是缓存脏读。在这个项目里我建议不要开 MyBatis 二级缓存。如果要做缓存购物车数量、热门商品这类数据放到业务层由你手动控制过期时间或者直接引入 Redis。这样既能控制数据一致性又不至于被隐蔽的缓存问题坑到。3. Vue3 Element Plus 的 PC 端实现3.1 从零初始化 Vue3 工程前端部分我们直接从工程初始化开始。创建项目我用 Vite不用 Vue CLI因为 Vite 基于 ESBuild冷启动速度和热更新体验都比 Webpack 时代舒服太多。npm create vitelatest mall-frontend -- --template vue cd mall-frontend npm install npm install element-plus npm install element-plus/icons-vue npm install pinia vue-router axios npm install -D sass这里说一下 Sass 的安装。新版 Vite 只需要装sass依赖不再需要node-sass而且也不需要额外配置就能在style langscss中直接使用。如果发现样式不生效检查一下 Vite 版本和 sass 版本避免 Sass 的 Legacy JS API 警告导致编译失败。Element Plus 建议按官方推荐的方式按需引入直接用unplugin-auto-import和unplugin-vue-components这两个 Vite 插件组件和 API 都能自动导入打包体积会小很多。如果你不想折腾按需引入全局引入也不是不行就是首屏打包产物会到 1MB 以上自己学习无所谓做项目还是建议按需。axios 封装是前端最不能省的一步。我的习惯是创建一个request.js统一设置baseURL、超时时间在请求拦截器里从 Pinia 或 localStorage 拿 token 放到请求头在响应拦截器里统一处理 HTTP 状态码和业务状态码。import axios from axios import { ElMessage } from element-plus const request axios.create({ baseURL: import.meta.env.VITE_API_BASE_URL, timeout: 10000 }) request.interceptors.request.use(config { const token localStorage.getItem(token) if (token) { config.headers.Authorization Bearer ${token} } return config }) request.interceptors.response.use( response { const res response.data if (res.code ! 200) { ElMessage.error(res.message || 请求失败) return Promise.reject(new Error(res.message)) } return res.data }, error { if (error.response?.status 401) { ElMessage.error(登录已过期请重新登录) window.location.href /login } else { ElMessage.error(error.message || 网络异常) } return Promise.reject(error) } ) export default request这里的VITE_API_BASE_URL放到.env.development和.env.production两个环境文件里开发环境指向http://localhost:8080/api生产环境指向你的后端域名。用环境变量而不是硬编码是前后端分离项目的基本修养。3.2 仿淘宝页面的组件化拆分思路仿淘宝 PC 端页面的核心不是像素级还原而是组件抽象。首页、搜索列表页、商品详情页、购物车、结算页、订单列表页这些页面之间大量存在复用逻辑。我在实际项目中通常抽这几个公共组件ProductCard商品卡片、PaginationBar分页栏、NumberInput数量选择器、EmptyState空状态占位。商品卡片在首页、搜索页、推荐位里都会用到所以把它做成接收product对象的组件内部负责跳转详情页。状态管理用 Pinia而不是把所有数据都塞进全局状态。购物车数量、登录用户信息这类跨页面共享的数据适合放 Pinia而商品详情页这种从接口获取的单一页面数据用组件局部状态就够了。如果什么东西都往 Pinia 里放最后就是一个巨大的全局对象组件间耦合会增加调试也会变难。页面路由需要分两套用户端路由和后台管理路由。用户端包括/home、/search、/product/:id、/cart、/checkout、/orders、/login等后台管理要以/admin为前缀配置单独的子路由和布局。路由守卫的逻辑是进入购物车、结算、订单页面之前判断是否登录未登录就跳转/login并附带redirect参数进入后台管理页面之前判断当前用户角色是否为管理员。这里有一个容易忽略的点/login页面本身不能被守卫拦截否则会形成跳转死循环。3.3 跨域、拦截器与登录态控制前后端分离项目最头疼的问题就是跨域这个项目也不会例外。开发环境下浏览器访问http://localhost:5173后端跑在http://localhost:8080两者端口不同浏览器会发起同源策略检查跨域配置没做好前端请求根本发不出去。开发环境最简单的方式是配置 Vite 代理前端把所有/api开头的请求转发到后端// vite.config.js export default defineConfig({ server: { proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } })这样设置之后浏览器访问的是同源地址跨域问题在代理层就解决了。生产环境下你通常会部署 Nginx那就直接把/api反向代理到后端服务。两套方案的核心是一样的让前端请求和后端响应在同一个源下完成。后端这边同时建议加一个全局 CORS 配置作为兜底不然你在本地拿 Postman 调试没问题一接前端就开始报跨域。SpringBoot 里实现一个WebMvcConfigurer配置允许的源、请求头和请求方法即可。这里有个细节配置allowCredentials(true)时allowedOrigins不能是*必须写明确域名否则浏览器会直接拒绝。登录态控制这块我用 JWT不用传统 Session。登录成功后后端返回 token前端存到 localStorageaxios 请求拦截器统一加Authorization头。后端加一个拦截器校验 token放行登录注册接口拦截其他接口。要注意 token 失效时返回统一的 401 状态码前端响应拦截器识别到 401 后清理本地登录态并跳转登录页。如果你追求更完善的安全防护还可以在后端做一个全局过滤器对请求参数中的特殊字符做 HTML 转义和敏感词过滤防止存储型 XSS这本来也是电商后台常见的安全需求。4. MySQL 初始化、连接池与上线部署4.1 MySQL 初始化与连接池参数数据库这块建议直接用 MySQL 8.x原因很简单资料多、默认字符集处理得好、性能比 5.7 有提升。安装 MySQL 时有两个地方必须注意一个是字符集要选utf8mb4不是utf8因为utf8在 MySQL 里最多支持 3 字节存 emoji 表情和生僻字会直接报错另一个是时区问题MyBatis 连接 MySQL 8 时如果 JDBC URL 少了serverTimezoneAsia/Shanghai会直接报 CST 时区识别错误或者查询出来的时间比预期慢 8 小时。连接池我强烈建议用 HikariCPSpringBoot 2.x 之后默认集成性能比 Druid 好配置也少。如果你需要 SQL 监控、慢查询日志这种可视化功能再考虑换 Druid。两者的核心参数你要能看懂配置项HikariCPDruid说明最大连接数maximum-pool-sizemaxActive连接池能提供的最大连接数最小空闲minimum-idleminIdle空闲状态下保留的最小连接数连接超时connection-timeoutmaxWait获取连接的最大等待时间检测语句默认无需配置validationQuery保活检测 SQLDruid 通常配置 SELECT 1HikariCP 默认的maximumPoolSize是 10对仿淘宝这种项目跑单机完全够。如果你用 Druid建议maxActive设 20、initialSize设 5同时开启testWhileIdle和timeBetweenEvictionRunsMillis避免数据库空闲一段时间后连接被 MySQL 服务端切断。数据库初始化用项目自带的 SQL 脚本最省事。导入时要注意排序问题先建用户表、分类表再建商品表、购物车表最后建订单表和订单明细表。如果 SQL 脚本里有外键约束导入顺序反了会直接报错。表结构字段建议统一用下划线命名比如created_at然后 MyBatis 配置mapUnderscoreToCamelCase: true这样数据库字段到 Java 属性的映射就不用手动一个个配resultMap了。4.2 图片与静态资源上传方案商品图片、轮播图、用户头像这三类静态资源需要单独想清楚存储方案。网上很多项目直接把图片转 Base64 存数据库系统演示没问题一旦图片多了数据库会迅速膨胀接口响应也会变慢基本不是能上生产的方案。最简单的做法是本地存储。在application.yml里配置上传路径比如D:/mall/upload后端通过 MultipartFile 接收文件后保存到该目录再把访问 URL 返回给前端。这里有个关键点你需要写一个静态资源配置类把/upload/**映射到本地目录不然前端根本访问不到图片。spring: servlet: multipart: max-file-size: 10MB max-request-size: 50MB mall: upload: path: /data/mall/upload url-prefix: /upload如果你还想做得更有工程化味道推荐集成 MinIO。MinIO 是一个开源对象存储服务项目里集成它并不复杂引入minio依赖写一个配置类和工具类然后上传时调用putObject就能得到文件访问地址。Configuration public class MinioConfig { Value(${minio.endpoint}) private String endpoint; Value(${minio.access-key}) private String accessKey; Value(${minio.secret-key}) private String secretKey; Bean public MinioClient minioClient() { return MinioClient.builder() .endpoint(endpoint) .credentials(accessKey, secretKey) .build(); } }MinIO 的优势是后续做分布式部署、做图片 CDN 加速都比较顺。我的建议是开发阶段用本地存储省事生产部署时无缝切换到 MinIO两边接口保持一致不会造成大量代码改动。4.3 打包部署jar 包加 Nginx 反向代理项目能本地跑通只是第一步部署上线才是完整闭环。后端打包用 Maven注意打包前要跑测试用例的话可能比较耗时直接跳过mvn clean package -DskipTests打包完成后在target目录生成mall-0.0.1-SNAPSHOT.jar。部署时直接扔到服务器上运行nohup java -jar mall-0.0.1-SNAPSHOT.jar --spring.profiles.activeprod app.log 21 前端打包npm run build生成的dist目录就是纯静态文件把它放到 Nginx 的 web 根目录再配置一个反向代理把/api请求转发给后端的 8080 端口server { listen 80; server_name localhost; root /usr/share/nginx/html; index index.html; location / { 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; } location /upload/ { alias /data/mall/upload/; } }Nginx 配置里最容易踩的坑是前端路由。Vue3 使用 history 模式路由后直接刷新/product/123页面Nginx 会去磁盘找这个文件找不到就 404。所以必须加try_files $uri $uri/ /index.html这行让所有刷新请求回退到index.html再交给前端路由去解析。后端接口走/api前缀的好处在这里也体现得特别明显静态文件请求和 API 请求可以干净分离。关于部署还有一个常见的疑问就是拿到一个 jar 包后怎么反编译回源码。Java 程序编译出来的 class 可以通过 CFR、JD-GUI、Procyon 这类工具反编译还原成 Java 代码反编译出来的代码虽然不能 100% 还原注释和泛型信息但作为找回源码片段、学习代码逻辑是完全够用的。不过我要提醒一句反编译只适用于你自己的项目或其他开源项目拿别人有版权的商业软件反编译去复用是侵权行为别干这种事。5. 高频坑位与优化实录5.1 开发期必踩的五个问题这个项目做下来我记录了五个高频问题可以说每个都至少浪费过我半天时间。第一个是 MySQL 8 的时区问题。现象是后端插入的时间数据在数据库里看是对的但接口查询返回给前端的时间比实际时间少了 8 小时。解决办法是在 JDBC URL 里显式加serverTimezoneAsia/Shanghai同时确认 MySQL 服务端时区设置正确。第二个是 axios 请求接口时浏览器控制台报跨域。很多人一看到跨域就去后端配 CORS但如果你已经用了 Vite proxy那问题就不在 CORS而在于请求是否走了/api前缀。检查一下前端 baseURL 是否写成了完整地址如果是http://localhost:8080/api就不会走代理一定要写成/api这种相对路径。第三个是 Element Plus 的图标不显示。按需引入组件时图标需要单独在需要的地方手动注册如果只引入了组件没引入图标页面上的图标就会显示为空白。解决方法是在main.js或某个index.js里统一注册需要的图标import * as ElementPlusIconsVue from element-plus/icons-vue for (const [key, component] of Object.entries(ElementPlusIconsVue)) { app.component(key, component) }第四个是 MyBatis 查询结果某些字段为 null。这个大概率是数据库下划线字段和 Java 驼峰属性没对上。检查application.yml是否配置了map-underscore-to-camel-case: true或者手动写resultMap指定映射关系。第五个是用户快速下单导致重复订单。前端连续点击提交按钮后端生成了多笔订单。这个问题要从两端解决前端点击后给按钮加 loading 状态防止重复提交后端也需要做幂等控制最简单的方式是订单创建接口要求前端提交一个唯一的请求号后端判断该请求号是否已处理过处理过就直接拒绝。5.2 性能与安全加固项目能跑通之后就该考虑它够不够稳、够不够安全。性能这块最立竿见影的是加索引。商品列表按分类查询category_id字段的索引必须加商品状态过滤要覆盖status高频搜索关键词LIKE %xxx%场景下普通索引其实吃不上力只能靠全文检索或搜索引擎来解决这个后面扩展方向里我会说。订单表按用户查询订单列表是最高频操作(user_id, status)联合索引也建议加上。索引不是越多越好但电商这种读写模式清晰的系统订单表和商品表的索引收益是很明显的。安全方面SQL 注入是 MyBatis 必须守住的底线。#{}是预编译占位符${}是字符串拼接。模糊查询、排序字段、拼 SQL 的地方除非你能确认值来自白名单否则一律用#{}这个是原则问题。越权漏洞也非常常见比如用户 A 通过篡改请求参数访问用户 B 的订单这种问题在写接口时必须留意查询购物车和订单时强制带上当前登录用户 ID而不是只依赖前端传的参数来拼 SQL前端传参可以作为辅助但不能作为唯一的查询条件。如果想对自己的后端做一次 XSS 安全加固可以仿照我在前面提到的思路写一个全局过滤器对请求体的文本参数做 HTML 实体编码对富文本字段做白名单标签过滤这样能最大程度减少存储型 XSS 的隐患。5.3 作为学习项目如何让价值翻倍最后聊一聊怎么把这个项目用好。老实说仿淘宝系统的源码并不稀缺真正值钱的不是把代码跑起来而是你能讲清楚每个模块为什么这么设计并且能在项目上做出有区分度的改进。如果你拿去当毕业设计或简历项目我会建议你做以下三到五个改造会让项目的价值和面试含金量立刻提升一个档次。第一个改造是引入 Redis 做热门商品缓存和购物车数量的临时存储可以在简历上写“通过缓存降低数据库访问压力”第二个改造是引入 RabbitMQ 做订单超时未支付自动取消模拟真实电商的延迟消息场景第三个改造是把商品搜索从 MySQL 的 LIKE 查询替换成 Elasticsearch前端搜索体验会明显变好第四个相对轻量集成 HanLP 做商品搜索分词让搜索在中文语境下更聪明效果好的同时实现难度也远低于上 ES第五个是后台管理增加数据导出功能用 EasyExcel 导出商品列表和订单报表比 POI 轻量太多也不会牵扯到 POI 生成图表那些看似高大上、实际落地很鸡肋的问题。做完这些改造项目就不只是一个“仿淘宝”而是一个有优化思路的完整电商系统。面试的时候你要能闭着眼睛讲出几条核心链路。比如用户下单时请求经过前端拦截器加 token、后端 Controller 接收参数、Service 开启事务、Mapper 更新库存、订单表和明细表写入、最后返回订单号——每一步做了什么、失败了怎么回滚、库存扣超了怎么办。能把一条链路的逻辑讲通比背一百个八股文都管用。项目里的难点比如库存防超卖、订单号生成、跨域方案每一个都是可以拿出来深入聊几分钟的话题。我个人在跑完这套项目后最大的体会是这种全栈项目最磨人的不是某一个技术点的深度而是数据在前后端之间流转的“链路感”。你得同时盯着后端日志和浏览器控制台看请求参数、响应结构、字段命名是否对得上耐心反而是最重要的能力。给初学者的建议是不要把全部精力放在“我要做个一模一样的淘宝”上先跑通一个最小闭环用户注册登录、浏览商品、加入购物车、提交订单。这个闭环跑通了后面所有模块都是在给它添砖加瓦。最后再分享一个我一直在用的小技巧写完每个接口都要用 Postman 或者 Apifox 存一个测试用例前后端对接口时能省下大量反复沟通的时间。项目做到最后你积累的不只是代码还有一套属于自己的调试方法这才是这类实战项目最有价值的部分。