企业官网建设流程全解析

我上个月刚帮一个学弟把"攀枝花学院二手物品在线交易系统"这个毕设项目从头到尾过了一遍。说实话，看到选题的时候我觉得这题选得挺聪明——校园二手交易，既不是烂大街到毫无技术含量的图书管理，也不是大到一个人做不完的电商平台，它恰好落在"毕设工作量饱和、技术栈经典、业务故事完整"这三个甜蜜点上。后来我陪他查重、改Bug、模拟答辩，折腾了两个多星期，中间被答辩老师可能问的问题逼着把很多细节重新梳理了一遍，整个过程有不少值得拿出来讲的东西。

如果你也是计算机专业本科生，正在纠结毕设题目，或者已经选了类似"Java + SpringBoot校园二手交易平台"的题目，那这篇博文就是写给你看的。我会把从选题逻辑、技术选型、数据库设计、核心代码实现，到最终答辩准备这条完整路线全部拆开讲，全部是我实操过、验证过的内容，不绕弯子。

1. 为什么"校园二手交易平台"是毕设选题的稳妥之选

1.1 毕设选题的普遍困境与这个题目的优势

每年到了开题季，我都能收到一堆"学长我这题能行吗"的私信。归纳一下大家遇到的问题，基本就三类：第一类是题目太简单，比如"图书管理系统"，代码量一旦不够，论文就严重注水，答辩时老师在台上问一句"你这个系统除了增删改查还有什么技术难点"，当场就冷场；第二类是题目太难，比如"分布式秒杀系统"，从Redis到消息队列到高并发压测，一个人别说做完，光是部署集群就能耗掉一半时间；第三类是题目太空，比如"基于AI的智能推荐系统"，需求模糊、边界不清晰，做着做着就不知道该干什么了。

校园二手物品交易平台恰好绕开了这三个雷区。首先，它的业务场景非常真实——高校里的闲置物品交易是硬需求，大一买的教材大二用不上、毕业季的自行车和台灯、换了新手机之后淘汰下来的旧手机，这些都是学生身边每天都在发生的事情。这个真实性带来的直接好处是：需求分析部分不用瞎编，论文里随便写几个典型用户场景都站得住脚。其次，它的功能边界清晰得令人发指，系统里有哪些角色、每个角色能干什么、流程怎么走，套用二手交易的习惯规则就能梳理得清清楚楚。最后，它的技术覆盖面够广，登录鉴权、上传图片、模糊搜索、订单状态流转、权限拦截，每一样都是Java Web开发的基本功。

1.2 针对"攀枝花学院"这类具体高校场景做系统定位

题目里带了具体校名，其实是件好事。毕设题目带具体学校，意味着你需要针对这个特定场景做定制化设计，而不是做一个通用的B2C商城。我在帮学弟做这块的时候，特意让他在需求分析里加了几个学校特有的细节：比如用户注册时必须填学号，学号要做基本的格式校验；商品分类里放进了"教材教辅""数码电器""自行车""文体用品"这些校园高频品类；交易方式上支持"校内面交"和"快递柜自提"两种——这些都是通用商城没有、但校园场景真实存在的需求。

这样做的价值在于，答辩时老师问"你这个系统和其他二手平台有什么区别"，你可以直接拿出这些针对性设计来回答，证明你不是单纯照着网上的商城项目改了个壳。这是很多学生容易忽略的加分点。顺便提醒一句，不要在校名上过度发挥，把学校的真实组织架构、真实管理流程编进系统，比如设计一堆完全不存在的院系审核节点，反而会让老师觉得你需求分析做得过度想象。拿捏好"校园氛围真实"和"系统边界克制"之间的度才是关键。

2. 技术栈选型：SpringBoot为核心的三层组合逻辑

2.1 为什么主栈是SpringBoot而不是SSH或Python

这是学弟当时问我的第一个问题。他纠结的点是，学校开设过Java课程，是不是应该用SSH（Spring + Struts + Hibernate）这种"老牌框架"显得更正统。我直接否掉了。现在的Java Web开发早就进入了SpringBoot时代，SpringBoot把配置简化到极致，内置Tomcat，一键启动，开箱即用，对毕设项目来说，省掉的XML配置时间足够你多写三个功能模块。更关键的是，SpringBoot贴近现在企业的真实开发方式，答辩时你说一句"用SpringBoot快速搭建了项目骨架"，比说"配置了三个XML文件"更能体现你对主流技术趋势的把握。

Python的Flask或Django也在我考虑范围内，但最终没选，原因有两个：第一，题目的核心就是一个用Java技术栈来做的Web项目，用Python等于重新解释一遍为什么跨出了Java体系；第二，从毕设评审的现实角度看，很多计算机学院的老师还是更认可Java生态里的Spring框架。选型这种事，有时候不是非得选"最好的"技术，而是选"最稳妥、最能把话讲圆"的技术。

2.2 前端路线：Thymeleaf模板引擎为主，同时暴露RESTful接口

我给学弟的方案是：主体用Thymeleaf模板引擎做服务端渲染，同时把所有业务接口都写成标准RESTful风格。这样设计是有讲究的。Thymeleaf是SpringBoot官方推荐的模板引擎，写起来就像HTML里嵌Java代码，对毕设来说不用再引入一个Node.js环境做前端工程化，能把工作量压缩到合理体量。但这不意味着完全放弃前后端分离的思路，Controller层所有接口统一返回设计好的JSON对象，将来随时可以接一套Vue前端，作为论文"后续拓展"和答辩口述中的进阶能力。

具体到工程结构，我帮他按下面这样拆分：

这种分层结构看起来中规中矩，但好处是答辩的时候可以讲得很清楚：每一层各司其职，Controller不写业务代码，Service不直接操作数据库。评审老师最吃这一套。

2.3 数据库与ORM选型

数据库用MySQL 8.0，这是Java生态里最标准的选择，没有争议。ORM层我选了MyBatis-Plus，而不是原生MyBatis或Spring Data JPA。MyBatis-Plus对毕设最友好的地方在于，单表CRUD方法基本都是内置的，查数据直接调用selectList、selectPage这些方法，开发速度翻倍；同时它保留了自定义SQL的能力，复杂查询在XML或注解里自己写就行。学弟当时不太理解为什么不用原生MyBatis，我告诉他一句话：原生MyBatis写一个单表查询要配一堆resultMap，而MyBatis-Plus只要继承一个BaseMapper接口。时间宝贵，不要花在重复劳动上。

3. 功能模块梳理：角色权限与核心业务闭环

3.1 两种角色的权限边界

二手交易平台的权限模型，我最终设计成了两种主要角色：普通用户和管理员。需要特别说明的是，市面上有一种做法是把"卖家"和"买家"拆成两种不同角色，但校园二手场景里同一名学生既可能卖东西也可能买东西，所以更合理的做法是同一个用户身份内同时具备买卖两种能力。这在数据库层面体现为：商品表里有user_id作为卖家ID，订单表里同时有buyer_id和seller_id两个字段。

• 普通用户（学生）：注册登录、发布商品、下架自己的商品、浏览搜索、收藏商品、对商品留言、发起订单、确认收货、评价。
• 管理员：用户管理（禁用/启用）、商品审核（通过/驳回）、分类管理、公告管理、交易数据统计。

3.2 商品发布与上下架的完整状态

商品模块是整个系统的表达力所在。发布商品时用户需要填标题、描述、价格、成色（全新/几乎全新/轻微使用痕迹等）、分类、所在校区，以及上传最多5张图片。这里有一个容易忽略的细节——商品发布后应该进入"待审核"状态，而不是直接上架。让管理员先审核，机制上解决了两个问题：一是过滤违规信息，让论文里"系统安全设计"部分有话可写；二是给后台管理模块增加了一个重要业务动作，避免后台沦为摆设。

审核通过后商品状态为"在售"，用户自己可以下架，管理员也可以强制下架。当订单产生并完成交易后，商品状态自动变成"已出售"，不再出现在搜索列表里，但可以在用户"我卖出的"页面里查看历史记录。这个状态设计看着基础，实际上是为了支撑后面订单模块里"商品不能重复被交易"这个约束，是整个系统的地基之一。

3.3 订单流程的状态机设计

订单流程算是这个系统的核心难点。我设计的状态流转是：待付款 -> 已付款待确认 -> 已发货 -> 确认收货（交易完成） -> 评价。考虑到校园二手交易多是面交，没有引入物流单号之类的复杂设计，但有一个关键点我让学弟务必加上：买家发起订单后，如果卖家在24小时内没有进行任何操作，订单自动取消。为什么要加这个？原因很实际——二手商品可能被多个人问价，商品被下单后如果卖家一直不处理，就会一直占着交易位置，其他人想买都买不了。自动取消机制保证了系统不会因为"死单"而卡住业务流程。这种设计在答辩时讲出来是实打实的加分项，因为它体现了你在思考系统的实际可用性，而不只是把表结构建出来。

订单状态我统一用int整数字段表示，0待付款、1已付款待确认、2已发货、3交易完成、4已取消、5已退款。用枚举常量类统一管理，而不是让魔法数字散落在代码里，这是代码整洁度的基本素养，也方便答辩时展开讲状态机设计。

3.4 留言与收藏：增强交互深度

除了核心交易，我建议学弟加上两个轻量级功能：商品留言和收藏功能。留言功能解决了买卖双方的沟通前置问题——买家可以在商品下留言，卖家可以在商品详情页看到留言并回复；收藏功能解决了用户"先看看再说"的场景，一键收藏之后可以随时回来继续决策。这两个功能实现起来都很简单，本质上就是两张关联表加几个CRUD接口，但在论文"系统功能详解"部分的分量却不可小视——数据库表数量从五六张涨到了十张左右，功能列表也更丰满，工作量体现得更直观。

4. 数据库设计实战：核心表结构与字段设计考量

4.1 用户表（user）

CREATE TABLE `user` ( `id` int NOT NULL AUTO_INCREMENT, `student_no` varchar(20) NOT NULL COMMENT '学号', `username` varchar(50) NOT NULL COMMENT '用户名', `password` varchar(100) NOT NULL COMMENT '密码(MD5加密存储)', `real_name` varchar(50) DEFAULT NULL COMMENT '真实姓名', `phone` varchar(20) DEFAULT NULL COMMENT '手机号', `avatar` varchar(255) DEFAULT NULL COMMENT '头像URL', `role` tinyint NOT NULL DEFAULT 1 COMMENT '角色：1普通用户 2管理员', `status` tinyint NOT NULL DEFAULT 1 COMMENT '状态：1正常 0禁用', `create_time` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_student_no` (`student_no`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

字段设计里有几个值得注意的点。学号加了唯一索引，保证用户注册的唯一性——在高校场景里学号就是天然的用户ID。密码用MD5加密存储，虽然更推荐BCrypt，但毕设级别用MD5配合盐值也可以接受，关键是能讲清楚为什么不能明文存密码。role字段区分普通用户和管理员，而不是单独建一张角色表，这是毕设常见的适度简化。status字段实现禁用用户功能，这是我非常建议加的一个字段——很多毕设项目没有它，用户管理模块就形同虚设。

4.2 商品表（goods）

CREATE TABLE `goods` ( `id` int NOT NULL AUTO_INCREMENT, `user_id` int NOT NULL COMMENT '卖家ID', `title` varchar(100) NOT NULL COMMENT '商品标题', `description` text COMMENT '商品描述', `price` decimal(10,2) NOT NULL COMMENT '价格', `category_id` int DEFAULT NULL COMMENT '分类ID', `condition_desc` varchar(50) DEFAULT NULL COMMENT '成色描述', `campus` varchar(50) DEFAULT NULL COMMENT '所在校区', `cover_image` varchar(255) DEFAULT NULL COMMENT '封面图', `images` text COMMENT '多图URL，逗号分隔', `status` tinyint NOT NULL DEFAULT 0 COMMENT '状态：0待审核 1在售 2已下架 3已出售 4锁定', `create_time` datetime DEFAULT CURRENT_TIMESTAMP, `update_time` datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_user_id` (`user_id`), KEY `idx_status` (`status`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

这一个表基本覆盖了商品业务的所有核心信息。价格用decimal(10,2)而不是float或double，这是涉及金额字段的基本原则——浮点数在二进制下无法精确表示，价格计算会出差错。图片存URL路径而不是二进制本身，图片文件上传到服务器本地后把访问地址存到数据库，这是所有生产项目的标准做法。images字段用逗号分隔的字符串存储多图URL，严格说这不够范式化，但毕设体量下，一个能直接取到的字段比一张子表的读写效率高得多，而且逻辑更直观。cover_image作为封面图单独抽出来，主要在列表页的缩略图展示时使用。

订单产生后商品状态会变成4（锁定），这是我后来补上的一个设计：下单后商品先锁定，避免其他买家继续下单，交易取消再恢复为1在售。这个状态加不加，直接影响订单模块的并发正确性，我在后面代码部分会展开讲。

4.3 订单表（orders）

CREATE TABLE `orders` ( `id` int NOT NULL AUTO_INCREMENT, `order_no` varchar(32) NOT NULL COMMENT '订单号', `goods_id` int NOT NULL COMMENT '商品ID', `buyer_id` int NOT NULL COMMENT '买家ID', `seller_id` int NOT NULL COMMENT '卖家ID', `price` decimal(10,2) NOT NULL COMMENT '成交价格', `status` tinyint NOT NULL DEFAULT 0 COMMENT '状态：0待付款 1已付款确认 2已发货 3完成 4取消 5退款', `pay_time` datetime DEFAULT NULL COMMENT '支付时间', `create_time` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_order_no` (`order_no`), KEY `idx_buyer` (`buyer_id`), KEY `idx_seller` (`seller_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

订单表单独加了order_no订单号字段。虽然自增id也能唯一标识订单，但自定义订单号在演示和日志排查时更直观，可以设计成"日期+时间戳+随机数"格式。buyer_id和seller_id同时出现在订单表里，这是二手交易与普通商城最显著的区别——普通商城只有买家没有卖家，而二手平台一笔订单要同时关联两个用户角色。

还有一个细节需要重点讲：price字段在订单表里冗余存储了一份，而不是下单时实时去商品表查。这看起来违反范式，但业务上是对的——商品价格可能在交易过程中被卖家修改，订单必须记录成交那一刻的价格，不能事后跟着商品表变化。这个点我特意让学弟在答辩时主动讲出来，属于"我有真实业务思考"的证明。

4.4 留言表、收藏表和分类表

这三张表结构都很简单，但设计时有一些小细节值得展开。

留言表（message）：id、goods_id、user_id、content、reply_content、create_time。关键点是加了reply_content字段，让卖家可以直接在留言的语境里回复，而不是另开一张回复表。毕设阶段这样的设计足够了，页面展示时留言和回复一一对应，比两张关联表简单太多。

收藏表（favorites）：id、user_id、goods_id、create_time。这里必须加唯一索引（user_id, goods_id），保证一个用户对同一商品只能收藏一次，否则手滑点两下收藏就出现重复数据，前端展示时就得去重。

分类表（category）：id、name、sort。这个表就是给商品分分类，加上sort排序字段可以让后台自定义展示顺序。不要小看分类表，商品模块的搜索筛选、前端页面的分类导航、后台的统计报表都要依赖它。正因为它被很多地方引用，字段设计宁可简单也不要乱加，命名统一、类型明确就够了。

5. 关键代码实现：从登录到交易的完整链路

5.1 登录注册与统一拦截

登录注册模块用了比较简洁的方案：注册时校验学号唯一性，密码通过MD5加密后入库；登录时根据用户名密码查库比对；会话保持使用Session，同时配合HandlerInterceptor做登录拦截，给需要权限的路由统一加控制。

public class LoginInterceptor implements HandlerInterceptor { @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) { // 判断是否是Ajax请求 String requestedWith = request.getHeader("X-Requested-With"); if ("XMLHttpRequest".equals(requestedWith)) { response.setContentType("application/json;charset=UTF-8"); response.getWriter().write("{\"code\":401,\"msg\":\"未登录\"}"); return false; } response.sendRedirect("/login"); return false; } // 把用户信息放到request里，供Controller直接使用 request.setAttribute("loginUser", user); return true; } }

这段拦截逻辑里区分了普通页面跳转和Ajax请求，这是很多毕设容易忽略的点。如果你在商品详情页点击"立即下单"是Ajax请求，结果被拦截后跳到了登录页的HTML，前端拿到的是一整个页面字符串，JSON解析直接失败。把Ajax请求单独处理成返回JSON状态码，前端检测到401就弹窗提示再跳转登录页，这个细节能省下一堆联调时间。

注册服务里的关键点是事务：先查学号是否已存在，再插入用户。虽然逻辑简单，但建议在Service层加@Transactional，保证"查重-插入"这个组合在并发下不会出问题。毕设项目并发量小，但这样写对培养工程习惯是有益的。答辩时说一句"我在注册逻辑上做了并发考量"，老师能听出你懂事务。

5.2 商品发布中的图片上传

图片上传是毕设高频功能点。实现上用SpringBoot对MultipartFile的原生支持，文件保存到项目的静态目录下，再对外暴露访问路径。核心代码大致如下：

@PostMapping("/goods/upload") @ResponseBody public Result upload(@RequestParam("file") MultipartFile file) { if (file.isEmpty()) { return Result.error("文件不能为空"); } String originalFilename = file.getOriginalFilename(); String ext = originalFilename.substring(originalFilename.lastIndexOf(".")); // 生成新文件名，防止重名覆盖，也防止中文文件名乱码 String fileName = UUID.randomUUID().toString().replace("-", "") + ext; // 按日期分子目录存储 String dateDir = new SimpleDateFormat("yyyyMMdd").format(new Date()); String dirPath = uploadDir + "/" + dateDir; File dir = new File(dirPath); if (!dir.exists()) { dir.mkdirs(); } file.transferTo(new File(dirPath + "/" + fileName)); // 返回可访问的URL路径 return Result.success("/upload/" + dateDir + "/" + fileName); }

这里有几个非常关键的工程细节。第一，文件名绝对不能直接用用户上传的原始文件名，两个用户上传同名文件会互相覆盖，中文文件名还可能引发编码问题。用UUID重新生成文件名，彻底规避了这两类问题。第二，按日期分目录存储，避免单个目录下文件过多，后续找文件、迁移文件都方便。第三，必须限制文件大小，SpringBoot配置里设置spring.servlet.multipart.max-file-size=5MB和max-request-size=20MB，防止超大文件把服务器搞崩。上传完的图片URL按逗号拼接后存进商品表的images字段，前端用img标签逐个展示。

顺带提醒一个坑：Spring Boot项目打包成jar之后，默认的static目录在jar包内部，运行期间往里面写文件可能会遇到只读文件系统的问题。毕设阶段一般用IDE直接运行或者打成war部署到Tomcat，这个问题不突出，但如果你打成jar部署到服务器，就要把上传目录配置成服务器上的一个绝对路径，千万别把文件写到jar包里面去。这个坑我见过不止一个学生踩过。

5.3 商品搜索的模糊查询与条件筛选

二手交易系统最常用的功能就是搜索商品。用MyBatis-Plus的QueryWrapper实现动态SQL拼接，核心思路是根据前台传过来的条件组合查询：

public PageResult<Goods> searchGoods(String keyword, Integer categoryId, BigDecimal minPrice, BigDecimal maxPrice, int page, int size) { Page<Goods> pageParam = new Page<>(page, size); QueryWrapper<Goods> wrapper = new QueryWrapper<>(); wrapper.eq("status", 1); // 只查在售商品 if (StringUtils.hasText(keyword)) { // 标题或者描述模糊匹配，用and括号包住两个or条件 wrapper.and(w -> w.like("title", keyword).or().like("description", keyword)); } if (categoryId != null) { wrapper.eq("category_id", categoryId); } if (minPrice != null) { wrapper.ge("price", minPrice); } if (maxPrice != null) { wrapper.le("price", maxPrice); } wrapper.orderByDesc("create_time"); Page<Goods> result = goodsMapper.selectPage(pageParam, wrapper); return new PageResult<>(result.getRecords(), result.getTotal()); }

这套代码有几个值得在答辩时讲清楚的设计。默认状态只搜在售商品status=1，被下架、已出售、待审核的商品绝不能出现在结果里。keyword的匹配用了and(w -> w.like().or().like())的分组写法，确保两个like条件被括号包住，不能脱离keyword条件形成or的优先级问题。排序用发布时间倒序，在校园二手这种商品数量不大、时效性敏感的场景里，这个策略简单有效。价格上下限，注意比较大小的小坑：ge是大于等于，le是小于等于，写反了搜索就全反了。

5.4 交易流程的状态机与事务控制

交易流程是整个系统的核心。我帮学弟写了下单的核心Service逻辑，重点是：下单时再次校验商品处于在售状态，然后创建订单，同时把商品状态改成"锁定"，这两个动作必须放在同一个事务里。

@Transactional public Result createOrder(Long goodsId, Long buyerId) { Goods goods = goodsMapper.selectById(goodsId); if (goods == null || goods.getStatus() != 1) { throw new BusinessException("商品不存在或已下架"); } // 防卖自买：买家不能购买自己发布的商品 if (goods.getUserId().equals(buyerId)) { throw new BusinessException("不能购买自己发布的商品"); } // 创建订单 Orders order = new Orders(); order.setOrderNo(generateOrderNo()); order.setGoodsId(goodsId); order.setBuyerId(buyerId); order.setSellerId(goods.getUserId()); order.setPrice(goods.getPrice()); order.setStatus(0); ordersMapper.insert(order); // 锁定商品 goods.setStatus(4); goodsMapper.updateById(goods); return Result.success(order); }

这段逻辑里藏了几个重要检查。先查商品状态是不是在售，防止了一物两卖的关键问题——两个买家同时看到商品在售，同时发起下单，如果没有一个状态约束，就可能出现一个商品对应多条有效订单的情况。这里利用的是"先查状态再更新"的乐观思路，配合事务能挡住绝大多数并发场景，毕设层级完全够用。

防卖自买这个检查特实用。很多学生根本想不到"自己买自己的商品"这条路径存在，但如果你的"立即购买"按钮没有前置判断，点了就会产生一条脏订单。答辩前用测试数据跑一遍，最容易露馅的就是这类边界条件。

下单和锁定商品放在同一个事务里，任何一个失败都会回滚，这就是事务一致性的实际体现。答辩老师如果问"为什么要放同一个事务"，标准答案就是：业务操作的最小原子单位必须包含订单创建和商品状态变更，否则会出现"订单失败但商品被锁定"或"订单成功但商品还能被搜到"的不一致状态。订单状态变更我在Service层单独封装了一个方法，每次变更都校验"当前状态是否等于期望前置状态"，比如确认收货必须从status=2（已发货）变更，不允许从status=1（已付款）直接跳到status=3（完成），这种状态机的合法跳转校验，是业务严谨性的直接体现。

6. 毕设避坑实录与答辩要点

6.1 最常被答辩老师追问的五个问题

我根据帮学弟模拟答辩时被问到的问题，整理了几个高频追问，直接列出来供参考。

第一，"这个系统最大的技术难点是什么？"很多学生的第一反应是"没什么难点"，这等于把送分题扔了。标准答法应该是：说清楚图片上传处理策略（UUID重命名、按日期分目录、大小限制）、订单状态机的合法跳转约束、以及数据库设计中价格字段冗余带来的一致性考虑。哪怕你的实现并不复杂，只要你能说清"遇到了什么问题、为什么这样解决"，老师就认可你有工程思维。

第二，"密码为什么用MD5？"很可能有人反问"现在不是推荐BCrypt吗"。你要答的核心是："我了解BCrypt更安全，毕设项目里选MD5加盐是为了在安全和性能之间做简单平衡，如果上线一定会换成BCrypt。"这样既展示了知识面，又说明选型有依据。

第三，"这张表和那张表为什么这么设计？"比如为什么订单表冗余了价格字段，为什么留言回复不单独建表。答案还是那句话：为了查询效率、为了保证业务快照，并且能讲清楚取舍。数据库设计的答辩核心不是范式多标准，而是你知不知道自己在牺牲什么、换取了什么。

第四，"如果用户量变大了，这个系统哪里会成为瓶颈？"这道题考察全局意识。标准回答是：单机本地图片存储会成瓶颈，可以换对象存储；MySQL单库单表数据量大后查询会变慢，可以按用户维度分表或者引入缓存；Session存储在单机里会失效，可以用Redis做集中式会话管理。不需要真的实现这些优化，但必须知道系统在哪里会扛不住、用什么技术解决，这叫知道边界。

第五，"测试数据是怎么来的？"千万别回答"随便填的"。我让学弟准备了完整的演示数据，包括十几个用户、二十多个商品、处于不同状态的订单。让数据库有真实的上下文，功能测试展示才有说服力。

6.2 演示时的数据准备与操作路径

演示环节建议准备两条固定路径。路径A是用户完整流程：注册登录 -> 浏览首页 -> 搜索关键词 -> 进入商品详情 -> 留言 -> 收藏 -> 下单 -> 卖家端处理 -> 确认收货 -> 评价。路径B是管理员流程：登录后台 -> 商品审核 -> 用户禁用/启用 -> 查看统计数据。这两条路径我让学弟用固定账号和固定数据排练了起码五遍，确保每个步骤都点得顺、不卡壳、不出现404。演示时最怕临时找数据，比如现场输入一个搜索词，结果搜不到任何商品，全程尴尬。所以演示数据必须预先插入，搜索词必须能搜出结果，所有页面跳转都要提前走通过。

演示环境建议直接用本机。SpringBoot项目本地启动，浏览器访问localhost:8080，尽量不要依赖远程服务器。答辩现场网络状况千奇百怪，密码连不上、服务器过期、域名解析失败都遇到过，本地跑是把现场风险降到最低的做法。

6.3 后续可以扩展的方向

关于扩展，我留了几个可以在论文"展望"部分或答辩口头加分时用的方向。一是引入Redis做热门商品缓存与Session共享，从单机走向分布式，想清楚"什么数据适合缓存、缓存淘汰策略怎么选"。二是加消息通知能力，比如买家下单后通过站内信或邮件通知卖家，用Spring的事件机制实现解耦，论文里撑起一节很自然。三是做个简单的推荐逻辑，比如根据用户收藏记录和商品分类推荐同类型商品，在论文里可以写成"基于兴趣的简单推荐策略"专题。四是容器化部署，写一个Dockerfile，阐述镜像构建与部署流程。这些方向不需要全部实现，能说出设计思路和落点，已经足够撑场面。

数据库字符集务必要统一用utf8mb4，排序规则用utf8mb4_general_ci，这一点必须放在最后单独说。如果按默认的latin1建表，前端输入生僻字或表情符号，保存时直接报"Incorrect string value"，排查起来极其痛苦。建表前把字符集规范化，后面省下的是成片的调试时间。这是我带过好几个学弟之后总结的血泪教训。

整个项目做下来，我最深的体会是：毕设的价值不在于系统有多炫酷，而在于你能否把每一个设计决定讲出一个"为什么"。二手交易平台恰好是一个能逼着你回答大量"为什么"的题目——为什么不直接改商品价格、为什么不把图片存数据库、为什么下单要锁商品状态、为什么搜索默认只能出在售商品，每一个"为什么"背后都是一个真实的工程决策。把这些想清楚，论文有内容，答辩有底气，将来面试也有故事讲。

如果正在读这篇文章的你也准备做类似的系统，我的建议很直接：不要只盯着代码跟着视频敲一遍就完事，先花两天时间把表结构设计好、把状态流转图画出来（哪怕手画在纸上），把每一步技术选型的理由记录下来，然后再开始写代码。顺序反了，你会发现自己在"改表、改代码、改需求"的循环里出不来。毕设是一次难得的完整项目训练，把"为什么"的功课做足，收获会远比那一纸学分多得多。