企业官网建设流程全解析

最近把一套宠物用品交易网站重新整理成了前后端分离版本，项目核心链路从商品浏览、加入购物车、模拟支付下单，一直做到订单管理和后台运营，技术栈就是标题里那套：SpringBoot提供RESTful API，Vue负责页面交互，MyBatis做数据库访问，MySQL存业务数据。这篇内容我把整个项目的设计思路、关键代码、部署流程都过一遍，一些只有实际动手才会踩到的坑也一并写出来。正在找毕业设计方向，或者想系统练一遍前后端分离开发流程的朋友，这份记录可以直接拿来参考，甚至改一改就能复用到其他垂直电商项目上。

1. 项目定位与需求拆解：为什么拿垂直电商练手

1.1 用户侧和管理侧的功能边界

商城系统的开发，第一步不是写代码，而是先分清“谁能干什么”。我把整个系统拆成用户端和管理端两条线，每条线拉出独立的功能清单，所有页面和接口都从这里导出。

用户端走的是购物主流程：注册登录、首页浏览、商品列表和详情、分类筛选、加入购物车、结算下单、模拟支付、订单列表、确认收货、商品评价，另外还有个人资料、收货地址管理、收藏夹这类基础功能。管理端走的是运营流程：商品上架、编辑、下架，库存调整，分类管理，订单发货和售后处理，用户账号管理，首页轮播图配置，以及简单的订单销量统计。

需求拆解这一步很多人会跳过，结果开发到一半发现漏了“取消订单”这种接口，再回头补就很被动。我习惯把每个功能写成“页面 + 请求方法 + 路径 + 是否可以匿名访问”的清单，后面联调阶段直接对照清单勾进度，既防遗漏也方便分工。

1.2 宠物垂直领域的特殊需求点

选宠物用品而不是做通用电商，是我刻意为之的。通用电商的SKU逻辑很复杂，服装要处理颜色尺码，数码要处理型号配置，新手很容易陷进规格组合的泥潭。宠物用品大部分是标准单品，可以把核心流程跑通，再考虑扩展规格维度。

宠物商品天然带品类属性，字段设计有层次感。我用了适用宠物类型（犬、猫、水族、爬宠、小宠）、适用年龄段（幼宠、成宠、老龄）、使用场景（主粮、零食、玩具、洗护、医疗保健）这三个维度来做商品筛选，比单纯“商品名称+价格”的练习项目有意思得多。前端界面上也能做出更年轻化的视觉风格，让整个项目看起来不像千篇一律的管理系统。

另一个实际原因是宠物消费复购率高，用户体系的粘性比普通百货更明显，所以注册、地址管理、历史订单这些功能值得认真做。业务上还有一个注意点：有些宠物商品存在“禁忌人群”或“使用禁忌”，比如某些驱虫药对猫有毒，商品详情页我预留了提示字段，这一点虽然不在核心技术范围内，但设计时提前留下了位置。

2. 技术选型逻辑：四个组件各自的分工与配合

2.1 为什么用SpringBoot而不是传统SSM

早些年做Java Web项目，SSM是标配，Spring+SpringMVC+MyBatis，但配置量相当痛苦，applicationContext.xml、spring-mvc.xml、web.xml动辄几百行。SpringBoot改变了这件事，它把“配置”变成了“约定”，内嵌Tomcat，入口类一个main方法直接启动，依赖管理用starter统一处理。

在这套商城系统里，SpringBoot承担三件事：对外提供RESTful API接口，用拦截器Web层鉴权，以及通过事务机制保证订单和库存的数据一致性。如果还抱着SSM做，光环境搭建就要耽误半天，这些时间省下来都花在业务逻辑上更有价值。

2.2 Vue、MyBatis、MySQL各自的不可替代性

Vue最核心的价值是响应式数据绑定和组件化。商城页面交互非常密集：购物车数量加减、复选框全选反选、价格实时汇总、搜索条件联动，这些场景如果用jQuery手动操作DOM，代码会越写越绕。Vue的数据驱动模式只要修改状态，页面自动刷新，逻辑链路清爽很多。配合Vue Router管理页面跳转，Pinia（或Vuex）维护用户信息、购物车数量这种跨页面共享的全局状态，整套前端结构就很清晰了。

MyBatis是半自动ORM，SQL该写还是自己写，但参数注入、结果集映射交给框架完成。电商查询条件复杂，分类、关键字、价格区间、销量排序经常组合出现，这种场景用MyBatis的<where>加<if>动态SQL来处理，可控性极强。相比全自动的JPA，MyBatis在优化SQL时也更直接，一条慢查询可以直接在XML里改，不绕弯子。

MySQL其实是“不折腾”的选择。商城系统最敏感的是订单和库存的一致性，InnoDB事务可以保证“扣库存+生成订单”要么都成功、要么都回滚。加上它成熟、文档多、部署简单，学费成本最低，即使遇到疑难问题，搜索引擎上基本都有答案。

2.3 前后端分离的代价与真实收益

前后端分离不是银弹，这点必须说清楚。收益是明摆着的：前端可以独立部署，静态资源能上CDN；后端只暴露接口，Web、小程序、App都能共用一套；团队并行开发时，前端不阻塞后端，后端也不阻塞前端。

代价同样真实存在——联调成本。前后端分离后，跨域问题、token鉴权方式、接口规范都得额外花精力管理。项目早期我用Session保存登录状态，前后端一分离才发现跨域场景下Session的维护非常别扭，索性换成了JWT方案。如果你是一个人独立开发，分离模式确实比单体多一套调试开销，但从学习主流开发模式的角度看，这笔学费必须交。

3. 数据库设计：用十张表撑起整个商城业务闭环

3.1 核心表的落地方案

我把全部表分成三类：基础数据、交易数据、扩展数据。基础数据包括user用户表、category分类表、product商品表、banner轮播图表；交易数据包括cart_item购物车表、address收货地址表、orders订单主表、order_item订单明细表；扩展数据是favorite收藏表和comment评论表。

缩略版建表SQL如下，生产环境还要补充外键索引和更多可选字段，先看骨架：

CREATE TABLE `user` ( `id` BIGINT NOT NULL AUTO_INCREMENT COMMENT '主键', `username` VARCHAR(50) NOT NULL COMMENT '用户名', `password` VARCHAR(100) NOT NULL COMMENT 'BCrypt加密后的密码', `nickname` VARCHAR(50) DEFAULT NULL COMMENT '昵称', `phone` VARCHAR(20) DEFAULT NULL COMMENT '手机号', `avatar` VARCHAR(255) DEFAULT NULL COMMENT '头像地址', `role` TINYINT NOT NULL DEFAULT 0 COMMENT '0-普通用户 1-管理员', `status` TINYINT NOT NULL DEFAULT 1 COMMENT '1-正常 0-禁用', `create_time` DATETIME NOT NULL COMMENT '创建时间', PRIMARY KEY (`id`), UNIQUE KEY `uk_username` (`username`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户表'; CREATE TABLE `product` ( `id` BIGINT NOT NULL AUTO_INCREMENT, `category_id` BIGINT NOT NULL COMMENT '所属分类', `name` VARCHAR(100) NOT NULL COMMENT '商品名称', `subtitle` VARCHAR(255) DEFAULT NULL COMMENT '副标题', `main_image` VARCHAR(255) DEFAULT NULL COMMENT '主图', `detail` TEXT COMMENT '详情', `price` DECIMAL(10,2) NOT NULL COMMENT '售价', `original_price` DECIMAL(10,2) DEFAULT NULL COMMENT '原价', `stock` INT NOT NULL DEFAULT 0 COMMENT '库存', `sales` INT NOT NULL DEFAULT 0 COMMENT '销量', `pet_type` TINYINT DEFAULT NULL COMMENT '适用宠物类型', `age_stage` TINYINT DEFAULT NULL COMMENT '适用年龄段', `usage_scene` TINYINT DEFAULT NULL COMMENT '使用场景', `status` TINYINT NOT NULL DEFAULT 1 COMMENT '1-上架 0-下架', `create_time` DATETIME NOT NULL, `update_time` DATETIME NOT NULL, PRIMARY KEY (`id`), KEY `idx_category` (`category_id`), KEY `idx_pet_type` (`pet_type`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='商品表';

所有表统一使用InnoDB引擎和utf8mb4字符集，前者保证事务支持，后者保证像🐱这类emoji造型的业务数据能正常存储。商品表里pet_type、age_stage、usage_scene用了TINYINT字典值，而不是直接存中文，这样筛选查询走索引更快，前端再做字典映射展示。

3.2 订单表设计：状态机与数据快照

订单表是商城系统的核心，设计上有两个关键点：快照字段和状态字段。

快照的意思是，订单金额、商品名称、单价都必须冗余保存在订单表里，而不是查询时去关联商品表。因为商品价格和名称会变，如果订单只保存商品id，商家改价之后历史订单就成糊涂账了。order_item表里我专门存了product_name、product_image、price_snapshot（成交单价）、quantity四个快照字段。

订单状态我定义成TINYINT字典值：

用数字存状态而不是字符串，主要为了索引效率和判断简洁。前端通过接口拿到状态值，再映射成“待付款”“已发货”这种文案展示。业务层针对每种流转写独立方法，不允许直接改status字段，这样即便前端漏隐藏了某个按钮，后端也能拦住非法跳转。

3.3 索引、金额与主键的三个硬性取舍

索引设计不能拍脑袋，要根据查询语句来。商城里最频繁的查询是商品列表按分类筛选，所以category_id必须建索引；用户查自己的订单，orders.user_id必须建索引；购物车查询按user_id走，同样要建。另外购物车表我加了(user_id, product_id)联合唯一约束，防止同一样商品被重复加入，前端按钮触发两次也不会出现两条脏数据。

金额字段必须用DECIMAL(10,2)，这是我在项目里最坚持的一点。浮点数的二进制存储天然有精度问题，0.1+0.2不等于0.3这种事放在商城领域是致命的，哪怕只差一分钱，用户投诉都解释不清。涉及钱的数据，宁可多用几个字符也要保精度。

主键统一用自增id，业务字段如手机号、邮箱都不适合当主键。手机号可以换绑，邮箱可能忘了改，一旦主键变更，所有关联表全部遭殃。自增id是无意义的，变更风险为零，性能表现也稳妥。

4. 后端核心实现：JWT鉴权、动态SQL与订单状态机

4.1 JWT鉴权：从登录到拦截校验的完整链路

前后端分离场景下，Session方案要处理跨域Cookie、多端会话保持，非常别扭，我直接换成了JWT。流程不复杂：用户登录成功，后端签发一个JWT字符串返回给前端；前端存到localStorage，每次请求在请求头携带Authorization: Bearer <token>；后端拦截器解析校验token，通过后把当前用户信息放入request属性，Controller就能直接读取了。

核心工具类用JJWT实现：

public class JwtUtil { private static final String SECRET = "pet-mall-secret-key"; private static final long EXPIRE_MS = 24 * 60 * 60 * 1000L; public static String generateToken(Long userId, Integer role) { Date now = new Date(); Date expireAt = new Date(now.getTime() + EXPIRE_MS); return Jwts.builder() .setSubject(userId.toString()) .claim("role", role) .setIssuedAt(now) .setExpiration(expireAt) .signWith(SignatureAlgorithm.HS256, SECRET) .compact(); } public static Claims parseToken(String token) { return Jwts.parser().setSigningKey(SECRET).parseClaimsJws(token).getBody(); } }

拦截器里做统一鉴权。放行登录、注册、商品浏览、首页轮播等公开接口，其余接口解析token，解析失败直接返回401。实现HandlerInterceptor，在preHandle里完成校验后，把userId塞进request的attribute，后续Controller拿起来非常方便。

密码存储这里也多说一句：DB里的password字段存的是BCrypt加盐哈希结果，不是明文，也不是简单MD5。MD5在现代硬件环境下跑字典攻击太容易了，BCrypt内置盐值、计算成本可调，是目前社区公认的稳妥方案。

4.2 MyBatis动态SQL实现商品分页筛选

商品列表页的筛选维度多且不固定：分类、关键字、价格区间、排序方式，有的请求带了这些参数，有的没带。用MyBatis的动态SQL判断条件，能把查询条件拼接得干净利落：

<select id="selectProductList" resultType="com.example.petmall.entity.Product"> SELECT * FROM product <where> <if test="categoryId != null"> AND category_id = #{categoryId} </if> <if test="keyword != null and keyword != ''"> AND name LIKE CONCAT('%', #{keyword}, '%') </if> <if test="minPrice != null"> AND price &gt;= #{minPrice} </if> <if test="maxPrice != null"> AND price &lt;= #{maxPrice} </if> </where> ORDER BY <choose> <when test="sort == 'price_asc'">price ASC</when> <when test="sort == 'price_desc'">price DESC</when> <when test="sort == 'sales_desc'">sales DESC</when> <otherwise>create_time DESC</otherwise> </choose> LIMIT #{offset}, #{pageSize} </select>

这里有三个细节很容易踩坑。第一，#{}是预编译占位符，能防SQL注入；排序字段列名不能用#{}，所以用了${sort}加<choose>白名单校验，绕过了注入风险。第二，XML里的>、<符号必须转义成>、<，不然XML解析直接报错。第三，分页手写LIMIT适合中小数据量，如果后续商品过十万条，再考虑引入PageHelper插件。

4.3 订单创建的Service实现与状态流转控制

下单是一个跨表的写操作，必须保证原子性。我把它放在一个@Transactional方法里，逻辑顺序是：校验商品状态和库存，依次扣减库存并增加销量，创建订单主表记录，批量创建订单明细快照，清空对应购物车项，最后返回订单号。

@Transactional(rollbackFor = RuntimeException.class) public OrderVO createOrder(Long userId, List<CartOrderItem> items, Long addressId) { // 1. 查询并校验库存 // 2. 计算总金额（以数据库商品单价为准） BigDecimal totalAmount = calculateTotal(items); // 3. 创建订单主记录 Order order = new Order(); order.setUserId(userId); order.setStatus(0); // 待付款 order.setTotalAmount(totalAmount); order.setAddressSnapshot(...); orderMapper.insert(order); // 4. 批量插入order_item快照 // 5. 更新库存/销量 // 6. 删除购物车选中项 return new OrderVO(order.getId(), totalAmount); }

这一步最容易出问题的是事务回滚范围。Spring默认只对RuntimeException回滚，如果自定义业务异常继承的是Exception，扣了库存但订单没插进去，库存也回不去了。我统一让所有自定义异常继承RuntimeException，并且事务注解上显式声明rollbackFor = RuntimeException.class，双保险。

状态流转设计上，我在Service层写了payOrder、cancelOrder、deliverOrder、completeOrder这些业务方法，每个方法内部先查当前状态，再判断能否流转到目标状态。比如cancelOrder只允许status=0时执行，已经支付的订单只能走退款流程。整套状态机在业务层封死，前端怎么操作都绕不过去。

5. 前端页面构建：工程结构、请求封装与角色路由

5.1 工程结构与axios拦截器封装

前端基于Vue生态初始化，目录划分是后面维护不乱的根基：

src/ api/ // 接口定义与axios实例 assets/ // 图片、样式 components/ // 通用组件，如商品卡片、分页器 router/ // 路由配置 store/ // Pinia全局状态 views/ // 页面级组件 admin/ // 管理端页面 Home.vue, ProductList.vue, Cart.vue ...

axios封装是整个前端请求的基础设施。请求拦截器负责给每个请求自动带上token，响应拦截器统一处理业务码和HTTP错误，抽出来之后页面上所有请求代码都不用重复写鉴权和错误处理。

import axios from 'axios' const service = axios.create({ baseURL: '/api', timeout: 10000 }) service.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers['Authorization'] = 'Bearer ' + token } return config }) service.interceptors.response.use( response => { const res = response.data if (res.code !== 200) { // 全局错误提示 return Promise.reject(new Error(res.message)) } return res }, error => { if (error.response && error.response.status === 401) { // token失效，清理本地状态并跳转登录 localStorage.removeItem('token') router.push('/login') } return Promise.reject(error) } ) export default service

5.2 路由守卫与用户端管理端的权限隔离

用户端和管理端共用一个前端工程，但页面权限必须分隔。路由配置里用meta标记是否需要登录、是否需要管理员权限，然后由全局前置守卫统一拦截。

router.beforeEach((to, from, next) => { const token = localStorage.getItem('token') const role = localStorage.getItem('role') if (to.meta.requiresAuth && !token) { next({ path: '/login', query: { redirect: to.fullPath } }) return } if (to.meta.requiresAdmin && role !== '1') { next('/') return } next() })

前端守卫只解决体验问题，真正的安全边界在后端。管理端接口会二次校验token里的role字段，即使有人通过浏览器控制台伪造路由，后端拿不到管理员身份依然拒绝服务。这个“前端防君子、后端防小人”的原则，我在项目里反复强调了多次。

5.3 购物车与订单确认页的状态同步思路

购物车页是前端状态交互最密集的地方。我用Pinia维护一个购物车数组，包含商品信息、数量、勾选状态。勾选、反选、全选、数量加减都通过action更新state，总价则用计算属性派生，这样数据流是单向的，不会出现“页面显示总价和实际勾选不一致”的诡异bug。

关键的一点是，前端计算出来的总价只用于展示，提交订单时后端会依据数据库单价重新计算。如果后端直接信任前端传过来的金额，把请求里的price改小就能低价下单，这是电商系统最不应该出现的漏洞。我给后端下单接口只传购物车项id和地址id，所有价格都由后端算。

6. 前后端联调：接口规范、跨域处理与调试三板斧

6.1 统一返回结构和RESTful接口约定

接口约束直接决定联调效率。所有后端接口都返回统一的JSON结构：

{ "code": 200, "message": "操作成功", "data": {} }

code是业务状态码，200代表成功；message用于前端全局提示；data是真正的业务载荷。这样前端封装一层后，页面代码只需关注res.data。

路径设计遵循RESTful风格，资源用名词复数：

接口路径一旦确定就尽量不改。项目前期我建议把接口清单导出成表格或者用接口文档工具维护，前端和后端按文档并行开发，联调阶段就不会出现“你说改了，我还在调旧接口”的误会。

6.2 CORS跨域处理：配置背后的原理

前后端分离后，前端跑在8080端口，后端跑在8081端口，请求必然跨域。解决方案在后端加一个全局CORS过滤器，允许前端来源访问。

@Configuration public class CorsConfig { @Bean public CorsFilter corsFilter() { CorsConfiguration config = new CorsConfiguration(); config.addAllowedOriginPattern("*"); config.addAllowedMethod("*"); config.addAllowedHeader("*"); config.setAllowCredentials(true); config.setMaxAge(3600L); UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource(); source.registerCorsConfiguration("/**", config); return new CorsFilter(source); } }

这里有个容易出错的细节：当allowCredentials设为true时，浏览器不允许Access-Control-Allow-Origin为通配符*，必须指定具体来源或使用OriginPattern。很多人网上抄配置要么不写Credentials，要么写*，结果带Cookie或自定义Header的请求被浏览器拦下来，排查半天。

6.3 联调阶段最高效的三个调试习惯

联调出问题，先用浏览器Network面板看完整请求响应，再动手改代码。很多时候后端逻辑没问题，是前端请求参数缺字段，或者字段名拼写不一致。Network里能同时看到请求头、参数、响应体，是前后端交界处最直接的证据。

第二个习惯是把后端关键接口的入参打日志。比如下单接口我加了一行log.info("创建订单 userId:{} items:{}", userId, items)，前端传错参数时，后端日志一眼就能看到真实数据，不用来回截图猜。生产环境加日志要控制级别，但开发联调阶段打得越细越好。

第三个习惯是用好前端开发工具。Vue项目打开Vue Devtools，检查组件state是否符合预期；如果页面渲染了错误数据，先看store里数据源对不对，再判断是接口问题还是渲染逻辑问题。按照“接口层→状态层→视图层”的顺序排查，定位效率比盲目改代码高得多。

7. 部署上线全流程：打包、Nginx反向代理与三个实测坑

7.1 后端jar包打包与systemd进程守护

后端部署非常简单，Maven构建出一个可执行jar包，服务器装好JDK和MySQL后，一条命令就能跑：

mvn clean package -DskipTests # 生成 target/pet-mall-server.jar nohup java -jar pet-mall-server.jar --spring.profiles.active=prod &

生产环境我建议不要用裸nohup，因为它不能自动重启。用systemd配置成系统服务，进程崩了会自动拉起，服务器重启也能自动恢复运行。

数据库配置方面写一份application-prod.yml，生产库地址、用户名、密码通过环境变量注入，不要把明文密码写进代码仓库。哪怕项目是私有仓库，环境分离的习惯也要从第一天养成，不然后面接手项目的人会被密码硬编码坑得欲哭无泪。

7.2 前端构建产物与Nginx多层级配置

前端部署分两步：本地构建，服务器托管。

npm run build # 生成 dist 目录，上传到服务器 /var/www/pet-mall/

Nginx是静态托管和反向代理的一把好手。配置分三层：静态资源root指向dist目录，index入口指向index.html；SPA路由history模式必须配try_files，否则刷新二级页面直接404；/api/前缀的请求反向代理到后端jar包端口。

server { listen 80; server_name your-domain.com; client_max_body_size 10m; location / { root /var/www/pet-mall; index index.html; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8081; 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 ~* \.(js|css|png|jpg|jpeg|gif|ico|svg|woff2)$ { expires 7d; add_header Cache-Control "public"; } }

静态资源加缓存能显著提升首屏速度，但注意try_files和缓存不要冲突，入口html不要设长缓存，否则发新版后用户一直加载旧页面。我的做法是只给/index.html设置no-cache，其余js、css、图片走7天缓存，内容更新靠文件哈希号变化刷新。

7.3 这个项目里实测的四个坑，每一个都卡过一晚上

第一个坑是XML里的小于号。商品价格区间查询写AND price <= #{maxPrice}，运行直接报XML解析错误。原因是XML标签属性里不允许裸<，必须转义成<或用<![CDATA[]]>包起来。这个问题百度一下能搜到，但没遇到过的人第一眼根本想不到是符号转义问题。

第二个坑是Vue项目构建内存溢出，日志报JavaScript heap out of memory。因为前端依赖包体积大，Node默认堆内存不够。解决办法是给构建脚本加参数：

{ "scripts": { "build": "node --max_old_space_size=4096 node_modules/.bin/vite build" } }

如果是Windows环境，直接这样写可能不生效，配合cross-env设置NODE_OPTIONS=--max_old_space_size=4096再执行构建，两边环境都稳妥。

第三个坑是JWT过期时间。起初我把token有效期设成了7天，结果用户改了密码旧的token依然有效，超级尴尬。后来把有效期压到24小时，并加了一个简单的token失效策略：改密码、管理员禁号时，把这批token的jti记录到Redis黑名单，过期时间与token一致。如果你是纯数据库方案，也可以建一张invalid_token表，效果类似。

第四个坑跟Nginx的history路由有关。第一次部署时把try_files写漏了，访问首页一切正常，从首页点到商品详情也没事，但在详情页手动刷新浏览器直接404。这正是SPA的history模式特性：路由是前端模拟的，服务器并没有对应路径文件。加上try_files $uri $uri/ /index.html后，刷新请求会统一回退到index.html，由前端路由重新匹配，问题就解决了。

做完这些，这套项目从本地开发到线上可访问的完整链路就全部通了。回看整个整理过程，技术本身没有多高深，真正的价值在于把SpringBoot、Vue、MyBatis、MySQL这四个流行组件用一套完整业务串起来，再经历了联调、部署、修坑的真实打磨。如果你也想拿它练手，建议不要只跑demo，而是从数据库设计开始自己重写一遍核心模块，遇到报错就自己查，踩过的坑才是真正学到的东西。