Spring Boot书店管理系统：从表设计到部署避坑全攻略

躲猫猫书店管理系统，名字挺有意思。第一次听到的时候我愣了一下，后来才反应过来，核心还是一个基于Spring Boot的书店管理系统，只是套了个有故事感的产品名。这类“XX管理系统”在毕业设计、课程设计和Java就业项目里出镜率极高——图书管理、用户管理、订单管理、轮播图、公告、会员积分，套路成熟，技术栈主流，但要说把它写得有亮点、答辩能讲清楚、代码能跑通不出幺蛾子，还是有不少门道。这篇文章我就结合自己做过和带人做过的经验，把这个Spring Boot书店管理系统从需求拆解、表设计、核心功能实现到部署避坑完整过一遍，给正在做类似项目的同学一个能直接“抄作业”的参考。

1. 项目定位与整体思路拆解

1.1 “躲猫猫”不等于花架子：先理清楚系统到底要干什么

做任何管理系统，第一步都不是写代码，而是把业务边界划清楚。“躲猫猫书店管理系统”这个名字虽然花哨，但落到实际功能上，本质上就是一个典型的B2C图书商城后台 + 用户前台的双端系统：

• 用户端（前台）：注册登录、浏览图书、按分类筛选、搜索书名/作者、查看图书详情、加入购物车、下单购买、个人中心（订单列表、收货地址、积分/会员信息）。
• 管理端（后台）：管理员登录、图书增删改查与上下架、图书分类管理、订单发货/取消处理、用户管理（禁用/启用）、轮播图管理、公告发布、会员积分规则配置。

为什么叫“躲猫猫”？我猜测有两种可能：一是书店本身有个“藏书寻宝”的线下主题，系统里可能藏着“幸运读者”“盲盒抽书”之类的互动功能；二是纯粹为了毕设题目看起来不那么千篇一律。不管哪一种，你都要把它变成一个可以讲解的“产品亮点”，而不是让这个名字变成一个空壳。

很多同学拿到题目后，第一反应是找一套开源店铺系统改个名字就交差。这个思路不是不行，但答辩时老师只要问一句“你的‘躲猫猫’体现在哪里？”就会很尴尬。我的建议是：至少补一个带主题感的小功能，比如“盲盒抽书”（后台设置一组随机图书，用户用积分抽取）或者“藏书阁”（模拟书架格子，每本书藏在某个格子后面，用户通过关键词提示定位）。这个小功能不需要复杂，一张表加一个接口就能实现，但能让整个项目的完成度和叙事性完全不同。

1.2 为什么选Spring Boot：不只是因为“热词”里全是它

搜一下就知道，Spring Boot相关的热搜词密密麻麻——自动装配原理、版本配置、Banner生成器、jar包反编译、MyBatis整合、Redis缓存、Docker部署，几乎涵盖了Java后端面试的每一个角落。书店管理系统选Spring Boot，不是跟风，而是因为它确实是这类业务系统的最优解：

• 自动装配：引入spring-boot-starter-web就能得到内嵌Tomcat和Spring MVC全套能力，不用像老Spring项目那样写一堆XML配置。这不是省事的问题，而是能让开发者的注意力集中在业务逻辑上，而不是配置地狱里。
• 生态成熟：书店管理系统的核心诉求是CRUD + 事务 + 权限 + 缓存，Spring Boot对应的starter方案——MyBatis-Plus、Spring Security或Sa-Token、RedisTemplate、Spring Data JPA——都是久经考验的组件，遇到问题上网一搜就有答案。
• 部署友好：一个java -jar就搞定，配合Docker更是能标准化交付。相比早期SSH项目需要手动部署到Tomcat，这种方式对毕设演示、实习交接、小团队上线都极其友好。

另一个容易被忽略的原因是答辩可讲性。Spring Boot的自动装配原理、starter机制、约定优于配置，这些都是面试官和答辩老师最喜欢的提问点。你做这个项目不仅是在“交作业”，更是在给自己积累面试素材——这一点我后面会专门展开。

1.3 版本选型：Spring Boot 2.7和3.x到底怎么选

这是新手最容易踩坑的地方。搜索引擎里“springboot版本太高”“idea 2026怎么配置springboot服务”这种问题满天飞，根源就是版本选型没做好。

如果你现在新开项目，我建议分情况选择：

使用场景	推荐版本	JDK	理由
毕业设计/课程设计	Spring Boot 2.7.x	JDK 8或11	资料最丰富，几乎所有现成代码都能直接跑，兼容性最好
求职就业项目	Spring Boot 3.2.x或3.3.x	JDK 17	更贴近企业现状，但要注意部分旧教程已不适用
公司存量系统维护	看现网版本	看现网版本	以稳定为主，不要盲目升级

这里有个很现实的教训：Spring Boot 3.x把javax包换成了jakarta，很多老教程里的import javax.servlet在3.x项目里直接编译报错。如果你选了3.x，又参考了2.x的教程，就会遇到一堆莫名其妙的兼容问题。毕设项目我强烈推荐2.7.x + JDK 8，这不是技术落后，而是“稳”字当头——你的时间应该花在业务功能和答辩准备上，而不是和版本兼容性较劲。

2. 技术选型与数据库设计

2.1 持久层框架：MyBatis-Plus真的好用

搜索引擎里“springboot + mybatis结合mvc框架设计”这个热词说明了一件事：很多人对MyBatis和Spring MVC的关系还没完全捋清楚。简单说：Spring MVC是Web层框架，负责接收请求、参数绑定、返回响应；MyBatis是持久层框架，负责SQL映射和数据访问。它们通过Spring容器无缝协作，Spring Boot只是把这些组装工作简化了。

具体到书店管理系统，我推荐MyBatis-Plus而不是原生MyBatis，理由非常实际：

• 单表CRUD零SQL：BaseMapper内置了selectById、selectPage、insert等方法，后台管理端80%的操作是单表傻CRUD，手写SQL毫无意义。
• 分页插件好用：MybatisPlusInterceptor加一个配置类就能实现物理分页，图书列表、订单列表都靠它。
• 逻辑删除和自动填充：@TableLogic注解实现删除标记，@TableField(fill = FieldFill.INSERT)配合MetaObjectHandler自动填充创建时间，这些功能都非常贴合管理系统的通用需求。

但有一点要提醒：不要为了用MyBatis-Plus而抛弃SQL能力。涉及多表关联查询（比如订单详情需要联查图书信息和用户信息）时，MyBatis-Plus的@Select注解写自定义SQL依然是最清晰的方式。我见过有同学把所有查询都拆成单表再在内存里拼接，数据量小没问题，但写法上确实不体面。

2.2 数据库表设计：八张表打底，一张表体现亮点

书店管理系统的数据库设计是答辩时的重点展示环节。我先给一个经过验证的表结构方案，再解释每张表的关键设计意图。

核心表：

表名	用途	关键字段
user	用户表	id,username,password,nickname,avatar,phone,points,status
book	图书表	id,title,author,publisher,isbn,price,stock,cover,description,category_id,status
category	图书分类表	id,name,sort_order
cart_item	购物车表	id,user_id,book_id,quantity,checked
orders	订单主表	id,order_no,user_id,total_amount,status,address_id,create_time,pay_time
order_item	订单明细表	id,order_id,book_id,book_title,book_cover,price,quantity
carousel	轮播图表	id,image,link_url,sort_order,status
notice	公告表	id,title,content,create_time,status

设计要点：

• book表单独存category_id而不是直接存分类名：方便分类改名、统计分类下图书数量，这是标准范式设计。
• order_item冗余了book_title和book_cover：订单产生后，图书信息可能被修改甚至下架，但订单快照应该保持不变。这个“冗余”是电商系统的通用做法，答辩时是加分项。
• orders和order_item必须分开：一个订单对应多个图书，主表只存总金额和状态，明细表各自存单价和数量。如果不拆分，后续退款、统计都要出问题。
• password存储：必须用BCrypt加密（Spring Security自带BCryptPasswordEncoder），绝不能明文存。

如果要加入“盲盒抽书”作为躲猫猫主题亮点，只需要加一张lucky_box_item表（id,book_id,cost_points,status），用户调用抽书接口时后台随机选一本书返回，同时扣除积分。这个功能的表设计简单，但故事性很强。

2.3 Redis用在哪：不是所有缓存都值得引入

很多毕设项目的技术清单里都写了“基于Redis实现缓存”，但问一句“缓存什么数据？为什么？”就答不上来。书店管理系统里，Redis真正有价值的两个使用场景是：

1. 图书热点数据的缓存：首页展示的图书列表、图书详情，属于典型的读多写少数据。用Redis缓存首页数据，缓存Key可以设计为book:list:category:{id}:page:{current}，后台更新图书时删除对应Key即可（Cache Aside Pattern）。
2. 验证码与Token的临时存储：用户登录时的短信/图片验证码、JWT Token的黑名单或刷新令牌，天然适合Redis的过期机制。redisTemplate.opsForValue().set(key, value, 5, TimeUnit.MINUTES)一行代码解决。

至于购物车、订单这些数据，不要放进Redis。订单是强一致性强事务性数据，必须交给MySQL保证可靠性，Redis里的数据一旦丢失就是事故。很多初学者喜欢把“尽可能多的数据塞进Redis”当作技术亮点，这其实是误解——合理使用才是亮点，滥用反而暴露出对组件定位的不理解。

2.4 配置文件的多环境拆分：别再只用一个application.yml

搜索热词里“springboot 配置”、“springboot yml 随机端口”都是高频问题，说明配置管理是新手集中翻车区。书店管理系统的开发环境和部署环境必然是不同的数据库地址、Redis地址、日志级别，所以从第一天起就应该拆分配置文件：

• application.yml：放公共配置（应用名、编码、MyBatis-Plus逻辑删除配置等）
• application-dev.yml：开发环境配置（本地MySQL、Redis、日志Debug级别）
• application-prod.yml：生产环境配置（服务器地址、日志Info级别、端口）

启动时通过spring.profiles.active=dev或prod切换。这个话题我后面在部署章节还会详细展开，这里先提一句：这个习惯能从源头上避免把本地数据库密码提交到Git仓库的尴尬。

3. 核心功能模块实现

3.1 登录认证：JWT还是Session？

书店管理系统需要区分用户端和管理员端，身份认证方案直接影响项目结构。我推荐用JWT + 拦截器的方案，理由如下：

• JWT天然无状态，适合前后端分离部署；
• 实现简单，不引入Spring Security那样的大块头框架；
• 答辩时可以把JWT的构成（Header、Payload、Signature）、签名算法、过期策略讲得清清楚楚。

具体实现思路：

1. 用户登录时校验用户名密码，密码用BCryptPasswordEncoder.matches()比对；
2. 验证通过后，生成JWT令牌，claims里放userId和role（USER或ADMIN），设置过期时间（建议用户端24小时，管理端2小时）；
3. 前端请求时携带Authorization: Bearer {token}；
4. 后端实现一个HandlerInterceptor，在preHandle里解析和校验Token，将当前用户信息存入ThreadLocal或用HttpServletRequest.setAttribute传递给后续逻辑；
5. 注册拦截器时排除登录、注册、图书列表、图书详情等白名单路径。

关于“为什么不直接用Spring Security”——不是不能用，而是对单个书店管理系统来说，Spring Security的过滤器链、认证管理器体系需要额外学习成本，而且配置不当反而成为障碍。以“快速落地、代码可讲、运行稳定”为目标，手写JWT + 拦截器是性价比最高的方案。当然，如果你的简历明确写了“熟悉Spring Security”，那就另当别论。

3.2 图书管理：状态字段比删除字段更重要

图书模块是整个系统的心脏。管理端的图书管理功能包括新增、编辑、上下架、删除，用户端展示的必须是“已上架”图书。所以book表的status字段是整个模块的关键：

• 0：下架（不向用户展示）
• 1：上架（正常售卖）

为什么不直接删除？因为图书数据有订单关联，物理删除会导致历史订单查不到图书信息。这里有两种处理方式：

一是逻辑删除方案：加deleted字段（0正常/1删除），MyBatis-Plus的@TableLogic自动拼接WHERE deleted = 0条件。二是状态而不是删除：后台的“删除”操作其实是把status改为0（下架），但保留数据记录。我在设计时倾向于第二种，因为对书店管理来说，“下架”比“删除”更符合业务语义——下架的图书改个状态就能重新上架，不需要恢复数据。

图书列表的分页查询要注意一个细节：条件查询要支持模糊搜索。用MyBatis-Plus的LambdaQueryWrapper时，可以这样写：

public Page<Book> pageBooks(int current, int size, String keyword, Long categoryId, Integer status) { LambdaQueryWrapper<Book> wrapper = new LambdaQueryWrapper<>(); wrapper.like(StringUtils.hasText(keyword), Book::getTitle, keyword) .or(StringUtils.hasText(keyword), w -> w.like(Book::getAuthor, keyword)) .eq(categoryId != null, Book::getCategoryId, categoryId) .eq(status != null, Book::getStatus, status); return bookMapper.selectPage(new Page<>(current, size), wrapper); }

这段代码里or条件的写法很关键：如果不加w ->这个Lambda子条件，or会使得后续所有条件都被OR连接，SQL逻辑就会出问题。这种细节，就是答辩时能展示“我真的写过代码”的证明。

3.3 下单流程：事务、乐观锁和订单状态机

图书商城最核心的流程是“加入购物车 → 提交订单 → 支付/模拟支付 → 管理员发货 → 用户确认收货”。整个流程里有两个容易出错的技术点：

第一个是库存扣减的并发问题。

用户点击购买后，代码逻辑通常是：先查询库存是否充足，充足则扣减，然后生成订单。但两个用户同时下单，都查到库存剩1本，都执行扣减，就会出现超卖。解决方案是用乐观锁：

UPDATE book SET stock = stock - 1 WHERE id = #{bookId} AND stock > 0

这条SQL在数据库层面保证了原子性：影响行数为0说明库存不足，下单失败。在Service层要配合事务使用，一旦扣减库存成功但订单生成失败，事务回滚，库存恢复。用@Transactional(rollbackFor = Exception.class)标注下单方法，这是最基本的保障。

第二个是订单状态流转。

订单表里status字段建议用整数存储并定义常量，不要直接用字符串，因为可扩展性差且易出错。推荐状态机：

状态值	含义	允许的后续状态
0	待付款	1（已付款）/ 5（已取消）
1	已付款/待发货	2（已发货）/ 5（已取消/退款）
2	已发货	3（已完成）
3	已完成	无
5	已取消	无

这个状态机可以用一个简单的switch或枚举类控制，核心原则是非法状态流转直接抛异常。比如一个订单从“已完成”变成“待付款”肯定是不对的，如果代码里没有这一层校验，数据就会越改越脏。

3.4 文件上传与回显：图片到底存在哪里

书店管理系统里图书封面、轮播图、用户头像都涉及图片上传。新手最容易犯的错误是把图片存到数据库里（BLOB字段），这不仅浪费数据库性能，还会导致项目打包后的jar特别臃肿。

推荐方案：图片文件上传到本地磁盘目录，数据库中只存相对路径。

在Spring Boot里配置上传路径，思路是加一个配置项，比如upload.dir=/data/bookstore/images/。然后写一个FileController接收MultipartFile，把文件保存到该目录下，同时生成一个UUID文件名防止重名。为了能让图片通过URL访问到，需要配置静态资源映射：

@Configuration public class WebMvcConfig implements WebMvcConfigurer { @Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/images/**") .addResourceLocations("file:" + uploadDir + "/"); } }

这样用户上传的/images/xxx.jpg就能直接通过浏览器访问。注意addResourceLocations里的file:前缀不能漏，否则Spring会把路径当成classpath路径去找，永远找不到。

如果项目用了Nginx做静态资源服务，那更好：Nginx直接配置location /images/ { alias /data/bookstore/images/; }，后端的映射都不需要了。但毕设项目一般没有单独的Nginx环境，上面的配置类方案足够。

4. 前端方案与接口设计

4.1 Thymeleaf还是Vue：两条路线怎么选

热搜词里“springboot vue前后端分离”和“springboot thymeleaf热更新”同时出现，说明这是两条主流的实现路线。

Thymeleaf路线（服务端渲染）：

适合时间紧、不想维护两个项目、且对前端不熟悉的同学。Thymeleaf和Spring Boot整合非常顺滑，页面文件放在src/main/resources/templates下，Controller返回视图名，通过model.addAttribute()传数据。需要注意：

• 模板缓存默认开启，改了HTML要重启才生效。开发时在application-dev.yml中设置spring.thymeleaf.cache=false，配合spring-boot-devtools实现热更新。
• 静态资源（CSS/JS/图片）放src/main/resources/static下，模板里引用时用th:href="@{/css/style.css}"语法。

Vue前后端分离路线：

适合求职项目、想展示“前后端分离能力”的同学。Vue项目单独维护，通过Axios调用后端接口。好处是后期扩展小程序/App时后端可以直接复用。代价是你需要额外处理跨域问题：

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

如果前端用了withCredentials携带Cookie，addAllowedOriginPattern("*")和allowCredentials(true)必须配合使用，否则浏览器会拦截响应。用JWT方案的话，实际不需要allowCredentials(true)，建议直接关掉，省去很多麻烦。

我个人的建议是：毕设优先选Thymeleaf，就业项目优先选Vue。原因很简单：毕设的核心是“管理系统业务逻辑完整、运行稳定”，你不希望花大量时间在Vue的构建配置和联调上；而求职时，企业对这个项目的期待是能放到简历上的技术栈展示，Vue + Spring Boot前后端分离本身就是亮点。

4.2 RESTful接口设计规范：别把接口随心情写

后端接口设计直接影响前后端联调的效率。书店管理系统建议统一遵循以下规范：

• 路径命名：全部用名词复数，如/api/books、/api/orders、/api/carousel；
• HTTP方法语义化：GET /api/books（分页列表）、POST /api/books（新增）、PUT /api/books/{id}（修改）、DELETE /api/books/{id}（删除）、PUT /api/books/{id}/status（上下架）；
• 统一响应体：后端接口返回统一的JSON结构：

{ "code": 200, "message": "success", "data": { } }

定义一个Result<T>泛型类，所有Controller都返回它。这样前端只需要统一的拦截器处理code和message，不用每个接口单独猜字段。有些同学偷懒直接返回Map或Entity，短期没问题，但只要加一个字段或报错，前端就要改一堆代码。

4.3 接口鉴权：哪些接口必须登录

接口鉴权总体策略如下：

接口范围	鉴权策略
/api/auth/login、/api/auth/register	匿名可访问
/api/books、/api/books/{id}	匿名可访问（仅看已上架数据）
/api/books/**、/api/orders/**等管理接口	必须管理员（role=ADMIN）
/api/cart/**、/api/orders（用户下单）	必须登录（role=USER）

拦截器的实现里要区分“是否登录”和“角色是否匹配”。一种简单的做法：Token的claims里存role字段，拦截器判断当前请求路径前缀，如果是/api/admin/**，就校验role是否为ADMIN。网上很多代码只判断了“有没有Token”，却没有判断“权限够不够”，这是很严重的安全漏洞——任何人只要注册个用户就能进后台，那整个系统就没有意义了。

5. 项目构建、打包与部署

5.1 Maven构建与依赖管理

书店管理系统用Maven构建是标配。pom.xml里最核心的是继承Spring Boot父工程：

<parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>2.7.18</version> <relativePath/> </parent>

这里有个很实用的经验：Maven依赖冲突是排查成本最高的问题。比如引入MyBatis-Plus后，它的传递依赖版本可能和Spring Boot的某个组件版本不匹配。使用spring-boot-starter-parent统一版本管理后，大部分依赖的版本号都不用写，Spring Boot已经帮你锁定了兼容版本。尽量不要为了“用最新版”而手动覆盖版本号，否则一旦出现依赖冲突，排查一晚上的时间不如直接回到默认版本。

5.2 打包运行：从jar到Docker

开发环境用IDEA直接运行主类，但部署必须打成可执行jar包：

mvn clean package -DskipTests java -jar target/bookstore-0.0.1-SNAPSHOT.jar --spring.profiles.active=prod

生产环境的Docker部署方案也很直观，Dockerfile可以这样写：

FROM openjdk:11-jre-slim WORKDIR /app COPY target/bookstore-0.0.1-SNAPSHOT.jar app.jar EXPOSE 8080 ENV SPRING_PROFILES_ACTIVE=prod ENTRYPOINT ["java", "-jar", "app.jar"]

宿主机上挂载/data/bookstore目录到容器内对应配置的上传目录，MySQL和Redis直接以容器方式一并起在同一个Docker Compose网络里即可。毕设如果要在答辩现场演示，Docker一键起的方案比“现场配环境变量”靠谱得多，也体面得多。

5.3 配置里的坑：时区、端口和数据库地址

搜“springboot yml 随机端口”说明很多人想搞“端口不固定”的骚操作，其实随机端口的正确用途是服务注册到注册中心时避免本地端口冲突，对单体书店系统来说并不适用。我建议直接用固定端口（默认8080，生产环境换一个不常见端口比如8090），便于前端联调和Nginx转发。

另外两个必踩的坑提前预警：

第一个是MySQL时区问题。如果你的数据库连接串里没有加serverTimezone=Asia/Shanghai，查询出的时间可能比实际时间少8小时。这是JDBC驱动和数据库时区不一致导致的。推荐连接串：

jdbc:mysql://localhost:3306/bookstore?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false

第二个是Redis连接问题。本地开发时Redis默认没有密码，但生产环境几乎都会设置密码。如果两个环境的配置文件没有分开，部署时就会在Redis连接上卡住。这也是我前面强调多环境配置文件分离的原因。

6. 常见问题与避坑实录

6.1 Spring Boot版本太高导致“教程失效”

“springboot版本太高”这个搜索热词我太有共鸣了。常见的翻车场景是：跟着B站的Spring Boot 2.x教程写代码，自己的项目却是3.x，结果javax.servlet找不到、spring.factories文件写法变了、WebSecurityConfigurerAdapter被废弃了，整个人当场裂开。

我的建议非常明确：新项目做毕设，无脑选2.7.x + JDK 8。2.7.x是Spring Boot 2.x最后一个稳定版本，生态资料极其丰富，网上几乎所有教程的代码都能直接跑。如果已经用了3.x，遇到老教程的代码，先做的不是改代码，而是区分哪些类在新版本中换了包路径或已被移除。简单说：javax换成jakarta，WebSecurityConfigurerAdapter改成SecurityFilterChain的Bean配置，spring.factories改成AutoConfiguration.imports。这个排查过程很磨人，但也是学习和理解框架演进的真实机会。

6.2 “jar反编译成项目”是什么情况，怎么处理

热搜里有一条“怎么将springboot jar反编译成项目”，这说明很多人的源码丢了，或者想“借鉴”别人的完整项目。技术上确实可以反编译：用IDEA自带的反编译模块打开jar包，能还原出.class文件的绝大部分Java代码，资源文件和配置文件（application.yml、static、templates）也能直接解压出来。但我要提醒一句：反编译得到的代码可能丢失注解参数默认值、局部变量名、注释，甚至因为混淆混淆后逻辑不通，直接用基本跑不起来。而且，拿别人的源码去交自己的毕设，属于学术不端，不仅没有意义，风险也很大。

正确的做法：把反编译当作理解他人思路的手段，而不是直接抄。比如想知道某个订单状态流转是怎么写的，反编译看一下思路，然后自己重新实现一遍，这才是对技术有帮助的方式。另外，如果你的源码丢了，可以从头用前面讲的方案重新搭核心功能——这个系统总共就那些表那些接口，按章节四的操作，一天能搭完核心骨架。

6.3 端口占用、连接被拒与日志排查三板斧

开发过程中最常见的报错大概有这些：

报错现象	排查思路	解决办法
Port 8080 was already in use	端口被其他程序占用	`netstat -ano
Communications link failure	数据库地址/账号/时区配置错误	确认MySQL已启动，检查spring.datasource.url和账号密码，先本地用客户端工具连一下
Failed to determine a suitable driver class	数据库驱动依赖缺失	确认pom.xml已引入mysql-connector-java（2.7.x）或com.mysql:mysql-connector-j（3.x）
Redis connection refused	Redis未启动或密码不对	本地先redis-server或启动Docker容器，检查spring.redis.host/port
接口返回401/403	Token未传或权限不足	检查前端请求是否加了Authorization头，拦截器路径是否配置了排除项

排查这类问题，我的习惯是三步走：先看启动日志有没有报错堆栈，再看配置文件有没有写错，最后用Postman/curl直接调接口绕过前端排查。很多同学一报错就在网上搜了半天，其实50%的问题只要看一行日志就能定位。

6.4 “答辩的时候老师问我做了哪些优化，我该怎么讲？”

这个问题实际上是“如何展现项目深度”。书店管理系统如果只是CRUD，答辩老师会觉得平平无奇。建议从以下维度准备三个“可讲细节”：

1. 数据库设计层面：解释订单快照的冗余设计（order_item存book_title和book_cover）——为什么要冗余、不冗余会有什么问题；
2. 并发控制层面：讲库存扣减的乐观锁SQL（stock > 0条件）、事务回滚机制、为什么不直接用synchronized锁；
3. 安全层面：密码BCrypt加密、JWT的签名与过期、接口权限角色区分、SQL注入的防护（MyBatis的#{}预编译与${}拼接风险）。

把这三个点讲清楚，比堆砌“我用了Redis缓存”“我用了Spring Cloud”这些没有实际承载的词汇更能说服人。亮点从来不是技术名词的堆砌，而是每个技术选择都有具体的业务理由和落地场景。

7. 从“能跑”到“好讲”的最后一公里

项目做到能跑通只是第一步，答辩或面试演示时的“讲解路径”比代码本身更重要。

我的建议是提前准备好一整条演示动线：先展示用户端首页（轮播图、图书列表、分类导航）→ 搜索/筛选图书 → 注册登录 → 加入购物车 → 提交订单 → 切换管理员登录 → 进入后台（图书上下架、订单发货处理）→ 最后切到数据库表结构设计（展开几张核心表讲设计）→ 再切到Docker部署页（说明如何一键部署）。整个过程控制在8到10分钟，每一段都有一句“我为什么这么设计”的解释。

另外一个小技巧：在项目里预留一两个“可现场改代码”的扩展点。比如在BookService里预留一个recommendBooks()方法，注释里写“后续可以接入用户行为数据做个性化推荐”，答辩时老师如果说“你还有什么可改进的”，你就可以自然地接住。这不是套路，而是真实的工程思维——系统从来不是做死的，而是留给后续演进空间的。

从技术栈的选择、表结构的设计、核心模块的实现到最后的部署和答辩演示，书店管理系统看似是一个普通的CRUD项目，但认真做完，它完全可以成为你Java后端能力的一个完整缩影。把Spring Boot的自动装配原理、MyBatis-Plus的便捷与局限、事务和乐观锁的实战、JWT和拦截器的鉴权方案亲手过一遍，这些经验会沉淀成你面对下一个项目时的底气。躲猫猫的乐趣在于发现和被发现的惊喜，做项目也一样——在一次次踩坑和排查里，你总会和更熟练的自己撞个满怀。