前后端分离的ONLY在线商城实战：SpringBoot+Vue+MyBatis+MySQL全栈实现

前后端分离、SpringBoot、Vue、MyBatis、MySQL，这几个技术词放一起，基本就是国内中小型电商项目最常见的标准模板。我今天要拆解的这套ONLY在线商城系统，就是把这套组合从头到尾跑通的实战项目，完整源码、SQL脚本、部署流程都有。项目名字里的ONLY是我随手起的代号，跟任何服装品牌没关系，大家直接把它当一套普通商城项目看就行。

这套系统本身不算重，但电商的核心链路全部覆盖了：前台用户能注册登录、浏览商品、加购物车、下单付款；后台管理员能管理商品分类、处理订单、管理用户。对正在学SpringBoot+Vue的初学者来说，它是一个可以把前后端如何协作、接口怎么设计、部署怎么落地彻底搞明白的绝佳样例；对需要快速搭演示项目的朋友来说，按这篇文章的步骤操作，基本一下午就能把整套系统跑起来。

1. 项目概述：这套商城到底做了什么

1.1 核心功能与页面地图

我在设计这套商城的时候，没有一上来就堆功能，而是先把角色拆清楚。系统只有两类用户：普通买家和后台管理员，所以页面也分成两个端口。

买家端主要页面有：首页、商品列表页、商品详情页、购物车、订单结算页、我的订单、个人中心、登录注册。管理员端主要页面有：后台首页看板、商品管理、商品分类、订单管理、用户管理。整体逻辑就是买家下单，管理员接单发货，这就是最基础的B2C闭环。

功能点拆开看：

• 用户模块：注册、登录、JWT鉴权、个人资料修改、收货地址维护。
• 商品模块：分类浏览、商品列表分页、商品搜索、商品详情、上下架状态控制。
• 购物车模块：加入购物车、修改数量、勾选商品、删除商品。
• 订单模块：提交订单、生成订单明细、模拟支付、查看订单列表、确认收货。
• 后台模块：商品CRUD、分类CRUD、订单状态操作、用户列表查看。

这里没有做秒杀、优惠券、积分商城这类复杂的营销玩法。原因很简单：第一版项目最重要的是把主干链路做稳，电商的骨架先立起来，后续要加营销功能，在表结构和代码分层都合理的前提下扩展并不难。

1.2 技术栈选型与理由

有人问为什么不用MyBatis-Plus，而是用原生的MyBatis。我的想法很简单：如果你连原生MyBatis的Mapper接口、XML映射、动态SQL都写过一遍，后面再用Plus是非常容易的；反过来，一开始就用Plus，遇到复杂查询和SQL优化时会很被动。商城项目里有不少多表关联和条件统计的SQL，原生MyBatis能让我完全掌控SQL，出现性能问题也知道怎么改。

1.3 前后端分离架构的工作方式

前后端分离不等于两个项目各写各的，重点是它们通过HTTP接口通信。前端只负责页面渲染和用户交互，后端只负责业务逻辑和数据持久化，两者通过约定的JSON数据格式对接。

在这套ONLY商城里，后端统一返回一个Result对象，结构如下：

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

前端的axios封装统一处理这个结构，code为200时取data，code为401时跳登录页。这样不管是商品列表还是下单接口，前后端都遵守同一套协议，省去了大量沟通成本。

目录结构上也做了明确分层。后端按照Controller、Service、Mapper、Entity四层划分，前端按照views、router、store、api、utils划分。这套结构说不上多高级，但它足够清晰，后文我会逐个模块展开讲。

2. 系统设计思路：数据库与接口先想清楚

2.1 数据库表结构设计

我在动手写代码之前，花了不少时间设计数据库表。表结构如果设计不合理，后面写SQL和业务逻辑会相当痛苦。这套商城最终落地的核心表有9张，我整理成表格方便对照。

商品表单独拆一张product_image表，是因为一个商品通常有多张图片，如果全塞在product表里的image字段里，用逗号拼接也可以，但后续要单独维护图片排序和主图时会很麻烦。用子表的方式更规范，查询时一对多关联即可。

订单表里存了address_snapshot字段，这个是快照数据。因为用户下单后如果修改了收货地址，订单历史里的地址不应该跟着变。这个细节很多人会忽略，但实际电商里非常重要。同样的道理，order_item里冗余了product_name和product_image，也是为了让订单数据不依赖商品表的变化。

2.2 订单状态与支付逻辑

订单模块是电商系统里最绕的部分。我设计了两个状态字段：status和pay_status。

status表示订单生命周期状态：

• 0：待支付
• 1：待发货（已支付）
• 2：待收货（已发货）
• 3：已完成
• 4：已取消

pay_status表示支付状态：

• 0：未支付
• 1：已支付

可能有人问：status为“待支付”的时候pay_status一定为0，为什么还要单独存一个支付状态？因为后续如果接入真实支付，会出现“已支付但订单还没发货”的中间状态，而且退款逻辑也依赖支付状态，分开存能避免状态机混乱。

模拟支付的实现也很简单，用户下单后跳到支付页面，点击“确认支付”，后端直接调用一个本地支付模拟接口，把pay_status更新为1，status更新为1。如果接入支付宝沙箱或微信支付，只需要替换这个支付接口即可，订单核心逻辑完全不用改。

2.3 接口设计要点

前端和后端是并行开发的，所以接口文档必须先行。我没有用特别重的接口管理工具，直接在项目里维护了一份接口清单，约定好请求方式和参数。

几个核心接口示例：

接口路径上我特意区分了/api和/admin两个前缀，目的是方便后端做权限拦截。普通用户接口需要登录后访问，后台接口必须管理员权限才能访问，拦截器里通过路径前缀就能快速判断。

3. 后端核心实现：SpringBoot + MyBatis + MySQL

3.1 工程初始化与统一返回结构

后端工程我用Spring Initializr创建，基础依赖选了Spring Web、MyBatis、MySQL Driver，后面再手动加了JWT相关的jjwt依赖。application.yml里最关键的配置是数据源和MyBatis的mapper位置。

yaml复制server:
  port: 8080

spring:
  datasource:
    url: jdbc:mysql://localhost:3306/only_mall?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai&allowPublicKeyRetrieval=true
    username: root
    password: 123456
    driver-class-name: com.mysql.cj.jdbc.Driver

mybatis:
  mapper-locations: classpath:mapper/*.xml
  type-aliases-package: com.only.mall.entity
  configuration:
    map-underscore-to-camel-case: true

那个map-underscore-to-camel-case=true非常关键。数据库字段是address_snapshot，Java属性是addressSnapshot，开启这个配置后MyBatis会自动映射，不用每个字段都写resultMap。

统一返回Result类也很简单，就是一个泛型类，包含code、message、data三个字段。配合全局异常处理器，不管业务异常还是系统异常，都能返回规范格式给前端。

java复制@Data
public class Result<T> {
    private Integer code;
    private String message;
    private T data;

    public static <T> Result<T> ok(T data) {
        Result<T> r = new Result<>();
        r.setCode(200);
        r.setMessage("操作成功");
        r.setData(data);
        return r;
    }

    public static <T> Result<T> error(String message) {
        Result<T> r = new Result<>();
        r.setCode(500);
        r.setMessage(message);
        return r;
    }
}

很多初学者喜欢在Controller里直接返回Map或者Entity，这样会导致前端拿到的数据结构不统一，联调时很痛苦。统一Result后，前端class Api里只需要处理三次：成功、业务失败、未登录。

3.2 JWT登录鉴权与拦截器

登录鉴权这套是面试常考，也是前后端分离的核心。传统Session方案在分布式环境下要额外做Session共享，JWT方案直接把用户信息加密后发给前端，前端每次请求带在Header里，后端通过拦截器校验，天然适合前后端分离。

JWT生成的工具类核心逻辑：

java复制public class JwtUtil {
    private static final String SECRET = "only-mall-secret-key";
    private static final long EXPIRE = 7 * 24 * 60 * 60 * 1000;

    public static String createToken(Integer userId, String role) {
        return Jwts.builder()
                .claim("userId", userId)
                .claim("role", role)
                .setExpiration(new Date(System.currentTimeMillis() + EXPIRE))
                .signWith(SignatureAlgorithm.HS256, SECRET)
                .compact();
    }

    public static Claims parseToken(String token) {
        return Jwts.parser()
                .setSigningKey(SECRET)
                .parseClaimsJws(token)
                .getBody();
    }
}

拦截器里做的三件事：校验Header里有没有token、token是否过期、当前请求路径是否需要管理员权限。通过路径前缀判断很直接：/admin开头的请求，除了登录接口，都需要角色为admin。

还有一个细节：每次请求都要从token里拿userId，如果每个Controller都手动解析token，代码会非常冗余。我的方案是在拦截器里把userId放进ThreadLocal，Controller里通过UserContext.get()直接获取。

java复制public class UserContext {
    private static final ThreadLocal<Integer> USER_ID = new ThreadLocal<>();

    public static void set(Integer userId) {
        USER_ID.set(userId);
    }

    public static Integer get() {
        return USER_ID.get();
    }

    public static void clear() {
        USER_ID.remove();
    }
}

注意，一定要在请求结束后调用remove清理ThreadLocal，否则Tomcat线程池复用时会读到上一个请求的用户信息。

3.3 商品、购物车、下单的关键逻辑

商品列表查询是最常见的列表分页场景。我用了MyBatis手写分页，传入pageNum和pageSize，计算offset，返回时同时查count得到总条数。如果不想手写，可以引入PageHelper，但我更推荐自己写一次，这样你能真正理解分页原理。

商品列表SQL里除了分页，还要注意根据分类和关键词动态拼接条件，以及只查询status=1的上架商品。

xml复制<select id="selectProductList" resultType="com.only.mall.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>
        AND status = 1
    </where>
    ORDER BY id DESC
    LIMIT #{offset}, #{pageSize}
</select>

购物车模块相对简单，加购时先查一下是否已存在同一用户同一商品，存在则累加数量，不存在则插入新记录。唯一要重点处理的是数量不能为负，不能超过商品库存。

下单是整个项目里最需要小心的地方。我先说一个最简单但很实用的防超卖SQL：

sql复制UPDATE product SET stock = stock - #{quantity}
WHERE id = #{productId} AND stock >= #{quantity}

这条SQL是数据库行级更新，天然是原子的。先尝试扣减库存，如果影响行数为0，说明库存不足，直接抛异常。配合@Transactional注解，如果后面创建订单失败，整个方法回滚，库存也会恢复。

java复制@Transactional(rollbackFor = Exception.class)
public Result submitOrder(OrderCreateReq req) {
    // 1. 校验地址
    // 2. 查询购物车中勾选的商品
    // 3. 遍历商品执行扣库存SQL
    // 4. 生成订单号并插入订单主表
    // 5. 批量插入订单明细
    // 6. 清空已购买购物车项
    return Result.ok(orderNo);
}

订单号我推荐用时间戳+随机数生成，格式类似202503121530001234567890，保证唯一即可。如果用数据库自增当订单号，不仅容易暴露日单量，也不方便做分布式扩展。

3.4 MyBatis使用中的缓存与映射问题

MyBatis缓存是很容易踩坑的地方。默认一级缓存是SqlSession级别的，同一个SqlSession中执行两次相同查询会走缓存；二级缓存默认关闭，需要手动开启。我在这个项目里没有开启二级缓存，原因很简单：商城系统的商品库存和订单数据实时性要求很高，缓存一旦没做好失效策略，很容易出现用户看到的数据不是最新的。

如果你要开二级缓存，建议只在商品分类这种很少变化的数据上做，并且要使用Redis这类外部缓存，而不是MyBatis自带的本地缓存。因为本地二级缓存在多实例部署下数据不一致问题很严重。

映射方面最常见的报错是Invalid bound statement。这个问题十有八九是Mapper接口和XML文件没有对应上。检查点有四个：

• Mapper接口的包路径和XML的namespace是否一致。
• 接口方法名和XML中statement的id是否一致。
• 接口方法参数是否都使用了@Param注解。
• application.yml里mapper-locations是否指向了XML目录。

还有一个很多人踩的坑：XML里的if test判断不等于某个字符串时，如果字段值是0，判断会失效。因为MyBatis会把'0'当成false处理。比如：

xml复制<if test="status != null and status != ''">
    AND status = #{status}
</if>

如果status传入0，拼出来的SQL会不包含这个条件。解决方案是加一个额外的数字判断，或者把类型转成字符串比较。这类细节不实际写一遍真的不容易发现。

4. 前端核心实现：Vue页面与接口联调

4.1 前端项目初始化

前端我用的Vue 2.7，搭配Vue Router和Vuex，UI组件库选择Element UI。为什么不直接上Vue3？因为Element UI对Vue2的生态最成熟，网上资料也多，作为学习项目更容易查错。如果你已经熟悉Vue3，迁移到Vue3 + Element Plus也不难，接口层基本可以复用。

初始化命令：

bash复制npm install -g @vue/cli
vue create only-mall-web

创建时选择手动配置，勾选Router、Vuex，CSS预处理器我选了SCSS。进入项目后安装Element UI和axios：

bash复制npm install element-ui axios

Element UI我直接用了全量引入，因为后台管理系统对打包体积不敏感。如果是面向用户的C端页面，建议按需引入，减少首屏加载时间。全量引入的写法是在main.js里：

javascript复制import Vue from 'vue'
import ElementUI from 'element-ui'
import 'element-ui/lib/theme-chalk/index.css'

Vue.use(ElementUI)

另外一个重要建议：不要用node-sass，用sass。node-sass安装经常失败，而且Node版本一升级就编译报错，换成dart-sass之后基本没有这个烦恼。

4.2 路由划分与登录守卫

前端路由分了两块：普通用户页面和后台管理页面。普通页面直接写在routes里，后台页面统一放在Layout组件下面，通过路由前缀/admin区分。

javascript复制const routes = [
  { path: '/', redirect: '/home' },
  { path: '/login', component: Login },
  {
    path: '/home',
    component: Home,
    meta: { requiresAuth: true }
  },
  {
    path: '/admin',
    component: AdminLayout,
    meta: { requiresAuth: true, role: 'admin' },
    children: [
      { path: 'product', component: AdminProduct },
      { path: 'order', component: AdminOrder }
    ]
  }
]

路由守卫的核心逻辑：只要访问的页面meta里requiresAuth为true，就检查本地有没有token；没有就跳转登录页。如果是后台路由，再检查当前用户的role是不是admin。

javascript复制router.beforeEach((to, from, next) => {
  const token = localStorage.getItem('token')
  if (to.meta.requiresAuth && !token) {
    next({ path: '/login', query: { redirect: to.fullPath } })
  } else {
    next()
  }
})

这里有一个体验细节：登录成功后应该跳转到redirect参数指定的页面，而不是永远跳首页。在登录方法里处理一下就能提升很多使用体验。

4.3 axios封装与跨域配置

axios如果每个页面都直接调用，遇到401处理、token携带、错误提示这些需求时要改的地方太多了。我在src/utils/request.js里统一封装了一个实例。

javascript复制import axios from 'axios'
import { MessageBox } from 'element-ui'
import router from '@/router'

const service = axios.create({
  baseURL: '/api',
  timeout: 15000
})

service.interceptors.request.use(config => {
  const token = localStorage.getItem('token')
  if (token) {
    config.headers['Authorization'] = token
  }
  return config
})

service.interceptors.response.use(
  response => {
    const res = response.data
    if (res.code === 401) {
      localStorage.removeItem('token')
      router.push('/login')
      return Promise.reject(new Error('未登录'))
    }
    if (res.code !== 200) {
      MessageBox.alert(res.message, '提示', { type: 'warning' })
      return Promise.reject(new Error(res.message))
    }
    return res.data
  },
  error => {
    return Promise.reject(error)
  }
)

export default service

开发环境的跨域问题通过vue.config.js里的devServer.proxy解决，不需要后端额外开启CORS。

javascript复制devServer: {
  proxy: {
    '/api': {
      target: 'http://localhost:8080',
      changeOrigin: true
    },
    '/admin': {
      target: 'http://localhost:8080',
      changeOrigin: true
    }
  }
}

这样前端请求/api/user/login时，开发服务器会把请求转发到后端8080端口，浏览器的地址栏始终是前端端口，就不会有跨域报错。

4.4 从商品列表到订单提交的完整链路

商品列表页是最典型的前后端交互页面。用户进入页面时，前端请求商品列表接口，拿到数据后渲染卡片。筛选分类和搜索关键词时，重新组装查询参数请求列表接口。我做了一个约定：列表接口统一返回{ list, total }结构，前端分页组件直接绑定total，页码变化时重新拉取列表。

商品详情页稍微复杂一点。除了基础信息，还要传商品id到详情接口，同时展示商品图片列表。加入购物车按钮点击后，请求购物车接口，成功后更新顶部导航栏的购物车数量，这个数量放在Vuex里，因为很多页面都要用到。

购物车页面展示了所有购物车项，修改数量、勾选商品、删除商品都通过接口操作。下单时把勾选的商品id列表传给后端，后端自己再根据当前用户从数据库里查购物车项，而不是信任前端传过来的商品价格、数量。这样做是为了防止用户篡改价格。

订单提交成功后，前端拿到订单号，跳转到模拟支付页面。点击“立即支付”请求支付接口，成功后跳转到订单详情。这一套流程走完，整个电商核心闭环就通了。

5. 部署实操：从零启动到服务器上线

5.1 本地环境准备与版本坑

部署之前先把环境准备好。我建议的版本组合：

• JDK 1.8 或 11
• Maven 3.6+
• Node.js 14+
• MySQL 8.0+

有一个很重要的提醒：Spring Boot 2.7.x不要用JDK 17以上，虽然能启动，但一些老版本的依赖和插件会报错。我踩过坑，JDK 17编译时会出现各种反射访问警告，严重时直接不可用。用JDK 8最省心。

MySQL 8.0安装时，如果之前装过其他版本，建议先彻底卸载干净。连接数据库时，如果遇到Public Key Retrieval is not allowed的报错，在连接串上加上allowPublicKeyRetrieval=true&useSSL=false即可。

5.2 初始化数据库和修改配置

拿到源码之后，第一步不是启动项目，而是先把数据库建好。进入MySQL命令行：

bash复制mysql -u root -p
create database only_mall default character set utf8mb4;
use only_mall;
source /your/path/only_mall.sql;

使用utf8mb4字符集很重要。如果用了utf8，商品名称里遇到特殊字符或Emoji会报错。SQL脚本执行完成后，确认一下表是否都建出来了，然后修改后端application.yml里的数据库账号密码。

如果你准备把后端放到服务器上，密码不要写死成123456这种，最好用环境变量或者外部配置覆盖。初级项目可以直接写在yml里，但要养成这个安全意识。

5.3 后端打包与启动

后端启动步骤分两种，开发环境和生产环境。

开发环境直接在IDEA里运行主类即可。生产环境用Maven打包：

bash复制mvn clean package -DskipTests

打包完成后，target目录下会生成一个only-mall.jar文件，运行：

bash复制java -jar only-mall.jar

启动日志如果出现Tomcat started on port(s): 8080，说明后端已经起来了。这时候可以先用curl验证一下：

bash复制curl http://localhost:8080/api/product/list

能返回JSON就说明接口正常。

如果端口被占用，可以用：

bash复制lsof -i:8080

找到占用进程，处理掉或者改后端端口。如果改端口，前端的proxy target地址也要同步修改。

5.4 前端打包与Nginx部署

本地开发时用npm run dev启动，实际部署需要先打包：

bash复制npm run build

构建完成后，项目根目录会生成dist文件夹，这里面就是纯静态文件。我习惯先把dist本地用nginx跑一遍，确认没有问题再上传服务器。

Nginx配置是前后端分离部署里最关键的一环，一个典型配置如下：

nginx复制server {
    listen 80;
    server_name your_domain_or_ip;

    root /usr/share/nginx/html/only-mall/dist;
    index 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;
    }

    location /admin/ {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }

    location / {
        try_files $uri $uri/ /index.html;
    }
}

这里有两个重点。

第一，location /api/和/admin/需要反向代理到后端8080端口，这样前端请求/api开头的接口时，Nginx会转发给后端。如果忘记配proxy_set_header Host，某些情况下后端获取请求头会异常。

第二，location /的try_files必须配成try_files $uri $uri/ /index.html。如果不配，前端路由使用history模式时，刷新某个子页面会404，因为Nginx找不到对应的真实文件。配了try_files后，所有路径都会回退到index.html，由前端路由接管。

5.5 服务器上长期运行的守护方案

用java -jar启动的进程，一旦关闭SSH窗口就会退出，所以需要注册成服务。我用的是systemd，新建一个服务文件：

ini复制[Unit]
Description=only-mall-server
After=network.target

[Service]
User=root
WorkingDirectory=/opt/only-mall
ExecStart=/usr/bin/java -jar /opt/only-mall/only-mall.jar
Restart=always
RestartSec=10

[Install]
WantedBy=multi-user.target

保存到/etc/systemd/system/only-mall.service后，执行：

bash复制systemctl daemon-reload
systemctl enable only-mall
systemctl start only-mall

之后看日志用：

bash复制journalctl -u only-mall -f

通过systemd管理的好处是进程崩溃后会自动重启，开机自动拉起，比手动nohup省心很多。用nohup虽然简单，但服务器一重启你就得手动去启动一次，不够可靠。

6. 常见问题与排查记录

6.1 后端启动阶段的报错排查

我整理了一张高频问题表，基本覆盖了这套项目从零到能跑起来的绝大多数坑。

还有一个初学者很容易忽略的问题：数据库连上了但查出来的中文全是问号。这种情况基本是连接串没有指定characterEncoding=utf8，或者数据库表本身是latin1编码。建库时一定要用utf8mb4。

6.2 前端开发中的跨域和路由问题

跨域是前后端分离联调时出现频率最高的问题。很多新手一看到浏览器控制台报CORS错误，第一反应是去后端加@CrossOrigin注解。我的建议是：开发环境优先用vue.config.js的proxy，生产环境用Nginx反向代理，后端不需要开启CORS。

原因很简单：用proxy和Nginx方案时，浏览器看到的请求是同源的，不会产生跨域，也不需要处理预请求。后端开CORS虽然代码简单，但容易被忽略的是会放开/api和/admin之外路径的访问，维护起来不够清晰。

前端另一个高频问题是登录后刷新页面，用户信息丢失。这是因为用户信息存在Vuex里，而Vuex的数据是在内存中的，页面一刷新就没了。解决方案是在路由守卫里判断：如果本地有token但Vuex中没有用户信息，重新调用获取用户信息接口。这比存localStorage更安全，也避免了每次都从localStorage读。

6.3 业务逻辑的隐藏bug

部署完能跑起来只是第一步，真正考验项目质量的是业务逻辑。我在测试过程中遇到过几个很典型的bug。

第一个是购物车数量为负数。前端虽然限制了输入框最小值为1，但直接调接口传-1是可以的。后端一定要做参数校验，最简单的方式是用Spring的@Valid注解，或者自己判断数值范围。

第二个是超卖问题。如果下单时先select查库存，再update扣库存，两个操作之间存在时间差，并发下就会出现库存扣成负数。我前面写的条件更新SQL是防止超卖的最低成本方案。用select + update的方式一定要改。

第三个是订单金额一致性问题。前端传总价是个大坑，用户改一下请求体就能把100元改成1分钱。所以下单接口不应该接收总价，或者接收了也不信，必须后端根据商品价格和数量重新计算总价。我在这套项目里直接规定：submitOrder接口只接收购物车中的商品id列表，金额全部后端算。

第四个是商品上下架过滤问题。后台把商品下架后，前台列表还是能查到。原因很可能是查询SQL没有加status=1条件。商品列表、商品详情、购物车展示这三个地方都要记得过滤下架商品。

7. 项目复盘与后续可以怎么做

7.1 这套项目值得写进简历的亮点

如果说这个项目和其他练习项目有什么区别，我觉得最值得写进简历的是以下几点。第一，从零设计了数据库表结构，包括订单快照、商品库存和订单明细的拆分，这是很多只会CRUD的候选人没有想过的。第二，使用JWT实现无状态登录，并通过拦截器完成用户角色鉴权，能体现对前后端分离认证机制的理解。第三，下单时用数据库条件更新扣减库存，解决了并发超卖问题，这是电商系统里非常经典的高并发场景。第四，独立完成了Nginx反向代理、history路由配置、systemd服务守护等部署工作，证明你具备上线能力。

面试官问到项目时，你可以把这几个点展开讲，比单纯说“我做过商城”要强得多。

7.2 可以继续扩展的方向

如果后续要继续完善这套系统，我建议按以下优先级扩展。

第一个推荐加Redis。用户登录token可以放到Redis里实现主动失效，热点商品可以缓存到Redis里降低数据库压力。这是最常用也是面试最常问的技术点。

第二个推荐完善支付模块。正式项目几乎不可能用模拟支付，可以接入支付宝沙箱环境，把支付回调和状态更新这块流程补齐。接入过一次之后，你对支付流程的理解会明显提升。

第三个推荐加消息队列。用户下单成功后，可以通过RabbitMQ发送通知，把扣库存、生成订单、发短信这些操作异步化，减少接口响应时间。这部分作为进阶，适合有基础之后再尝试。

7.3 一些个人的部署经验

最后分享一个我在部署环节总结出来的经验：永远先把日志工具准备好，再启动服务。我在服务器上部署这套系统时，第一件事就是看日志文件怎么输出，配置好logback的日志文件路径和级别，然后再执行systemctl start。遇到问题，现场tail -f日志文件，比在代码里到处加System.out.println要高效得多。

另外，数据库生产环境一定要定期备份。我的习惯是每天凌晨用mysqldump备份一次，保留最近7天的备份文件。商城项目数据量再小，也架不住手滑误删表。只备份不测试恢复等于没备份，这点是吃过亏后的真实建议。

这套ONLY商城从数据库设计到前后端联调再到服务器部署，整个过程走下来，你基本就能理解一个完整Web项目是怎么从零到上线了。照着源码和这篇文章的操作步骤来，遇到问题时多看看日志，相信你很快就能把它跑起来。