企业官网建设流程全解析

简介：面向毕业设计与课程设计的校园服务平台完整项目，基于微信小程序开发前端、Java构建后端，并使用MySQL存储数据。系统围绕校园二手交易场景设计了管理员、卖家、用户三类角色：管理员可管理用户、卖家、商品公告与订单；卖家能发布和维护二手商品、处理订单发货；用户可注册登录、浏览公告、搜索购买商品，覆盖完整业务闭环。压缩包共1112个文件、约27.76MB，包含Java后端源码、Vue管理端页面、小程序wxml/wxss/js脚本、png/svg图标资源、SQL数据库脚本以及mp4演示视频等，另有安装、启动、构建三个bat脚本分别负责依赖安装、启动服务与项目构建，辅助快速部署。演示视频直观展示从注册到下单发货的完整流程，说明文档和数据库设计帮助理清项目结构与表关系，适合作为毕业设计、课程设计参考或二次开发蓝本。已有140人学习使用。

1. 微信小程序+Java后端的校园服务平台：这套毕设源码能直接改来用吗？

校园服务平台这类毕设，最容易踩两个坑：代码能跑但演示不了，或者演示能跑但改不动。这份源码是微信小程序做前端、Java做后端、MySQL存数据，管理员还能通过Vue页面进后台管商品和订单，解决了毕业设计最头疼的“从零搭一套能演示的系统”的问题——注册、登录、商品发布、下单、发货、公告管理这些链路都是通的，数据库脚本也给了，到手不是重写，而是换皮肤、加字段、改逻辑。适合急着交毕设的在校生、想拿完整案例练手的Java初学者，以及想快速出校园二手平台原型的开发者。下面从功能边界、数据库设计、接口联调、部署踩坑和二次开发五个角度拆开讲。

2. 三种角色与六大功能模块：管理员、卖家、用户的权限边界怎么拆？

拿到源码先别急着跑，打开数据库设计文档把角色理清楚。这个系统把使用者分成三类：管理员、卖家、普通用户。表面看只是登录入口不同，实际是三种隔离的数据权限：普通用户只能浏览公告和购买二手商品，卖家在用户能力基础上多了商品增删改查和发货权，管理员拥有全部后台管理权限。如果直接把用户表和卖家表合成一张表，后面订单归属、发货状态都会乱，所以先看清角色边界再动代码。

2.1 为什么校园二手平台要拆三种角色

二手交易的特殊性在于“买东西的人和卖东西的人权限不同”。用户下单要的是浏览商品、加入订单、查看物流；卖家要的是上架、改价、下架、发货；平台方要的是封禁违规账号、删除问题商品、处理订单纠纷。如果所有功能堆在一个角色里，小程序页面会多出一堆按钮，管理员后台也会暴露不该暴露的操作。这个项目用的是简化版RBAC思路：角色决定菜单，菜单决定接口，接口决定数据范围。对毕设答辩来说，这种设计也容易讲清楚——“我的系统有三类用户，各自有不同的业务流程”，比单角色堆功能好讲得多。

另外要注意，用户注册时是直接选角色，还是由管理员审核身份，源码里一般给的是注册时选用户或卖家。这类毕设常见做法是注册表里有role字段，填1是用户、2是卖家，管理员在后台可以改。你在答辩时要能说清楚这个字段的含义，下面第三章会再提。

2.2 管理员后台九大模块分别管什么

管理员功能在Vue管理端里实现，压缩包解压后你能看到main.css.bak、update-password.vue.bak这类备份文件，说明后台管理页是Vue结构，各种模块页面都在。九个模块分别是：个人中心（改管理员自己的密码和头像）、用户管理（查看和禁用普通用户）、校园公告管理（发布、下线公告）、卖家管理（审核卖家和封禁卖家）、二手商品管理（强制下架违规商品）、订单信息管理（查看全站订单）、订单发货管理（处理卖家的发货申请或代发货）、管理员管理（添加其他管理员）、系统管理（菜单、角色、关于我们这类配置）。

从源码阅读角度，我的建议是按“订单信息管理→用户管理→二手商品管理”三个先看。订单模块能串起全站数据，用户管理能看到权限字段怎么用，商品管理能看到上下架状态枚举。其余模块逻辑类似，看一遍就能举一反三。

2.3 卖家端与用户端：页面菜单只差三步

卖家登录小程序后看到的四个模块是首页、校园公告、二手商品、我的；我的里包含二手商品管理、订单信息、订单发货。普通用户“我的”里只有二手商品（已买）、订单信息、订单发货（查看物流）。也就是说，卖家比用户多的核心能力，是商品的新增、编辑、删除，以及订单的“发货”操作。

这两个动作在小程序前端都做了权限判断：不是卖家角色，页面不会渲染“发布商品”按钮，后端接口也会做二次校验。前端隐藏只是体验问题，后端拦截才是安全边界。这个“双端校验”思路答辩时一定要提，老师很吃这一套。

2.4 一条订单从发布到完成的数据流

拿一个完整场景串一遍：卖家在小程序发布一件“九成新高数教材”，数据写入商品表并带上seller_id，状态默认“在售”；用户搜索看到商品后点击购买，后端先生成订单记录，状态“待发货”，同时把商品状态改成“已下架”，避免一物多卖；卖家在“订单发货”里填快递单号，状态变“已发货”；用户确认收货后，状态变“已完成”。

整个过程涉及商品表、订单表、发货表三张表的状态联动。你改代码时要特别注意：商品状态和订单状态是分开的字段，不能混用。商品状态是“在售/下架”，订单状态是“待发货/已发货/已完成”，很多毕设翻车就翻在把这两个状态当成同一个字段去写。

提示：看源码时先找到订单状态枚举值定义在Java后端的哪个类里，通常是个常量类或者字典表。抄下来贴在手边，调试接口会省很多时间。

3. MySQL数据库与Java后端：从建表语句到接口路径的对照阅读

数据库是整个项目的地基。我拿到这套源码的习惯是：先不跑代码，直接把库导进MySQL，用Navicat把表结构看一遍。这个项目涉及的核心表有用户表、卖家表、商品表、订单表、公告表，以及后台的轮播图、管理员等配置表。下面先把导入步骤和核心表结构讲清楚，再带你认Java后端的接口分层。

3.1 数据库导入的正确姿势：字符集、时区、两处编码坑

压缩包里的SQL文件是带建库和insert数据的完整脚本。常见做法是先用Navicat新建一个utf8mb4编码的数据库，再右键运行SQL文件。命令行方式更可控：

mysql -u root -p CREATE DATABASE IF NOT EXISTS campus DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE campus; SOURCE /path/to/campus.sql;

这条命令里的COLLATE utf8mb4_general_ci是关键参数。MySQL 8.0导出的脚本经常带utf8mb4_0900_ai_ci，如果你本机是MySQL 5.7，导入会直接报“Unknown collation”。解决方法是把脚本里的0900_ai_ci替换成general_ci，一条命令搞定：

sed -i 's/utf8mb4_0900_ai_ci/utf8mb4_general_ci/g' campus.sql

数据库导好之后，还要检查Java后端连库的配置。这套源码从文件结构看是Eclipse导出的Web工程（.classpath、org.eclipse.wst.common.component这些就是Eclipse的工程描述文件），配置一般写在jdbc.properties；如果是SpringBoot结构，就是application.yml。核心参数是连接串，我一般写成这样：

jdbc.url=jdbc:mysql://localhost:3306/campus?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai&allowPublicKeyRetrieval=true jdbc.username=root jdbc.password=123456

参数说明：useSSL=false是因为本地开发没有SSL证书，不关会警告甚至连接失败；serverTimezone=Asia/Shanghai是给MySQL 8.x的驱动用的，不写会报时区错误；allowPublicKeyRetrieval=true解决MySQL 8的caching_sha2_password认证插件连接问题，这是老项目接MySQL 8最常见的三个报错来源。

3.2 核心表结构：用户、卖家、商品、订单、公告

用户表和卖家表是这个系统最容易混淆的地方。先看用户表：

CREATE TABLE user ( id INT PRIMARY KEY AUTO_INCREMENT COMMENT '主键', username VARCHAR(50) NOT NULL UNIQUE COMMENT '登录名', password VARCHAR(100) NOT NULL COMMENT '密码，建议MD5加密存储', nickname VARCHAR(50) COMMENT '昵称', phone VARCHAR(20) COMMENT '手机号', avatar VARCHAR(255) COMMENT '头像URL', role TINYINT DEFAULT 1 COMMENT '1普通用户 2卖家', create_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT '注册时间' );

role字段在这里只区分1和2。但如果项目把卖家做成独立表，用户表里就不该有role，而是通过外键关联或卖家表里再存一份user_id。你拿到的源码到底是哪种，打开数据库看有没有sellers表就知道。独立卖家表的结构通常是：

CREATE TABLE sellers ( id INT PRIMARY KEY AUTO_INCREMENT, user_id INT NOT NULL COMMENT '关联user表', shop_name VARCHAR(100) COMMENT '店铺名称', status TINYINT DEFAULT 0 COMMENT '0待审核 1正常 2封禁', audit_time DATETIME COMMENT '审核时间' );

这种设计的价值在于：卖家有独立的店铺信息、审核状态，和普通用户不冲突。商品表相对直观，重点看几个关键字段：

CREATE TABLE goods ( id INT PRIMARY KEY AUTO_INCREMENT, seller_id INT NOT NULL COMMENT '发布者，关联sellers表', title VARCHAR(100) NOT NULL COMMENT '商品标题', price DECIMAL(10,2) NOT NULL COMMENT '价格', original_price DECIMAL(10,2) COMMENT '原价', cover_image VARCHAR(255) COMMENT '封面图', images TEXT COMMENT '多图，逗号分隔', content TEXT COMMENT '商品描述', status TINYINT DEFAULT 0 COMMENT '0在售 1已下架 2已售出', create_time DATETIME DEFAULT CURRENT_TIMESTAMP );

订单表要同时存user_id、seller_id、goods_id三个外键，再加一个status字段：

CREATE TABLE orders ( id INT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL COMMENT '订单号，前端展示用', user_id INT NOT NULL COMMENT '买家ID', seller_id INT NOT NULL COMMENT '卖家ID', goods_id INT NOT NULL COMMENT '商品ID', amount DECIMAL(10,2) NOT NULL COMMENT '成交金额', status TINYINT DEFAULT 0 COMMENT '0待发货 1已发货 2已完成 3已取消', create_time DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_order_no (order_no) );

varchar(32)的order_no是给用户看的，和数据库主键id分离，这样订单号可以带日期前缀，比如20250601001，看起来更正规。上述建表语句是通用版，你拿到的库结构可能字段名不同，但语义基本一致。

3.3 Java后端分层：controller、service、dao、entity的对应关系

Java后端代码一般分四层：controller接收小程序请求，service写业务逻辑，mapper/dao负责SQL，entity是对应表的实体类。阅读顺序建议反过来：先看entity了解字段，再看mapper看SQL，最后看controller确认接口路径。以一个商品查询接口为例：

@RestController @RequestMapping("/api/goods") public class GoodsController { @Autowired private GoodsService goodsService; @GetMapping("/list") public Result list(@RequestParam(defaultValue = "1") Integer page, @RequestParam(defaultValue = "10") Integer size, @RequestParam(required = false) String keyword) { PageInfo<GoodsVO> pageInfo = goodsService.queryGoods(page, size, keyword); return Result.ok(pageInfo); } }

这段代码参数要解释清楚：page是页码，从1开始；size是每页条数，默认10；keyword是可选的搜索关键词，不传就返回全量分页。Result是统一返回体，一般包含code、message、data三个字段，小程序端判断code是否等于200即可。这里把Result写成泛型包装类，比直接返回Map要规范，答辩时能拿出来说。

3.4 接口路径怎么认：登录注册、商品、下单、发货、公告

对照源码里controller目录，常见接口路径整理如下：

整个系统前后端分离，小程序端只通过HTTP调接口拿JSON，所以接口路径、参数名、返回结构三者的对应关系是调试重点。你用Postman先把登录接口调通，拿到token后，所有需要登录的接口就都能测了。改样式这类事（源码包里的main.css.bak这类备份就是样式备份）根本不需要动后端，改完前端重新编译就行。

4. 微信小程序端实战：从注册登录到商品下单的完整链路

小程序端的代码结构类似Vue页面：pages目录放页面，每个页面有wxml、wxss、js、json四个文件；utils目录放公共方法；app.js是全局逻辑；app.json注册页面和tabBar。这一章按调试顺序把链路带通：先看请求封装，再调登录，然后渲染首页列表，最后跑通下单。

4.1 请求封装：把wx.request包成Promise

小程序原生的wx.request是回调式的，页面多了会嵌套得很痛苦。这套源码通常会在utils/request.js里封装一层Promise：

const BASE_URL = 'http://localhost:8080'; // 本地调试用，真机要改局域网IP function request(url, method = 'GET', data = {}) { return new Promise((resolve, reject) => { wx.request({ url: BASE_URL + url, method: method, data: data, header: { 'Content-Type': 'application/json', 'Authorization': wx.getStorageSync('token') || '' }, success: (res) => { if (res.data.code === 200) { resolve(res.data.data); } else { wx.showToast({ title: res.data.msg, icon: 'none' }); reject(res.data); } }, fail: (err) => reject(err) }); }); } module.exports = { request, BASE_URL };

逻辑说明：BASE_URL是出问题最多的地方，开发工具里localhost可以，真机预览必须换成电脑的局域网IP，否则手机访问不到后端；header里从storage取token，实现登录态；success里统一判断res.data.code，不为200就弹toast，业务页面不用每个都写错误处理。

4.2 登录注册：表单数据怎么提交给Java后端

登录页用两个input绑username和password，按钮触发submitLogin，然后调用request：

async submitLogin() { const username = this.data.username; const password = this.data.password; if (!username || !password) { wx.showToast({ title: '用户名和密码不能为空', icon: 'none' }); return; } try { const data = await request('/api/user/login', 'POST', { username, password }); wx.setStorageSync('token', data.token); wx.setStorageSync('userInfo', data.user); wx.switchTab({ url: '/pages/index/index' }); } catch (e) { console.error('login failed', e); } }

这里有个细节：注册时区分用户和卖家，注册页通常有单选框让用户选身份。单选框提交的值要跟后端role字段对应上，用户传1、卖家传2。很多初学者在这里翻车，选了卖家身份，后端收到的却是字符串“seller”，导致角色判断失效。所以前端提交前要保证类型是数字，用parseInt转一下。

4.3 首页数据渲染：公告和二手商品列表怎么加载

首页onLoad里并行请求公告和商品列表：

onLoad() { this.loadGoods(); this.loadNotices(); } async loadGoods() { const data = await request('/api/goods/list', 'GET', { page: 1, size: 10 }); this.setData({ goodsList: data.list }); }

wxml里用wx:for渲染：

<view class="goods-card" wx:for="{{goodsList}}" wx:key="id" bindtap="goDetail">data: { page: 1, size: 10, goodsList: [], hasMore: true }, onReachBottom() { if (!this.data.hasMore) return; this.loadGoods(this.data.page + 1); }, async loadGoods(page) { const data = await request('/api/goods/list', 'GET', { page: page, size: this.data.size }); let list = this.data.goodsList; if (page === 1) { list = data.list; } else { list = list.concat(data.list); } this.setData({ goodsList: list, page: page, hasMore: data.list.length === this.data.size }); }

逻辑说明：page从1开始，hasMore表示还有下一页。触底时page+1重新请求，新数据用concat拼在旧数据后面，避免覆盖。关键是hasMore的判断——后端返回的list长度如果小于size，说明到了最后一页，再往上拉就不该发请求。如果不做这个判断，每次触底都会发请求，白白耗流量。页面下拉刷新则调用this.loadGoods(1)重置列表。另外页面标题、顶部导航栏高度这些细节，微信小程序的胶囊按钮位置在各机型上不一样，只能真机逐台调，属于“长了记性才算会了”的细节。

4.5 下单流程：从商品详情到订单列表

商品详情页顶部是商品信息，底部放“立即购买”按钮。点击后先判断有没有登录，没登录就跳登录页：

async buyNow() { if (!wx.getStorageSync('token')) { wx.navigateTo({ url: '/pages/login/login' }); return; } const order = await request('/api/order/create', 'POST', { goodsId: this.data.goods.id, amount: this.data.goods.price }); wx.redirectTo({ url: '/pages/order/order?orderNo=' + order.orderNo }); }

下单成功后，卖家端会在“订单发货”里看到这笔订单，填完快递单号后订单状态变成“已发货”，用户端订单页面会根据status字段显示不同按钮：待发货显示“等待发货”，已发货显示“确认收货”，再点一次确认收货就调confirm接口。这个状态机逻辑不复杂，但你要注意：用户点击“确认收货”之后，商品表里的status也应同步改成“已售出”，不能只改订单状态。这个联动在service层要写清楚，否则商品会一直占着“在售”位置。

提示：答辩时老师喜欢看“封装得好不好”。所以别把wx.request裸写在页面里，优先展示utils/request.js这种统一封装，强调错误码统一处理、token统一注入，这两点是Java后端接口对接的加分项。

5. 常见问题排查：数据库、JDK、微信开发者工具三处高频翻车点

把项目跑起来的顺序一般是先装依赖，再导入数据库，然后启动后端，最后用微信开发者工具打开小程序目录。每步都有经典坑，我按遇到的频率排个序，每条都按现象、原因、解决三步写清楚。

5.1 数据库导入报错：排序规则不认识

现象：Navicat运行SQL文件，弹窗提示“Unknown collation: 'utf8mb4_0900_ai_ci'”，或者导入成功但所有中文都变成问号。

原因：SQL文件是在MySQL 8.0环境导出的，8.0默认排序规则是utf8mb4_0900_ai_ci，5.7及以下不认识；中文乱码则是连接字符集没指定。

解决：优先用替换法，把SQL里的0900_ai_ci全部替换成general_ci再导入。命令行执行：

sed -i 's/utf8mb4_0900_ai_ci/utf8mb4_general_ci/g' campus.sql

导入后如果还乱码，检查连接串里的characterEncoding=utf8参数，同时确认数据库本身的默认字符集是utf8mb4。记住：Navicat连接的高级选项卡里也要把编码选成UTF-8，三层编码都要一致，缺一层就乱码。

5.2 后端启动报时区错误或Access denied

现象：后端启动时控制台报Caused by: The server time zone value 'Öйú±ê׼ʱ¼ä' is unrecognized，或者Access denied for user 'root'@'localhost'。

原因：前者是连接串缺少serverTimezone参数，MySQL驱动8.x强制要求时区；后者是密码不对，或者root账号不允许该方式连接。

解决：连接串里加serverTimezone=Asia/Shanghai&useSSL=false&allowPublicKeyRetrieval=true。如果报Access denied，先确认application.yml里的密码和本机MySQL一致。注意有些一键安装版MySQL默认密码是空的或123456，别只看文档，用Navicat实测一下。我曾经在这上面耗了两个小时，后来才发现只是密码填错了，根本不是配置问题。

5.3 真机预览白屏、图片加载不出来

现象：微信开发者工具里一切正常，点击“真机调试”或预览扫码之后，小程序能打开但商品图片全是裂图，接口数据也加载不出来。

原因：开发者工具设置里勾选了“不校验合法域名、web-view（业务域名）、TLS版本以及HTTPS证书”，真机上这个选项不生效。个人开发没有备案域名，request合法域名配置不了，后端又是HTTP，所以真机访问被拦。

解决：分两步。本地联调用“真机调试”功能，手机和电脑同一WiFi，把BASE_URL从localhost改成电脑的局域网IP，例如http://192.168.1.100:8080，后端同时监听0.0.0.0。要发布上线就必须配备案过的HTTPS域名，不然微信不让你正式发布。图片如果还是裂图，检查后端返回的是不是相对路径，换成完整URL。这个坑属于“开发工具能用、真机必挂”的高频黑匣子，建议你答辩前一定用真机过一遍。

5.4 启动脚本一闪而过、端口被占用

现象：双击2-run.bat，窗口一闪就关了，或者浏览器打开8080端口报404。

原因：窗口一闪说明Java进程启动失败，常见原因是JDK没装或版本不对、JAVA_HOME没配、端口被其它程序占用。

解决：别用双击的方式看错误，改成命令行运行：

java -jar target/campus-web.jar

这样能看到完整报错。端口占用用这个命令查：

netstat -ano | findstr 8080

找到占用端口的PID后在任务管理器里结束进程，或者改application.yml里的server.port为8081，然后小程序端的BASE_URL也同步改端口。另外，源码如果是Eclipse WTP工程，先确认JDK编译级别和项目要求的版本一致，是1.8还是11，不一致会出现UnsupportedClassVersionError。

5.5 用户明明注册成功，登录却提示密码错误

现象：注册后表单提示成功，但去登录一直报“用户名或密码错误”。查看数据库发现密码字段存的是明文，看起来没问题。

原因：注册时后端可能对密码做了MD5或BCrypt加密，但登录页传过去的密码没有做同样处理，或者加密算法不一致。

解决：看数据库密码格式就能判断。如果密码是一串32位的MD5，那登录接口里也把密码加密后再比较；如果密文带$2a$开头，就是用BCrypt，后端直接用passwordEncoder.matches()校验，不要自己再加密一次。你调试时用一个已知密码重新注册，然后拿这个密码去登录，能最快定位是哪一端没有做同样的处理。

6. 多快能验证跑通：一组测试账号与一个最小功能改动

这套资源解压后源码、演示视频都在压缩包里，建议你先看演示视频对照效果，再按下面的顺序复现。拿到源码先别急着改界面，花二十分钟走一遍验收路径，确认整条链路是通的，然后从最小改动开始动手。

6.1 验证链路：按这个顺序点一遍

准备两个测试账号，一个注册成普通用户、一个注册成卖家，再登管理员后台给卖家审核通过。然后按下面的顺序操作，对照预期结果：

这五步能跑通，说明数据库、后端、小程序三端没问题，剩下的都是改样式和扩展功能。跑不通就按第5章的顺序排查，优先看后端控制台报错，再看数据库表字段。

6.2 最小改动：给商品列表加一个价格排序

很多老师会在答辩时问“能不能按价格排序”。这个需求改动非常小，适合作为二次开发切入点。后端的GoodsController加一个可选参数sort，默认不排序：

@GetMapping("/list") public Result list(@RequestParam Integer page, @RequestParam Integer size, @RequestParam(required = false) String keyword, @RequestParam(required = false) String sort) { return Result.ok(goodsService.queryGoods(page, size, keyword, sort)); }

mapper里加一段动态SQL：

<select id="queryGoods" resultType="com.campus.entity.GoodsVO"> SELECT * FROM goods WHERE status = 0 <if test="keyword != null and keyword != ''"> AND (title LIKE CONCAT('%', #{keyword}, '%') OR content LIKE CONCAT('%', #{keyword}, '%')) </if> <if test="sort == 'price_asc'"> ORDER BY price ASC </if> <if test="sort == 'price_desc'"> ORDER BY price DESC </if> </select>

小程序端的商品列表页加一个排序按钮，请求时多带一个sort参数：

loadGoods(sort = '') { request('/api/goods/list', 'GET', { page: 1, size: 10, sort }); }

这个改动覆盖了后端参数接收、SQL拼接、前端请求三个环节，完整展示了怎么在不破坏原结构的情况下加需求。MySQL的ORDER BY后面不能直接拼接用户输入的字段名，所以这里用白名单判断sort只能是price_asc或price_desc，这属于SQL注入防御的入门做法，答辩提一句很加分。

我到现在还记得第一次拿到这类毕设源码时的场面：急着看代码，跳过数据库，直接启动后端，结果报一连串错还不知道去哪查。后来习惯改成先看文档、再导库、再起后端、最后过链路，几乎没有再为环境问题熬过夜。从那以后，我每次拿到新工程都强制走一遍“导库、起服务、过核心流程”三件套，再去动业务代码。希望帮到你。

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