SpringBoot+Vue校园信息平台实战：数据库设计、接口实现与部署全解析

毕业季那会儿，我接手了一个挺典型的校园项目：给本校做一个集二手闲置、失物招领、活动报名和公告资讯于一体的校园生活信息平台。需求方只有一句“方便学生的校园生活”，但真正落地时面对的是一系列决策——模块边界怎么划、数据库表怎么建、多条件查询怎么写得优雅、前后端怎么高效联调、最后怎么部署才不至于三天两头出问题。整套系统我最终采用了 SpringBoot + Vue + MyBatis + MySQL 的组合来实现，今天就把这个项目的完整拆解写出来。

这篇博文不会只贴一堆建表语句和代码片段，而是会把“为什么这么设计”讲明白：为什么用单体架构而不是微服务，为什么用 MyBatis 而不用 JPA，为什么前端选 Vue3 而不是 Vue2，数据库字段为什么要冗余、为什么要逻辑删除，以及我在联调和部署阶段踩过的那些坑。如果你正准备做类似的前后端分离管理类系统，或者正在做毕业设计、需要一个能真正跑起来的参考案例，这篇内容应该能帮你少走不少弯路。

1. 项目定位与模块拆分：校园信息平台不是“万能展示墙”

1.1 核心业务场景与用户角色

校园生活信息平台的本质，是解决信息散落的问题。以前二手交易靠QQ群、失物招领靠教学楼公告栏、活动报名靠线下填表，信息流动慢而且容易丢。这类系统要做的，就是把“发布信息—浏览检索—互动联系—后台管理”这条链路集中到一个平台上。

所以需求再五花八门，核心用户也只有两类：学生和管理员。学生能浏览各类信息、发布二手商品、登记失物/拾物、报名活动、收藏内容；管理员负责内容审核、活动发布、公告管理、用户管理。用户表里用一个 role 字段区分这两种角色就够了，不需要设计复杂的 RBAC 权限表——这种规模的项目引入完整权限框架属于过度设计，后面维护成本反而高。

1.2 MVP 阶段的模块取舍

我见过太多人一上来就想做聊天功能、支付系统、实时消息推送，最后项目烂尾。信息平台类项目最忌讳一开始就铺开做。我最终定的 MVP 模块只有五个：二手闲置、失物招领、校园活动、公告资讯、个人中心。

二手闲置是平台使用频率最高的模块，核心链路是发布商品、分类检索、查看详情、下架删除；失物招领和二手闲置结构相似，但多了“寻物/招领”的类型区分；校园活动需要考虑报名人数上限，超员后就不可报名；公告资讯由管理员发布，普通学生只能查看；个人中心聚合“我发布的”“我收藏的”两个列表。至于站内信、评论点赞、支付担保这类功能，完全可以在 MVP 跑通后按需迭代。

一个很实用的判断标准是：如果某个模块用 Excel 也能管理，但它能被学生高频访问，那它就该做进系统；如果某个功能只是“听起来很完善”，但使用频次一个月都未必有一次，就先砍掉。信息平台的价值在于聚合访问入口，而不是罗列功能。

1.3 技术选型复盘：为什么还是这套组合

这个项目恰好在 2025 年启动，SpringBoot + Vue3 依然是中小型管理系统最稳的组合。我复盘过几套备选方案，给大家一个参考：

后端我选的是 SpringBoot 2.7，因为 3.x 要求 JDK17 起步，不少实验室和校园服务器的 JDK 还是 1.8，兼容性上 2.7 容错率更高。持久层用 MyBatis 而不是 MyBatis-Plus，原因有两个：一是这段代码需要清晰展示 SQL 在哪、怎么优化，二是动态 SQL 在复杂筛选场景下能精确控制执行逻辑。MyBatis-Plus 确实能少写很多 CRUD，但对多条件分页这类逻辑反而多了一层不太透明的封装。当然，如果你追求极致速度，用 Plus 也没问题，我这里是故意用原生 MyBatis 保持 SQL 的可控性。

数据库选 MySQL 8.0，不是 5.7。8.0 的窗口函数、UTF8MB4 默认支持、性能优化都很关键，而且现在新装环境基本都是 8.0，没必要逆潮流选旧版本。前端用 Vue3 + Vite + Pinia + Vue Router，这套组合在开发体验上比 Vue2 + Vue CLI 快一个量级，Vite 的冷启动和热更新对学生机这种配置不高的开发环境非常友好。

2. 数据库建模：从业务表到索引设计的落地细节

2.1 核心表结构清单

这类项目建表有一个通用的套路：先画用户，再画业务主体表，最后画关系表。我最终落地的核心表有七张：用户表、二手商品表、失物招领表、活动表、公告表、收藏表、报名表。

以用户表为例，完整字段设计如下：

CREATE TABLE `user` ( `id` BIGINT NOT NULL AUTO_INCREMENT, `username` VARCHAR(32) NOT NULL COMMENT '登录账号', `password` VARCHAR(100) NOT NULL COMMENT 'BCrypt加密后的密码', `nickname` VARCHAR(32) DEFAULT NULL, `avatar` VARCHAR(255) DEFAULT NULL COMMENT '头像地址', `phone` VARCHAR(20) DEFAULT NULL, `role` TINYINT NOT NULL DEFAULT 0 COMMENT '0-学生 1-管理员', `status` TINYINT NOT NULL DEFAULT 1 COMMENT '0-禁用 1-正常', `deleted` TINYINT NOT NULL DEFAULT 0 COMMENT '逻辑删除 0-未删 1-已删', `create_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, `update_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_username` (`username`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户表';

二手商品表、失物招领表、活动表这三张核心业务表的结构高度相似，都由三部分组成：发布者标识、业务内容字段、状态字段。二手商品表大致是 id、user_id、title、description、price、original_price、category、images、status、view_count、deleted、create_time、update_time；失物招领表多一个 type 字段（寻物/招领）和一个 location 字段；活动表多 start_time、end_time、max_people、current_people。

这里有个关键点：不要给每一类信息单独建一堆“专用字段表”，而是提炼共性和差异。比如图片字段，很多新手会单独建一张图片表，然后用外键关联，结果查询详情时还得二次联表，非常麻烦。对于校园信息平台这种低并发业务，直接在业务表里用 VARCHAR 字段存 JSON 格式的图片地址数组，前端拿到直接遍历渲染，后端解析也简单。五张图以内的需求，这个方案一年能省下大量联表的麻烦。

2.2 逻辑删除、状态流转与时间戳设计的底层逻辑

逻辑删除是我在这个项目里坚持的一个设计：所有核心业务表都带 deleted 字段，删除操作一律执行 UPDATE 而不是 DELETE。为什么？因为二手商品、失物招领这类数据具有回溯价值——管理员需要看到被删内容以便违规追踪，而且用户在“我的发布”里看到“已下架”状态，体验也更好。如果真删了数据就彻底没了。

但逻辑删除有个副作用：所有查询条件都要额外带上deleted = 0。MyBatis 里建议把这些公共条件写在 XML 的<sql>标签中复用，比如：

<sql id="base_where"> deleted = 0 <if test="category != null and category != ''"> AND category = #{category} </if> <if test="keyword != null and keyword != ''"> AND (title LIKE CONCAT('%', #{keyword}, '%') OR description LIKE CONCAT('%', #{keyword}, '%')) </if> </sql>

状态字段的设计要配合业务流转。二手商品 status 我用 0-下架、1-在售、2-已卖出、3-违规下架四态；活动表 status 用 0-未开始、1-报名中、2-已结束、3-已取消。每个状态对应的前端按钮和后端接口权限完全不同，比如已卖出商品不能再出现在列表中，已结束活动不能再提交报名。状态机的设计一定要在编码前画清楚，我见过太多项目上线后因为状态没对齐而查数据对不上的情况。

时间戳用 DATETIME 而不是 TIMESTAMP，字段默认值直接写CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP，这样插入和更新都不用手动维护时间，MyBatis 里也不要再给 create_time、update_time 赋值，否则容易出现前台时间显示和数据库实际值差八小时的问题。

2.3 高频查询的索引策略

建表时顺手把高频查询的索引建好，比上线后发现慢再补救划算得多。我在这套系统里遵循三个原则：

第一，查询条件里的状态和分类字段建联合索引。比如二手商品列表页最常见的筛选是“在售商品中按分类排序”，于是建(status, category, create_time)联合索引。这样既能过滤 status，又能走分类，还能让排序走索引。

第二，外键字段单独建索引。user_id、activity_id 这些字段虽然不建物理外键（我强烈建议不建物理外键，避免插入和删除的锁表风险），但逻辑上它是关联字段，查询频率极高，必须建普通索引。

第三，不要对 text 类型字段建索引。description 这类长文本内容，如果后续要支持全文搜索，应该另建全文索引或用 ElasticSearch，而不是直接加普通索引。业务前期用 LIKE 模糊查询完全够用，注意避免 LIKE '%关键词%' 这种前缀通配写法，它无法走索引。

3. SpringBoot 后端接口实现：MyBatis 动态 SQL 与分层设计

3.1 工程分包规范

后端工程我按“controller-service-mapper-entity”四层切分，但比这四层更重要的是包的边界意识。我的分包结构是：

• controller：只做参数接收、调用 service、返回统一结果，不写任何业务逻辑
• service：业务编排，事务边界在这里
• mapper：MyBatis 的接口层，只写数据库交互
• entity：数据库实体类
• dto：前端交互对象，不直接暴露 entity
• common：统一返回结果、全局异常、常量、工具类
• config：JWT 拦截器、跨域配置、静态资源映射

容易被忽略的是 dto 和 entity 的分离。很多小型项目图省事直接拿 entity 返回给前端，后面一旦加字段、改字段名，前端接口就跟着乱。我在这个项目里定义了两类 dto：查询请求对象（QueryDTO，承载分页参数和筛选条件）和返回展示对象（VO），用 BeanUtils 或 MapStruct 做转换。

3.2 典型接口案例：多条件分页查询的动态 SQL

二手商品列表是这套系统最核心的接口，查询条件包括分类、关键字、价格区间、状态、排序方式，再加上分页。原生 MyBatis 的动态 SQL 在这里非常合适。controller 层接收一个 ProductQueryDTO，然后调用 service。

关键点在 mapper XML，我贴一个核心片段：

<select id="selectProductPage" resultType="com.example.entity.Product"> SELECT id, user_id, title, price, original_price, category, images, status, view_count, create_time FROM product <where> deleted = 0 <if test="q.status != null"> AND status = #{q.status} </if> <if test="q.category != null and q.category != ''"> AND category = #{q.category} </if> <if test="q.keyword != null and q.keyword != ''"> AND (title LIKE CONCAT('%', #{q.keyword}, '%') OR description LIKE CONCAT('%', #{q.keyword}, '%')) </if> <if test="q.minPrice != null"> AND price &gt;= #{q.minPrice} </if> <if test="q.maxPrice != null"> AND price &lt;= #{q.maxPrice} </if> </where> ORDER BY <choose> <when test="q.sort == 'price_asc'">price ASC</when> <when test="q.sort == 'price_desc'">price DESC</when> <when test="q.sort == 'newest'">create_time DESC</when> <otherwise>create_time DESC</otherwise> </choose> </select>

用<where>标签的好处是会自动去掉多余的 AND 和 OR，不需要手工拼 SQL。排序字段用<choose>做白名单映射，而不是直接把前端传的 sort 字符串拼进去，这是防止 SQL 注入的基本素养。分页我用的是 PageHelper，用法很简单：

PageHelper.startPage(pageNum, pageSize); List<Product> list = productMapper.selectProductPage(query); PageInfo<Product> pageInfo = new PageInfo<>(list);

一个极其容易踩的坑是：PageHelper.startPage()之后必须紧跟你要分页的那一条查询语句，中间不能插入任何其他 SQL 操作。官方文档说“紧跟第一个查询”，实际体验是最好近到它们之间只有一行代码。我见过同事在 startPage 和查询之间加了一行日志查询，结果分页跑到了日志查询上，业务数据全部返回了。

3.3 JWT 登录认证与权限拦截

我没有引入完整 Spring Security，对这个项目来说太重了。登录认证用 JWT + 拦截器就能优雅解决。用户表密码用 BCrypt 加密，服务端每次登录校验时用 BCrypt 的 matches 方法比对明文和密文，而不是解密——BCrypt 根本不可逆，这也意味着数据库泄露了也不能直接拿到明文密码。

登录成功后在服务端生成 token，我用的是 jjwt 0.11.5 版本，把 userId 和 role 放进 Claims，设置过期时间 24 小时：

String token = Jwts.builder() .setSubject(String.valueOf(user.getId())) .claim("role", user.getRole()) .setIssuedAt(new Date()) .setExpiration(new Date(System.currentTimeMillis() + 86400000L)) .signWith(SignatureAlgorithm.HS256, secretKey) .compact();

然后写一个 TokenInterceptor 实现 HandlerInterceptor，在 preHandle 里校验 token 并取出 userId 放回 request attribute 中，后续 controller 直接从 request 拿当前登录用户，不需要每个接口都手动传 userId。

我这里特别强调一下放行路径的维护。像/api/auth/login、/api/auth/register、商品浏览接口、公告列表接口都是免登录的，其他接口需要登录，而管理员相关接口还要额外校验 role==1。拦截器里用 AntPathMatcher 做路径匹配，把**/admin/**单独拎出来校验管理员权限。这种“两级拦截”比在 controller 每个方法上打注解更直观，也更容易复现问题。

3.4 统一返回体与全局异常处理

接口返回体不统一是前后端联调效率低下的第一大元凶。我从一开始就规定所有接口返回 Result 对象，结构固定为 code、message、data 三件套。code=200 表示成功，其他业务码由常量定义，比如 401 未登录、403 无权限、500 系统异常。前端 Axios 的响应拦截器只看 code，不看 HTTP 状态码，这样业务异常和系统异常的处理会非常统一。

配合全局异常处理，用 @RestControllerAdvice 统一拦截三类异常：BusinessException（手动抛出的业务错误，比如“商品已在售状态不能下架”）、参数校验异常（MethodArgumentNotValidException，绑定 @Valid 校验结果）、兜底 Exception。这样 controller 里的代码才能真正保持干净，不需要 try-catch 满天飞。

4. Vue 前端开发与联调：从页面搭建到接口对接

4.1 项目初始化与目录结构

前端我用 Vite + Vue3 + Pinia + Vue Router 起步。创建项目最省事的方式是：

npm create vite@latest campus-front -- --template vue cd campus-front npm install npm install axios vue-router@4 pinia element-plus

目录结构我是这样规划的：views 放页面级组件，components 放可复用组件，api 按模块拆分接口，router 配置路由，stores 放 Pinia 状态，utils 放 axios 封装和工具函数。这里有个经验：api 目录下的每个文件导出的方法名要和后端接口语义完全对应，比如 getProductPage、createProduct、updateProductStatus。这样前后端对照着看代码时，几乎不用猜接口是干什么的。

Element Plus 我用来做组件库，表格、表单、日期选择器、分页组件直接拿来用。但要注意别把所有页面都做成“后台管理表格风”，校园信息平台的 C 端页面（指面向普通学生的浏览页面）应该做得更卡片化、更活泼一些，组件库负责表单和反馈类组件就好。

4.2 Axios 封装与开发环境代理

Axios 封装是整个前端工程质量的分水岭。我在 utils/request.js 里创建了一个 axios 实例，baseURL 设为/api，这样开发和生产环境可以统一走代理。

请求拦截器里做两件事：从 localStorage 取 token，有就加到 Authorization 头；在请求头里设置 Content-Type 为 application/json。响应拦截器里统一处理返回结构：

service.interceptors.response.use( (response) => { const res = response.data if (res.code === 200) { return res } if (res.code === 401) { // token 过期或未登录，跳转登录页并清除本地登录态 localStorage.removeItem('token') router.push('/login') } return Promise.reject(new Error(res.message || '请求失败')) }, (error) => { return Promise.reject(error) } )

开发环境的跨域问题，通过 Vite 的 proxy 配置解决，不用后端配 CORS：

server: { proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true, rewrite: (path) => path.replace(/^\/api/, '') } } }

我特别提醒一句：如果后端也配了 CORS，前端也配了代理，两条路同时走反而容易出问题。我的习惯是开发环境统一走 Vite 代理，生产环境统一走 nginx 反向代理，后端 SpringBoot 的跨域配置直接关掉，避免双通道下请求头冲突。

4.3 路由守卫与用户登录态管理

前端路由用 hash 模式还是 history 模式，这里我直接说结论：除非你已经充分理解 nginx 的 try_files 配置，否则校园信息平台这种项目一律用 hash 模式。hash 模式部署到任何静态服务器、甚至从本地文件直接打开都能跑，对服务器环境要求为零。history 模式虽然 URL 好看，但刷新页面时会触发 404，需要在 nginx 层做 fallback 到 index.html 的处理，多一层配置多一个坑。

路由守卫的逻辑如下：

router.beforeEach((to, from, next) => { const token = localStorage.getItem('token') const userInfo = localStorage.getItem('userInfo') ? JSON.parse(localStorage.getItem('userInfo')) : null if (to.meta.requiresAuth && !token) { next('/login') return } if (to.meta.requiresAdmin && (!token || userInfo?.role !== 1)) { next('/') return } next() })

用户信息在登录成功后存到 localStorage，同时在 Pinia 里维护一份响应式副本。这里有个细节：localStorage 里的 userInfo 是做持久化的，Pinia 里的 store 是做组件响应式渲染的，两者各司其职。业务系统里很多人只存 token 不存用户信息，结果每个页面都要调一次获取信息接口，太浪费了。

4.4 核心业务页面的实现要点

商品列表页是这套系统的门面。我推荐用卡片流布局，每张卡片展示图片、标题、价格、浏览量，点击进入详情页。列表页最重要的交互是筛选栏和分页的联动：筛选条件变化时重置页码为 1，分页切换时保留当前筛选条件。这要求在组件的 data 里维护一个 query 对象，所有筛选控件都绑到同一个 query 上，请求时整体提交。

发布商品页的表单校验用 Element Plus 的表单校验规则，图片上传我实现了一个简易的上传组件：选择文件后用 FormData 提交到后端/api/file/upload，后端保存到指定目录并返回地址，前端把图片 URL push 到 images 数组里。注意图片上传要限制文件类型和大小，我限制单张不超过 2MB，格式只允许 jpg / png / webp。

Vue 插槽在这里的典型应用是列表空状态。Element Plus 的 el-empty 用默认插槽可以自定义描述文案；列表卡片组件里我也用了插槽，让父组件可以注入操作按钮（比如“编辑”“下架”）。这些细节能让代码复用率提升不少，页面也不会千篇一律。

5. 打包部署与踩坑复盘：那些让我排查到半夜的问题

5.1 Vue 打包后与 SpringBoot 的两种部署方式

项目上线时我同时验证了两种部署方式。第一种是直接把前端打包产物放进 SpringBoot：先npm run build，把生成的 dist 目录里的全部文件复制到src/main/resources/static下，然后重新打包 SpringBoot jar。启动后访问http://ip:8080/就能看到前端页面，后端接口路径因为 controller 都是/api开头，前端打包后也会正确请求。

这种方式胜在部署简单——只需要跑一个 jar，适合小型服务器和学生机的实验环境。但缺点是每次前端改版都要重新打包后端，而且前端静态资源被塞进 jar 后，nginx 层面做 gzip 缓存也麻烦。所以正式上线推荐第二种方式：前后端完全分离部署。Vue 构建产物放到 nginx 的 html 目录，nginx 监听 80 端口，静态文件直接由 nginx 返回；/api前缀的请求反向代理到 SpringBoot 的 8080 端口：

server { listen 80; server_name localhost; location / { root /usr/share/nginx/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; } }

try_files $uri $uri/ /index.html这一行是给 history 路由模式用的，如果用 hash 模式就没有 404 问题。一个人维护的小项目，nginx + SpringBoot jar 这种组合已经非常抗造了。

5.2 联调阶段的高频坑：MyBatis 条件失效与 MySQL 时区

第一个高频坑是 MyBatis 的多条件查询“条件不生效”，表现是传了 status 参数但 SQL 里就是没有这层过滤。排查链路是这样的：先打印 MyBatis 日志看实际执行的 SQL，如果 SQL 里条件确实没有拼接，那就是<if test>判断的问题；如果 SQL 有条件但结果不符合预期，那是参数类型或映射的问题。

最常见的根因有两种。一是在<if test="status != null">中 status 是 Integer 类型没问题，但如果是 String 类型且传了空字符串，判断条件必须写成status != null and status != ''，否则空字符串会被当成有效值；二是在 mapper 接口里没加@Param注解，MyBatis 在 XML 中引用参数名失败，导致回退到 arg0、param1 这种位置参数，XML 里写的参数名全部无效。我的习惯是每一个 mapper 接口方法的参数都显式加@Param，绝不依赖编译期保留参数名的开关，这样 XML 里引用谁都不虚。

第二个高频坑是 MySQL 时区问题。直观现象是：数据库里存的时间是对的，但 Java 查出来放到前端显示差了 8 小时。根因是 SpringBoot 2.7 里 JDBC 连接串没指定 serverTimezone 时，默认跟随系统时区，而 MySQL 驱动和 JVM 默认时区不一致。解决方式是在application.yml里显式指定：

spring: datasource: url: jdbc:mysql://localhost:3306/campus_life?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false&allowPublicKeyRetrieval=true

characterEncoding=utf8也要带上，否则中文可能会出现乱码。这个allowPublicKeyRetrieval=true是 MySQL 8.0 新版驱动的要求，不加会偶发认证失败。这三个参数是我每次搭建开发环境都会默写出来的黄金三件套。

第三个坑涉及 PageHelper 和动态 SQL 的“隐形联调问题”。前面说了 startPage 后面必须要紧跟查询，但就算贴紧了，如果 mapper XML 里写了多个 SELECT 语句（比如先查了 count 再查 list），PageHelper 的拦截也可能只作用到第一条 SELECT 上。我的做法是分页查询单独写一个 XML 方法，每个方法只执行一条 SELECT，不混入其他逻辑。分页总数计算交给 PageHelper 自动生成的 count SQL，不要自己再去查一次总数，否则两条 SQL 的执行边界容易重叠。

5.3 图片上传与静态资源映射

图片上传接口本身不难，难点在服务端的目录策略和访问映射。我这种做法是：定义一个可配置的上传根路径（比如/data/campus/upload），文件按日期分目录存放，文件名用 UUID 重命名，避免中文名和重复名。

后端要能通过 URL 访问这些图片，需要在 SpringBoot 里配置虚拟路径映射：

@Configuration public class WebConfig implements WebMvcConfigurer { @Value("${file.upload-path}") private String uploadPath; @Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/files/**") .addResourceLocations("file:" + uploadPath + "/"); } }

前端上传成功后拿到的是/files/2025/06/xxx.jpg这种相对路径，在列表页渲染时要用拼接了服务器地址的完整 URL。这里有一个部署相关的坑必须说：如果前端和后端都部署在同一台机器的 nginx 下，图片的/files前缀也要像/api一样在 nginx 里做访问转发，否则前端请求图片会 404。我见过不少人部署上线后发现商品图片全部裂开，排查半天才发现是 nginx 少配了一个 location。

5.4 缓存与查询性能的优化方向

校园信息平台这种读多写少的业务，性能优化的收益非常明显。第一层优化是 MyBatis 二级缓存，这真是个双刃剑。二级缓存默认不开启，开启后按 namespace 缓存查询结果，但一旦涉及多表关联查询，A namespace 缓存的数据被 B 表更新后就可能读到脏数据。我在这个项目里的取舍是：只给单表查询且更新频率低的公告表开启二级缓存，商品表、活动表这种频繁改状态的表一律不开，宁可每次查库也不承担脏数据风险。如果你对 MyBatis 二级缓存原理不够熟，我的建议是干脆全部不开。

第二层优化是列表页的“减少即时查询压力”。商品列表的浏览量字段（view_count），每次打开详情页就 UPDATE 一次，并发高时会锁行。我用了一个简单的折中方案：浏览量累计到前端同一个用户会话内只增一次，并且把 UPDATE 语句改成SET view_count = view_count + 1这样一条 SQL 原子递增，而不是先 SELECT 再 UPDATE，锁竞争时间能降低不少。

第三层优化是 nginx 层。前端打包后的 js、css 文件开启 gzip，响应体积直接减少 60% 以上，加载速度提升明显；商品图片加浏览器缓存头，用户第二次访问时图片从本地缓存加载，服务器带宽瞬间宽裕。

最后说几句

整套系统从数据库建模到前后端联调、再到上线部署，我前后花了两个星期左右，其中差不多有三四天是在和 MyBatis 的怪癖、时区问题、nginx 配置打架。现在回看，最值得满意的地方不是用了多新的技术，而是每一个设计决策都能讲出理由：为什么选单体、为什么逻辑删除、为什么动态 SQL 这么写、为什么前端用 hash 路由。如果你也在做类似的项目，我最后给一个小建议：花半天时间把 MySQL 的慢查询日志打开（SET GLOBAL slow_query_log = ON;），它会忠实地告诉你哪些 SQL 该建索引、哪些查询在拖后腿。校园信息平台这种业务体量下，慢查询日志里暴露的问题往往十秒钟就能优化到位，但它能帮你养成“任何查询结果都先解释执行计划”的习惯，这个习惯比项目本身值钱得多。