企业官网建设流程全解析

1. 校园二手交易小程序，为什么是毕设的“常青树”选题

前几天一个学弟拿着选题列表来问我，里面赫然躺着“校园二手交易平台”。这题目听着老，但每年都能做出新花样——尤其最近这套SpringBoot后端加微信小程序前端的版本，项目方连源码和演示录像都公开了出来，很多人直接拿来当毕设参考。我顺着这份材料把整个项目的设计思路、技术选型、踩坑点重新过了一遍，觉得正好能覆盖大多数Java方向毕设的硬核知识点，值得专门写一篇拆解。

先说结论：如果让我从几十个常见选题里选一个性价比最高的，校园二手交易平台能排进前三。它的用户群体明确，就是本校学生；业务场景真实，毕业季的教材、电动车、小家电流转量最大；技术链路完整，一个典型的前后端分离系统该有的东西它都有。更关键的是，老师听这个题目不费劲，你不用花十分钟解释业务背景，答辩时间全留给技术提问环节。再加上现在移动端基本都用微信小程序承载，比传统Web端多了一层“平台适配”的讨论空间，非常容易体现工作量。

1.1 这种选题为什么能年年翻新

“旧题目”不意味着“旧实现”。同样是二手交易，早几年的方案是纯Web端，JSP写页面、用户用账号密码登录；后面流行Vue加SpringBoot的单页应用；这几年标配变成了微信小程序。前端载体一变，登录方式、接口风格、发布审核规则全都要跟着变，所以哪怕业务模型没变，只要按照新技术版本从头做一遍，依然有足够的原创空间。

从评审角度看，二手平台天然包含多种角色和状态流转，可以综合考察学生对数据建模、接口设计、权限控制、并发处理的能力。没有复杂的算法，没有冷门中间件，对普通本科生来说正好是“跳一跳够得着”的难度。相比那些纯管理系统，二手平台多了一条交易闭环，天然比增删改查的题目高一个档次。

1.2 三张角色表与一条状态主线

系统侧的主线其实就一条：卖家发布商品，买家浏览查找，双方通过平台撮合完成交易。围绕这条主线，数据模型上至少需要三类角色：普通用户、管理员，以及区分买卖身份的场景角色。角色不必设计得太复杂，复杂的是商品和订单的状态。

二手交易和标准电商有个本质区别：普通商品库存是无限多的，而二手商品库存恒等于1，售出即下架。我在指导毕设时，经常看到同学把二手平台按电商来建模，搞一套购物车加库存表，最后把自己绕晕。合理的做法是简化：商品状态只保留“在售”“下架”“已售出”；订单如果一定要做，状态可以是“待买家确认”“待卖家确认”“交易完成”“已取消”。不用真的接入支付，模拟一笔支付就行，把重点放在状态流转的合法性校验上。

2. SpringBoot后端的核心设计：表结构、接口与鉴权

后端用什么、为什么用，直接体现设计水平。这套项目主框架是SpringBoot，持久层用MyBatis-Plus，数据库MySQL，登录缓存用Redis，令牌用JWT。这套组合几乎是目前Java毕设的标准答案，理由很简单：SpringBoot能快速搭好Web应用骨架，MyBatis-Plus把CRUD和分页从几十行减到几行，Redis加JWT解决小程序无状态登录，每一样都有现成文档和大量排错案例。

2.1 六张核心表与字段设计思路

数据库设计决定了项目能承载多少业务。我看到不少同学一上来就建了十几张表，半数是冗余的，反而把自己写崩。实际上，一套合格的二手交易平台最核心的六张表就够了。

字段设计上要特别注意：openid是微信侧的用户唯一标识，绝不能直接暴露给前端，登录后统一下发token；商品表加status和view_count，前者配合状态机，后者为热门排序留余地；订单号用时间戳加随机数生成，不要用自增ID直接当业务单号，否则答辩时容易被问“订单号有什么业务含义”。

2.2 接口风格：统一返回与状态机驱动

后端接口遵循RESTful风格，所有返回都包一层统一的Result结构，包含code、message、data三个字段。这样小程序端拦截器可以统一判断code，不用每个页面单独处理异常。分页查询统一传page和size，返回对象里带上total，方便前端做加载更多。

接口不要暴露“任意改状态”的能力。商品上下架、标记售出这类操作，前端传的是动作而不是目标状态。后端拿到动作之后，先校验当前状态能不能走这个动作，再执行更新。举个例子：一件“已售出”的商品不能再次上架，“交易中”的商品不能重复被下单。把状态机逻辑收敛到后端，前端就只是一堆按钮。

// 商品状态流转：用动作代替状态赋值 public Boolean changeStatus(Long productId, Integer action) { // action: 1上架 2下架 3标记售出 Product product = productMapper.selectById(productId); if (product == null) throw new BizException("商品不存在"); if (!StatusMachine.canTransform(product.getStatus(), action)) { throw new BizException("当前状态不允许该操作"); } product.setStatus(StatusMachine.targetStatus(action)); return productMapper.updateById(product) > 0; }

核心接口也就十个左右：小程序登录、商品分页查询、商品详情、发布商品、修改商品、收藏留言、创建订单、订单列表、上传文件、后台管理。接口不在多，而在每个接口是不是真的有人用。

2.3 JWT登录鉴权与拦截器

小程序的登录链路和后端鉴权是整个项目最容易被追问的部分。时序是：前端wx.login拿到临时code，传给后端；后端拿code去微信接口换openid和session_key；查用户表，不存在就注册；然后生成JWT返回给前端。前端把JWT存进storage，后续每个请求都在header里带Authorization。

为什么不用Session而用JWT？小程序的Cookie机制和浏览器不一样，服务端Session需要额外维护存储和跨域配置；JWT是无状态的，后端只靠密钥验签就能确认用户身份。缺点是token一旦签发不能主动失效，所以要在JWT里设置过期时间，拦截器解析失败或过期时统一返回401，小程序端收到后跳转登录页。拦截器实现也很简单，继承HandlerInterceptor，在preHandle里解析token，把userId放入ThreadLocal上下文，方便后续业务直接取。

public class TokenInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) { String token = request.getHeader("Authorization"); Long userId = JwtUtil.parseToken(token); if (userId == null) { throw new BizException(401, "登录已过期"); } UserContext.set(userId); return true; } }

放行规则上，登录接口、商品列表、商品详情这些公开接口不需要token，但发布商品、创建订单、个人中心必须登录。静态资源上传目录也要放行，否则图片加载会被拦截器拦成401。

3. 小程序端的实现细节：从登录到下单的完整链路

小程序端不只是页面，它承担了用户从进入系统到完成交易的全部交互。我建议学生拿到源码后不要急着看页面样式，先把登录、发布、下单这三条链路走明白，因为这三条链路正好对应后端的三个核心能力：身份识别、文件存储、业务状态流转。

3.1 登录链路与用户信息授权的新规

小程序端的登录函数一般封装成一个ensureLogin方法。先检查本地storage有没有token，有就用；没有就调用wx.login，把code发给后端，拿到token后再放行后续请求。所有请求都走统一封装的request方法，在header里带上Authorization。

这里有个2022年之后的重要变化：微信调整了头像昵称的获取方式，不再支持wx.getUserInfo直接弹窗授权，改成button的open-type="chooseAvatar"配合昵称输入框。如果拿到的项目是比较新的版本，应该能看到这种实现；如果还是老代码用授权弹窗，上传体验版之后会被平台拒绝。手机号也有类似限制，getPhoneNumber接口需要企业主体的小程序才能正常用，毕设阶段用普通输入框让用户填手机号是常见做法，答辩时一句话说明原因即可，老师都能理解。

3.2 商品发布：图片处理、表单校验与上传

商品发布页看起来简单，实际坑最多。前端流程一般是：选择分类，填写标题、描述、价格，然后选择图片。图片这块要特别注意体积，手机拍一张照片动辄两三兆，不压缩直接上传会非常慢，而且容易超时。

推荐做法是三步走：wx.chooseMedia选择图片，wx.compressImage压缩到单张500KB以内，再用wx.uploadFile上传。后端用MultipartFile接收，做好类型和大小校验，用UUID生成新文件名后保存到磁盘。数据库里不存完整访问地址，只存相对路径，比如/upload/xxx.jpg。访问图片时前端统一拼接baseUrl。

uploadImages(filePaths) { const tasks = filePaths.map((path) => { return new Promise((resolve) => { wx.compressImage({ src: path, quality: 60, complete: (res) => { wx.uploadFile({ url: `${baseUrl}/api/file/upload`, filePath: res.tempFilePath, name: 'file', success: (res) => resolve(JSON.parse(res.data).data) }); } }); }); }); return Promise.all(tasks); }

这里有一个特别多同学踩的坑：数据库里存了带IP的完整地址，比如http://192.168.1.100:8080/upload/xxx.jpg。在自己电脑上跑没问题，一换网络环境、一换演示电脑，IP变了，所有商品图片全部裂开。正确做法就是只存相对路径，前端维护一个baseUrl，请求时动态拼接。真机调试的时候，后端地址不能用localhost，要用局域网IP，同时后端要开启跨域配置。

3.3 下单闭环：两种策略怎么选

下单是业务核心，但二手平台的下单有两种完全不同的策略，选错会影响整个项目结构。

毕设我优先推荐方案A，因为二手商品本身库存就是1，不需要购物车批量结算，而且线下交易是校园二手市场的常态。如果指导老师点名要购物车，再补方案B。方案B多加购物车表和支付流水表，同时要处理订单超时未支付、发货物流等一堆问题，工作量翻倍。

无论选哪种方案，都必须处理同一个并发问题：只有状态为“在售”的商品才能创建订单，创建成功后要立即把商品状态从“在售”改成“交易中”或“已售出”。否则就会出现两个用户同时下单同一件商品的恶性bug。

4. 实战中最容易翻车的几个环节

这部分是血泪经验。很多同学拿到项目当天就跑通了，到答辩前一周开始接二连三出幺蛾子，问题几乎都集中在并发、文件、平台规则和数据库环境四块。

4.1 并发下单与超卖问题

场景复现一下：两个用户同时盯上一台九成新的显示器，同时点“我想要”。如果代码是先查商品状态再创建订单，两个请求都能查到“在售”，于是产生两个订单，商品被卖了两次。这不是小概率问题，是并发编程的基础考点，也是答辩时老师最可能追问的地方。

解决办法是把状态更新做成条件更新，SQL写出来一行就够：

UPDATE product SET status = 2 WHERE id = #{productId} AND status = 1;

如果影响行数等于1，说明抢到了，可以创建订单；影响行数为0，说明商品已经被别人下单，直接提示“手慢了”。这个思路本质是乐观锁，虽然没有version字段，但效果完全等价。

演示的时候可以开两个微信开发者工具模拟器同时点击，展示只有一个人能成功，这是答辩加分点。不用悲观锁和Redis分布式锁的理由也要准备好：数据库本身就能用一行条件更新解决问题，加锁徒增复杂度，而且如果被问到锁超时、锁释放问题，容易答崩。

4.2 图片上传与本地存储的路径坑

本地文件存储没有对象存储那么复杂，但坑全在路径上。后端用application.yml配置一个upload.dir目录，保存时按月份分目录，用UUID重命名文件，避免重名和中文文件名问题。需要检查文件扩展名，只允许jpg、png、jpeg、webp，否则容易被传恶意文件。

前端访问图片的地方要统一封装方法，不要一个页面一个写法。后端还需要配置静态资源映射，把/upload/映射到物理磁盘目录。如果项目里加了拦截器或者安全配置，记得放行/upload/，不然图片请求会被拦成401或404。

真机调试时还有一个常见问题：手机和电脑不在同一个局域网，或者电脑防火墙没关，导致手机访问不到电脑上的后端接口。稳妥做法是把后端地址配置抽到一个单独的config.js文件里，调试时只改一处。

4.3 小程序类目、隐私接口与审核红线

二手交易在微信平台属于电商类目，个人主体很难开通对应的类目和支付能力，所以这套项目里的支付几乎都是模拟支付。答辩时要说清楚“出于主体资质限制，支付流程以模拟方式实现”，这话老师一听就懂，不算短板。

更关键的是隐私接口的配置。只要用到选择图片、选择头像、获取位置这类能力，小程序后台都要配置隐私保护指引。很多毕设直接在开发者工具里预览时功能一切正常，一发体验版就白屏，多半是隐私协议没配置。开发者工具里可以勾选“模拟隐私接口”，但真机预览时会严格校验，这个细节能写进问题排查里，体现出你确实做过真机测试。

4.4 数据库与环境的隐形雷

MySQL 8的时区问题几乎是必踩项。连接字符串上要带serverTimezone=Asia/Shanghai，字符集要带useUnicode=true&characterEncoding=utf8。导入SQL文件时如果中文变成乱码，多半是SQL文件本身的编码不是utf8。我见过不少同学卡在这里，最后发现是下载的SQL文件用了GBK编码。

Maven依赖下载慢也是常见问题，解决方案就是换国内镜像仓库。微信开发者工具的“不校验合法域名”开关，开发阶段开着没问题，但提交体验版之前必须关掉，然后在小程序后台配置request合法域名，而且域名必须是HTTPS。如果后端还没上线，可以先用内网穿透临时解决，但答辩演示还是建议本地运行，最稳定。

5. 从拿到源码到顺利答辩：改造与演示的完整建议

这是最后冲刺阶段。项目方给的资料里有两样东西最值钱：一份能跑的源码、一份演示录像。但直接用会有两个风险：一是不知道项目怎么启动，二是答辩时空有一份录像却讲不出设计。正确用法是把录像当功能清单，把源码当学习材料，而不是把录像背下来。

5.1 本地跑通项目的环境与启动顺序

提醒一句，不要一上来就双击运行，先确认环境。JDK选8或17都可以，Maven 3.6以上，MySQL 5.7或8，Redis必须有，因为登录和验证码都依赖它。微信开发者工具用最新稳定版就行。

启动顺序按下面这个流程走，基本不会乱：

1. 先建数据库，导入项目里的sql文件，检查有没有报错；
2. 修改后端application.yml里的数据库账号密码、Redis地址、上传目录；
3. 先启动Redis，再启动后端，看控制台日志有没有异常；
4. 用浏览器访问后端接口地址，能出JSON说明后端起来了；
5. 微信开发者工具导入小程序目录，修改config.js里的baseUrl；
6. 开发阶段勾选“不校验合法域名”，先在模拟器里跑通登录和商品列表。

常见报错对照如下：数据库连不上就查账号密码和端口；Redis报错就查有没有启动；Maven依赖报红就强制刷新并检查镜像；小程序请求失败就查baseUrl和跨域配置。每一步都有明确排查路径，别瞎猜。

5.2 演示录像怎么用才能变成自己的表达

演示录像存在的意义，不是让你照着背，而是告诉你“项目方认为哪些功能是核心亮点”。我建议这样用：第一遍完整看，记录功能出现的顺序；第二遍边看边操作，把系统自己走一遍，遇到不一致的地方停下来研究；然后画一张功能清单，把录像里的顺序改成“业务闭环”顺序。

答辩时，从用户登录开始，到发布商品、浏览搜索、下单、状态变化、管理员审核，串成一条故事线。每讲完一个功能，主动接一句“这里我做了……，是为了解决……”，把话题引到技术细节上。老师真正想听的，不是操作演示，而是背后的设计判断。

5.3 二次开发改哪里性价比最高

改UI是性价比最低的改动，换个颜色并不会加分。真正能让老师眼前一亮的是功能层面的扩展。按性价比排序，我建议从以下四项里挑一个做：

每项改动都不能只是“加了页面”，要能回答“为什么这么做”和“遇到什么问题”。比如WebSocket连接在弱网下怎么处理、推荐规则怎么防止刷量，这类问题虽然简单，但准备好就能拉开差距。

6. 扩展思路：从毕设到可落地产品的差距

如果只是应付答辩，前面五章够用了。但如果想把这份毕设填进简历，或者拿它去参加课程设计评优，那还得再往前走一步：想清楚它离一个可用的产品还差什么。

6.1 信用与安全模块：二手平台真正的护城河

二手交易最大的痛点不是功能，是信任。你可以顺着这个点加一批模块，每一块都是独立亮点。学生认证可以考虑用学号加学校邮箱验证，认证后的用户展示专属标识；信用分机制让交易成功加分、多次违约扣分、低于阈值禁止发布；发布内容加违禁词过滤，后台维护举报列表；甚至可以模拟交易担保，买家付款到平台，确认收货后再打给卖家。

这些功能在后端实现上都不难，本质是常规CRUD加定时任务，但它们能让评委觉得这个学生真的研究过业务，而不是只会抄代码。更实际的意义是，简历上写“设计了基于信用分的风控机制”比写“实现了一个二手交易系统”有说服力得多。

6.2 性能与运维细节：缓存、索引、日志与监控

想让项目经得起追问，还要关注非功能质量。热点商品的详情和首页列表可以考虑用Redis缓存，key设计要考虑失效时间和数据一致性，比如商品下架时主动删除缓存；商品表加(status, create_time)复合索引，订单表加buyer_id索引，数据量上去后查询差距非常明显；全局异常处理器用@RestControllerAdvice统一错误格式，避免每个Controller里重复写try-catch；日志用logback按天滚动，方便线上定位问题。

上线部署时记住一条硬规矩：小程序request合法域名必须是HTTPS，后端接口用Nginx转发并配置SSL证书，图片和接口都走同一个域名，不然小程序真机上会有一堆白屏问题。用Actuator暴露几个关键指标，再写一页部署文档，这部分可以作为论文里的“系统测试与部署”章节素材。

说实话，校园二手交易平台这个题我前前后后带过不少学生，最让人印象深刻的不是谁的技术多强，而是谁更愿意把项目当成一个真问题去拆解。同样的源码，有人交上去的是一堆代码，有人交上去的是对整个系统的理解。建议各位拿到这份源码和演示录像之后，先别急着改页面、换颜色，按上面说的顺序把登录、发布、下单这三条链路跑通，再挑一个扩展点做深。等你能在五分钟内把“为什么这样设计”讲清楚，答辩和简历都不会差。