企业官网建设流程全解析

简介：面向计算机相关专业毕业生的二手图书交易平台毕业设计项目，以Java为后端实现，附带完整论文、源码、数据库脚本与说明文档，既能用于课题设计与系统开发，也能支撑论文撰写和答辩准备。资源包共205个文件，总大小49.11MB，其中Java源码与编译class文件共34个，前端涵盖HTML页面、62个JS脚本、42个CSS样式及字体图标文件，另有SQL数据库脚本和Word格式论文文档，目录结构清晰，便于按模块查阅。论文内容覆盖可行性分析、业务流程、需求分析、数据流图、总体设计、数据库详细设计、系统实现与测试等完整章节，并包含用户、商品、订单、购物车等核心业务模块的代码实现，可帮助读者快速理解从需求到落地的开发全流程。整个项目遵循软件工程规范，从设计到测试行文完整，为类似电商类毕业设计提供可复用的思路与模板。目前已有72人学习，适合正在筹备毕业设计或需要参考真实Java Web项目案例的学生使用，也可作为课程设计、项目实训的参考资料。

1. 毕业设计选 Java 二手图书交易平台，到底在做什么

每年大四下学期，总有一批人被同一个问题卡住：Java 课程学了一堆，但真要独立做一套能过答辩、能写出论文、还能讲清楚系统的项目时，不知道该从哪下手。二手图书交易平台是这类场景里最经典的选择之一，它不碰高并发、不碰分布式，把用户、商品、订单、购物车这几个核心模块做扎实，就足够覆盖一套完整 Web 系统的全部知识点。这类项目的好处是边界清晰：前端页面能看得见，后端接口能测得到，数据库表结构能画得出来，论文每章都有实际代码和截图撑着，不会出现“系统做了但写不出东西”的尴尬。

这篇笔记面向的是正在做 Java 课程设计或毕业设计的人。我会把二手图书交易平台从技术选型、数据库设计、核心功能实现、论文撰写到答辩避坑整条链路拆开讲。所有代码都按 Spring Boot + MyBatis + MySQL 这套主流组合来写，这也是目前 Java 后端项目中最容易上手、最不容易在环境上翻车的搭配。你不需要会微服务，不需要碰中间件，把单体应用跑通、把 CRUD 写明白、把事务和权限处理好，就已经达到本科毕业设计的优秀线了。

2. 技术选型与数据库设计：先把地基打牢，后面才不返工

2.1 为什么是 Spring Boot + MyBatis + MySQL，而不是其他组合

常见做法是直接选 Spring Boot 2.x + MyBatis + MySQL 8.x。Spring Boot 负责把 Spring 的配置自动化，不用再写那一大堆 XML；MyBatis 负责 SQL 与 Java 方法的映射，适合需要手写复杂查询的业务；MySQL 负责存数据，免费且资料量大，出个报错信息一搜就有答案，不会像某些商业数据库那样在环境问题上消耗大量时间。

也有不少人用 JSP + Servlet 做传统 JavaWeb，或者用 Spring Boot + JPA。我的看法是：如果论文里需要体现“手写 SQL 的能力”，MyBatis 比 JPA 更容易展示；如果你的前端基础弱，不想写 Vue 和 React，就用 Thymeleaf 模板引擎直接渲染页面，把前后端放在同一个工程里，部署时打一个 jar 包就能跑，既少了跨域问题，也少了 Nginx 配置这道坎。反过来，如果论文想表达“前后端分离”这个亮点，那就用 Vue + Spring Boot 做成 RESTful API 风格。两条路我都走过，各有取舍，但从答辩角度来说，能讲清楚自己的选择依据比选什么本身更重要。

2.2 数据库表结构设计：六张表怎么划分

二手图书交易平台的表结构是整套系统的核心，也是论文里“数据库设计”一章的主要内容。我一般会按用户、图书、购物车、订单、分类、轮播图这六个维度来拆表。以下是我在实战中反复调整后稳定下来的建表 SQL，直接对照着用即可。

CREATE TABLE t_user ( id INT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(32) UNIQUE NOT NULL COMMENT '登录名', password VARCHAR(128) NOT NULL COMMENT '加密后的密码', nickname VARCHAR(32) COMMENT '昵称', phone VARCHAR(11), avatar VARCHAR(255) COMMENT '头像路径', role TINYINT DEFAULT 1 COMMENT '1买家 2管理员', create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE t_category ( id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(32) NOT NULL, sort_order INT DEFAULT 0 ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE t_book ( id INT PRIMARY KEY AUTO_INCREMENT, title VARCHAR(128) NOT NULL COMMENT '书名', author VARCHAR(32), publisher VARCHAR(64), price DECIMAL(8,2) COMMENT '原价', sell_price DECIMAL(8,2) COMMENT '售价', category_id INT, cover VARCHAR(255) COMMENT '封面图片路径', description TEXT COMMENT '书况描述', status TINYINT DEFAULT 1 COMMENT '1在售 0已下架 2已售出', seller_id INT COMMENT '发布者', create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE t_cart ( id INT PRIMARY KEY AUTO_INCREMENT, user_id INT NOT NULL, book_id INT NOT NULL, quantity INT DEFAULT 1, create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE t_order ( id INT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(64) UNIQUE COMMENT '订单编号', user_id INT COMMENT '买家', seller_id INT COMMENT '卖家', total_amount DECIMAL(10,2), status TINYINT DEFAULT 0 COMMENT '0待支付 1已支付 2已发货 3已完成 4已取消', address VARCHAR(255), create_time DATETIME DEFAULT CURRENT_TIMESTAMP, pay_time DATETIME ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE t_order_item ( id INT PRIMARY KEY AUTO_INCREMENT, order_id INT, book_id INT, title VARCHAR(128), price DECIMAL(8,2), quantity INT ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

这段 SQL 里有几个设计点值得专门说明。第一，密码字段没有用明文，password 字段长度设成 128，给 SHA-256 加盐后（实际上 BCrypt 更像答案）预留足够的空间。第二，t_order 表里同时存了 buyer_id 和 seller_id，二手交易的特殊之处在于同一个订单涉及买卖双方，后续在“我买到的”和“我卖出的”这两个列表里要分别按不同字段查询。第三，t_order_item 冗余了图书名称和价格，这么做看起来不太符合三范式，但实际是故意为之，订单生成后图书可能被修改或删除，如果不做冗余，历史订单的展示数据就会丢失。

2.3 数据库设计时的三条血泪经验

设计阶段最容易翻车的不是表结构画不出来，而是业务边界没划清。第一个常见坑是“一个用户既买东西又卖东西，那还分不分角色”——我的做法是 t_user 表只保留一个 role 字段，1 表示买家，2 表示管理员。二手平台的用户本身就是卖家的角色，任何人登录后都可以发布图书，没必要把“卖家”设成一种需要申请的角色，这会平白增加很多审批逻辑。

第二个坑是删除策略。图书被下架后，购物车里还残留着这本书的信息，此时点击结算会发生空指针。所以 t_book 表的 status 字段不能省，用逻辑删除而不是物理删除，购物车和订单里的数据都要先查图书状态再继续业务流程。

第三个坑是金额字段类型。价格一律用 DECIMAL，不要用 FLOAT 或 DOUBLE，这在 Java 侧的对应类型是 BigDecimal。浮点数在二进制中无法精确表示，比如 0.1 加 0.2 得到的是 0.30000000000000004，一旦在订单金额上出现这种精度误差，论文答辩时被老师追问会非常尴尬。

3. 核心功能搭建：登录、图书展示、购物车与订单实现

3.1 工程结构与后端分层如何组织

前端页面我用 Thymeleaf 做服务端渲染，后端按 controller、service、mapper、entity、config 五个包来分层。以下是实际工程中 controller 层的代码骨架，其余层的代码都是围绕它展开的：

@Controller @RequestMapping("/book") public class BookController { @Autowired private BookService bookService; @Autowired private CategoryService categoryService; // 首页图书列表，带分页，支持按分类和关键字筛选 @GetMapping("/list") public String list(@RequestParam(defaultValue = "1") Integer pageNum, @RequestParam(defaultValue = "8") Integer pageSize, @RequestParam(required = false) Integer categoryId, @RequestParam(required = false) String keyword, Model model) { PageInfo<BookVO> pageInfo = bookService.queryPage(pageNum, pageSize, categoryId, keyword); model.addAttribute("pageInfo", pageInfo); model.addAttribute("categoryList", categoryService.listAll()); return "book/list"; } // 图书详情 @GetMapping("/detail/{id}") public String detail(@PathVariable Integer id, Model model) { BookVO book = bookService.getDetail(id); model.addAttribute("book", book); return "book/detail"; } // 发布图书（卖家操作） @PostMapping("/publish") public String publish(@Validated BookForm form, BindingResult result, @RequestParam("file") MultipartFile file, HttpSession session) { if (result.hasErrors()) { return "book/publish"; } User user = (User) session.getAttribute("loginUser"); bookService.publish(form, file, user.getId()); return "redirect:/book/myPublish"; } }

注意上面的代码全部是“返回视图名 + Model”的写法，这是 Thymeleaf 渲染方式的典型特征，必须配一个静态页面模板才能看到效果。如果选择前后端分离，则需要把返回值改成@ResponseBody加 Result 包装类。

分页用的PageHelper是国产插件，底层原理是拦截 MyBatis 的 Executor，在运行时动态拼接 LIMIT 语句，用起来非常方便。pageNum默认值为 1，pageSize为 8，这意味着首页每页显示 8 本图书。参数校验用@Validated注解，需要添加 spring-boot-starter-validation 依赖，否则注解不会生效，这是一个很容易被忽视的配置点。

3.2 用户登录：Session 与拦截器必须配套

登录模块是答辩时老师几乎必问的功能，它的核心不是“能用”，而是“安全”。很多课程设计项目直接用明文密码存库，登录后把用户对象丢进 Session 就结束，这在实际求职或项目复盘时都是硬伤。下面给出一个经过整理的登录代码示例：

@Service public class UserServiceImpl implements UserService { @Autowired private UserMapper userMapper; // BCrypt 加密，内置盐和随机因子，比 MD5 更可靠 @Autowired private BCryptPasswordEncoder passwordEncoder; @Override public User login(String username, String password) { User user = userMapper.selectByUsername(username); if (user != null && passwordEncoder.matches(password, user.getPassword())) { return user; } return null; } @Override public boolean register(User user) { String rawPassword = user.getPassword(); String encodedPassword = passwordEncoder.encode(rawPassword); user.setPassword(encodedPassword); return userMapper.insert(user) > 0; } }

配套的拦截器负责拦截未登录用户的访问请求：

public class AuthInterceptor implements HandlerInterceptor { // 在进入 Controller 之前执行。如果未登录，重定向到登录页 @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { HttpSession session = request.getSession(); User user = (User) session.getAttribute("loginUser"); if (user == null) { response.sendRedirect("/login"); return false; } return true; } }

密码为什么不能用 MD5？原因在于 MD5 是纯哈希算法，没有盐值参与时，攻击者可以直接用彩虹表撞库。BCrypt 会在哈希过程中自动加入随机盐，并且这个过程是单向且计算缓慢的，暴力破解成本非常高，这也是 Spring Security 官方推荐的加密方式。在 application.properties 中需要注入BCryptPasswordEncoder这个 Bean，不改配置直接@Autowired会报“找不到类型为 BCryptPasswordEncoder 的 Bean”，这个细节代码里别忘了。

3.3 图书上架与图片上传：文件路径是最大的坑

图书发布功能里包含图片上传。实际开发中，图片上传的坑主要不在代码，而在路径配置。代码层面的解决方案如下：

@Configuration public class WebConfig implements WebMvcConfigurer { @Value("${file.upload-path}") private String uploadPath; @Override public void addResourceHandlers(ResourceHandlerRegistry registry) { // 把 /upload/** 映射到本地磁盘目录 registry.addResourceHandler("/upload/**") .addResourceLocations("file:" + uploadPath); } }

同时在 application.properties 文件里加上：

file.upload-path=/home/ubuntu/upload/

这段配置的意义在于：浏览器访问http://localhost:8080/upload/xxx.jpg时，Spring Boot 会从本地磁盘路径读取文件。如果你没做这一步，上传后页面图片会 404，这是新手最容易翻车的地方。另一个注意点是目录分隔符要写对，Windows 环境下要写成D:/upload/，不要用反斜杠结尾，否则在某些系统上路径拼接会出错。

3.4 订单流程：事务与状态机是看不见的安全网

下单是整个平台最核心的链路，涉及多张表的数据变化，必须加事务。下面是下单逻辑的实现思路，为了保证代码可读性，这里用伪代码框架表达关键流程：

@Transactional(rollbackFor = Exception.class) public Order createOrder(CreateOrderRequest req, Integer buyerId) { // 1. 查询购物车中选中的图书条目 List<CartItem> cartItems = cartMapper.selectCheckedItems(req.getCartItemIds()); if (cartItems.isEmpty()) { throw new BusinessException("购物车为空，无法下单"); } // 2. 生成订单号，格式：时间戳 + 用户ID + 随机数 String orderNo = "BO" + System.currentTimeMillis() + buyerId; // 3. 创建主订单 Order order = new Order(); order.setOrderNo(orderNo); order.setUserId(buyerId); // 注意：这里需要判断卖家的统一性，一个订单只属于一个卖家 // 4. 插入订单明细（从购物车冗余复制数据） for (CartItem item : cartItems) { Book book = bookMapper.selectById(item.getBookId()); // 关键校验：图书状态是否在售，防止并发下单 if (!Integer.valueOf(1).equals(book.getStatus())) { throw new BusinessException(book.getTitle() + " 已下架或已售出"); } // 更新图书状态为已售出 book.setStatus(2); bookMapper.update(book); // 插入 order_item 明细 } // 5. 清空购物车中已下单的商品 cartMapper.deleteBatchIds(req.getCartItemIds()); return order; }

需要特别提醒的是@Transactional注解默认只回滚 RuntimeException，不会拦截检查异常，因此在rollbackFor属性中要显式指定Exception.class，这是面试高频追问点，答辩时能准确说出来是加分项。状态机的逻辑埋在下单操作里：图书有“在售、下架、已售出”三种状态，下单时把“在售”改为“已售出”，如果这步不做校验，两个用户同时购买同一本书就会出现超卖问题。

这里需要补一句：真正玩过这套流程的人会明白，电商系统的状态机远不止这么简单，还需要处理支付超时、取消订单、退货退款等边界情况。对于毕业设计而言，把“创建订单→支付→发货→完成”这条主线的状态扭转做好，再把“取消订单”分成买家取消和卖家取消两种场景，已经能写出一定的业务深度，足够在答辩中展示。

4. 论文怎么写出彩：需求分析到系统测试的完整落笔逻辑

4.1 论文各章结构与每个章节该写什么

很多人的论文“写不出来”，本质是没搞清楚论文和项目的对应关系，才会导致系统做完了论文只能抄笔记。我在完成项目后，论文结构保持不变，但每个章节的落笔逻辑做了适当调整。按照常见的本科毕业设计论文模板，七章或八章的结构是主流，核心逻辑如下：

需求分析这一章，不要写“用户登录系统、用户可以买书”这种废话式描述。正确做法是画出用例图，把参与者分成游客、买家、卖家、管理员四类，然后列出每个角色对应的一级用例。功能需求之外必须写非功能需求，包括性能指标（首页响应时间小于 2 秒）、安全需求（密码不能明文存储，SQL 注入怎么防御）、可用性需求（断网提示友好，不崩页面）。这一部分是评审老师判断你是否真的从用户角度思考问题的重要依据。

总体设计章节放系统架构图和技术架构图。系统架构图用分层结构画，展示表现层、业务层、数据层之间的关系；技术架构图标注 Spring Boot、MyBatis、MySQL、Thymeleaf 之间的关系。接口设计这一块可以用表格列出所有 RESTful 接口，比如 POST /api/order（创建订单）、GET /api/book/list（分页查询图书），每个接口写清楚参数、返回状态码和含义。千万不要把接口文档写成“方法名+参数个数”，老师一眼就能看出来你根本没有真正调试过。

详细设计章节的写法有一点需要格外注意，不是把控制器的每个方法抄一遍，而是选 2~3 个核心流程画时序图或流程图，再配核心代码片段做解释。下单流程是最合适的素材，又体现事务又体现状态机，同时也让代码展示有层次感；登录鉴权流程也值得写，它包含了拦截器设计、密码加解密、Session 管理三个知识点。代码别贴太长，控制在 50 行以内，必须带文字说明。

数据库章节则直接复用我们建表时的设计，画出每个表的字段说明表、ER 图，并写清楚一张订单表同时存储买卖双方 ID 的设计原因。

4.2 说明文档的写作技巧：从“平铺直叙”到“面向运维”的落地写法

这部分要重点说，因为很多读者的需求不局限于论文本身，还希望自己做完项目后，把说明文档写好。毕业设计附带的说明文档通常是给导师或者答辩老师看的，本质作用是一份“可以按步骤跑起来”的部署手册，它是整个项目交付物中最后被翻看、却也是最能直接暴露问题的一份文件。说明文档最忌讳两种叙述方式：一种是只写“安装 JDK、下载项目、点击运行”，太过粗糙；另一种是把项目的全部代码打印一遍，太过冗长。

我习惯把说明文档定位成三分结构：项目环境清单（JDK、MySQL、Maven 的版本号，操作系统）、分步部署流程（每一步命令 + 预期结果）、常见故障对照表（报错信息 + 原因 + 处理办法）。关键配置信息要标明位置——数据库连接串在哪一个 properties 文件、端口在哪修改、初始化 SQL 在哪执行。

这里分享一个实际的部署路径，这套命令在 Ubuntu 终端里逐行执行可以跑通，Windows 环境可参照调整，本质是相同的操作步骤，核心思路是“前后端在一个工程里、数据库脚本文件先导入、再启动 jar 包”：

# 导入初始化数据库（-u 和 -p 后不要加空格，这两个参数的含义是数据库用户名与密码） mysql -uroot -p123456 < db/init.sql # 构建可执行 jar 包，跳过测试避免连不上数据库导致构建报错 mvn clean package -DskipTests # 启动 Spring Boot 应用，可以用 nohup 后台运行 java -jar target/second-hand-book-0.0.1-SNAPSHOT.jar --server.port=8080 # 启动成功后自动打印日志，看到 "Started ... in x seconds"，说明启动成功

把这几条命令放进说明文档的“部署运维”一节，再加上一个预期结果描述——浏览器访问http://localhost:8080能打开首页——任何一个人拿到你的压缩包，按步骤做最多 30 分钟就能跑起来。越是这类细节，越能体现一个开发者对交付质量的判断力。

4.3 论文查重与代码附件的边界处理

论文是文字类的交付，还涉及两个容易踩坑的点。第一是查重。系统设计、数据库设计这些章节容易和同班同学的模板高度重合，我的习惯是数据库表结构的字段说明做成表格，每张表单独一行描述；核心代码用“关键代码段 + 注释”来呈现，不要整个文件粘进去。第二是在论文末尾附主要源码清单。很多人不知道该把哪些代码放进去，全贴又厚又显得没主见，我这里建议只放以下文件：pom.xml（前 50 行）、application.properties、UserController、BookController、OrderController、创建表和初始化数据的 SQL 脚本。代码行数在 400 行以内，既能证明工作量，又不会让论文显得像源码印刷册。

5. 项目部署与运行避坑：5 个高频故障的完整排查思路

5.1 图片上传后无法访问，页面 404

现象：项目启动正常，图书发布成功，但前端页面图片位置显示裂图，浏览器直接访问图片路径返回 404。原因：Spring Boot 默认只映射 classpath 下的 static 目录，不会自动把磁盘路径变成 HTTP 可访问资源，上传的图片保存到了本机，但请求路径没有映射到本机目录。解决：在配置类中重写addResourceHandlers，把/upload/**映射到file:开头的本地磁盘路径。其次要检查上传文件时是否把完整相对路径存入了数据库，只存“相对路径 /upload/xxx.jpg”才是正确姿势，不要把F:/xxx/upload/xxx.jpg这种绝对路径写进数据库，否则换一台机器运行就全部失效。

5.2 部署到服务器后出现中文乱码

现象：本地运行一切正常，部署到 Linux 服务器后，前端页面显示“？？？”或乱码，管理员在后台上传的图书名称也变乱码。原因：MySQL 连接串没有指定 UTF-8，或数据库默认字符集不是 utf8mb4。解决：建库时用CREATE DATABASE xxx DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;，同时连接串增加参数characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai。这两处修改要同时在数据库端和应用端做，只改一处还会出现部分正常部分乱码的诡异情况，这种问题属于最典型的“黑匣子”故障，不打印 SQL 日志几乎看不出。

5.3 Maven 依赖冲突或打包后包体异常大

现象：本地 IDE 运行正常，打包后报NoClassDefFoundError，或打出的 jar 比预期小，页面加载缺少静态资源。原因：SPRING BOOT MAVEN PLUGIN 没有正确配置，打出来的是普通 jar 而不是可执行 fat jar；另一种情况是本地引入的依赖与 Spring Boot 版本不匹配。解决：pom.xml 的 build 节点中必须加入如下配置：

<build> <plugins> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> <version>2.7.14</version> </plugin> </plugins> </build>

依赖冲突问题的定位思路在面试真题中也常被追问。现象多种多样，报错信息里能看到NoClassDefFoundError或ClassNotFoundException，说明类存在于编译环境但运行时被排除了。解决是使用mvn dependency:tree查看依赖树，定位重复类来自哪两个依赖，然后在 pom.xml 中用<exclusions>排除不需要的那个。毕业设计用到的依赖不多，最常见的冲突发生在 MySQL 驱动版本和 Druid 连接池之间。

5.4 上传文件大小超限，提示 Failed to parse multipart servlet request

现象：选择一张大于 1MB 的图片做封面时，后端抛异常，Spring Boot 默认限制单文件大小为 1MB。原因：Spring Boot 内嵌 Tomcat 对MaxFileSize的默认值是 1MB，MaxRequestSize默认值是 10MB，如果不改配置，上传稍大的封面图就会直接报错。解决：在 application.properties 中增加一段配置。同时要注意这段配置的版本兼容性，Spring Boot 2.x 和 3.x 的配置项格式是相同的：

# 单文件大小上限，可改为 20MB spring.servlet.multipart.max-file-size=10MB # 单个请求总大小上限，包含多个文件的情形 spring.servlet.multipart.max-request-size=20MB

5.5 本地跑通了，换电脑后连不上数据库

现象：把项目源码复制到另一台电脑，运行时报Access denied for user 'root'@'localhost'或Communications link failure。原因：对方电脑的 MySQL 密码不同或没有启动服务，而连接配置写死在 application.properties。解决：把配置改成从环境变量读取，这样在交付代码时可以保留默认值，但每台机器上都能灵活覆盖：

spring.datasource.url=${DB_URL:jdbc:mysql://localhost:3306/second_book?characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai} spring.datasource.username=${DB_USERNAME:root} spring.datasource.password=${DB_PASSWORD:123456}

这段配置的写法是环境变量:默认值的形式。启动时如果显式传入了环境变量，就用环境变量；没传入时就用冒号后的默认值兜底。这种方法在多人协作的项目中很实用，能避免每个人拿到代码后都要手动改配置文件，也是面试中可以顺手提及的一个细节。

6. 答辩与交付的加分操作：把项目从“能跑”变成“能讲清”

到了收尾阶段，你已经有了完整的源码、数据库脚本和论文文稿，但距离答辩通过还差最后一步：把项目里的设计亮点用自己的话讲出来。很多人的翻车现场是：代码是自己写的，但被老师一句“你这里为什么用 Redis 而不用本地 Map”问住了。下面给出几个常用的加分方向，不需要额外实现，但答辩时被问到设计决策时可以直接用。

领域模型层面的设计亮点，比如图书状态的“在售、已下架、已售出”三态转换，以及下单时将图书标为“已售出”来防止超卖，这是业务逻辑层面的思考成果。安全层面的亮点有 BCrypt 密码加密、SQL 注入的预编译处理、基于拦截器的登录鉴权，这些点都是安全的综合性体现。数据库层面的亮点是订单表的字段冗余设计和订单号的无序生成策略，配合数据库索引应对多条件分页查询的问题。

验证方法上，我习惯在正式答辩前按三层做自测：第一层是功能链路，把“注册→登录→发布图书→浏览→加入购物车→下单→支付→发货→完成”整条链路走一遍；第二层是异常链路，分别用错误密码登录、重复用户名注册、购买已下架图书、超过文件大小限制上传等操作触发错误，确认提示信息是“XXX 错误，请重试”而不是大堆异常堆栈；第三层是数据校验，检查数据库里订单金额与图书价格是否一致、订单明细是否冗余生成、用户删除后历史订单是否能正常显示。

最后说一个第一人称的教训。带过不少同专业的人做课程设计，有一次看到学弟在答辩 PPT 里放了一大页 Docker 部署命令来展示“容器化部署”，结果老师问“容器和虚拟机的区别是什么”，他一紧张就答不上来，反而让整个项目的可信度下降。从那以后，我养成一个习惯：任何写进论文或 PPT 的技术点，都必须做到能用两句话说清“为什么用它、它解决了什么问题”，说不清的点就不写。这个习惯也延续到了现在的工作中。如果你正卡在某个环节，建议从数据库脚本开始重跑一遍，对照上面讲的部署命令逐步执行，绝大多数问题都能在前面那几条排查思路中找到答案，希望帮到你。

本文还有配套的精品资源，点击获取