企业官网建设流程全解析

每到毕业设计季，“校园代送服务平台”这类题目几乎可以说是Java Web方向最热门的选择之一。原因很简单：业务场景学生党都懂、角色划分清晰、订单状态流转能体现系统设计能力，而且用SSM框架实现起来难度适中，既能展示功底又不至于给自己挖太深的坑。我见过很多人拿着这套题目却不知道从哪下手，也有不少人代码能跑起来但一被问“订单并发接单怎么办”就卡壳。这篇就从一个完整的项目视角，把需求定位、数据库设计、核心功能实现、环境搭建、常见坑位和答辩准备一次讲透，让你真正做到“学得会、做得出、能展示”。

1. 项目定位与整体设计思路

1.1 校园代送到底在解决什么问题

先聊需求。校园里的代送场景特别真实——快递驿站离宿舍区两公里，食堂饭点排队排到怀疑人生，临时要交文件但人不在校区。这些需求以前靠的是QQ群和朋友圈“喊一嗓子”，但群消息刷得太快，信息不结构化，谁接了单、送到没有、给不给报酬全靠自觉和缘分。

代送服务平台本质上做的是两件事：一个是供需匹配，把“我有跑腿需求”和“我有空余时间”的两类人拉在一起；另一个是建立信任和履约保障，发单人知道订单有人接、有人送，接单人知道自己做完能拿到对应的报酬。

所以系统功能可以拆成三条主线：面向普通用户的发单、接单、订单管理；面向接单人的接单与状态更新；面向管理员的用户管理、订单监控和统计报表。搞清楚这三条主线，你就知道后面数据库要建哪些表、接口要做到什么程度。我不建议一上来就堆功能，先抓住“一条订单从发布到完成要经历哪些状态”这个核心，整个系统的骨架就立住了。

1.2 为什么选SSM这套技术栈

SSM就是Spring + Spring MVC + MyBatis的组合，前些年几乎是Java Web开发的标准配置，直到今天依然是很多高校毕业设计题目里明确限定的技术选型。

拆开看三个框架各自的职责：Spring负责对象创建和依赖管理，也就是IOC和AOP，事务控制也归它；Spring MVC负责接收前端请求，做路由分发，把URL对应到Controller的方法上；MyBatis负责数据持久层，把Java对象和数据库表之间的映射交给XML或注解来处理。

有人会问，现在公司里不是都用Spring Boot了吗，为什么还要用SSM？这个问题在答辩时也经常被老师问到。我的理解是：SSM的配置是全手动的，你能亲眼看到web.xml、spring-mvc.xml、mybatis-config.xml这些文件怎么把三层框架粘起来，而Spring Boot把这些全部自动装配了，反而少了一层“原来原理是这样”的领悟。用SSM做完一个项目再去看Spring Boot，几乎可以无缝切换；反过来直接学Boot的人再回看SSM，往往会觉得“网页请求是怎么进到Controller的”很抽象。

另外SSM的技术资料极其丰富，遇到问题搜一下基本都有现成答案，Tomcat 8 + JDK 1.8 + MySQL 5.7这套经典环境跑起来也稳，对毕业生来说“能跑通”本身就是很重要的一件事。

1.3 角色划分与核心业务流

这个平台涉及三类角色：发单人、接单人、管理员。这里多说一句，很多学生在设计时把“用户”和“接单人”拆成两套系统，其实大可不必，同一个用户既可以发布需求也可以接别人的单，用角色字段区分管理员和普通用户就够了，不需要搞两套注册登录。

角色能力如下表所示：

订单的核心流程是：用户发布订单后，订单进入“待接单”状态；另一个用户看到订单并点击接单，订单变成“配送中”；接单人完成代送后标记送达，发单人确认无误，订单进入“已完成”状态。过程中任何一方都可以取消订单，但要区分原因：发单人在无人接单前取消、接单人接单后无正当理由取消，这两种情况对信用分的影响是不一样的。

这个业务流对应的就是整个系统最核心的表结构设计和代码逻辑，后面几章我就按这个流程往下拆。

2. 数据库设计与核心流程建模

2.1 核心表结构拆解

数据库是整个项目的根基，表设计烂了，后面写代码会无比痛苦。这个项目我建议至少设计四张核心表：用户表、订单表、评价表、公告表。有精力的话可以加一张钱包流水表，做余额结算用。

用户表的信息比较标准，重点字段如下：

CREATE TABLE t_user ( user_id INT PRIMARY KEY AUTO_INCREMENT COMMENT '用户ID', username VARCHAR(20) NOT NULL UNIQUE COMMENT '登录名', password VARCHAR(64) NOT NULL COMMENT '加密后的密码', nickname VARCHAR(20) COMMENT '昵称', phone VARCHAR(11) COMMENT '手机号', role TINYINT DEFAULT 1 COMMENT '1用户 2管理员', balance DECIMAL(10,2) DEFAULT 0 COMMENT '账户余额', credit_score INT DEFAULT 100 COMMENT '信用分', status TINYINT DEFAULT 1 COMMENT '1正常 0禁用', create_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT '注册时间' ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

订单表是整个系统里字段最多的，也是核心中的核心。

CREATE TABLE t_order ( order_id INT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL COMMENT '订单编号', publisher_id INT NOT NULL COMMENT '发单人ID', taker_id INT DEFAULT NULL COMMENT '接单人ID', type TINYINT DEFAULT 1 COMMENT '1取快递 2代买饭 3代送文件 4其他', title VARCHAR(50) NOT NULL COMMENT '标题', content VARCHAR(500) COMMENT '需求描述', reward DECIMAL(6,2) DEFAULT 0 COMMENT '代送费', pickup_location VARCHAR(100) COMMENT '取件地点', deliver_location VARCHAR(100) COMMENT '送达地点', status TINYINT DEFAULT 1 COMMENT '1待接单 2配送中 3已完成 4已取消', create_time DATETIME DEFAULT CURRENT_TIMESTAMP, accept_time DATETIME COMMENT '接单时间', finish_time DATETIME COMMENT '完成时间', KEY idx_status (status), KEY idx_publisher (publisher_id), KEY idx_taker (taker_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

这里有两个细节想提醒一下。一个是代送费用字段我命名为reward而不是price，原因是代送场景下这个钱更像“跑腿辛苦费”，叫reward在业务语义上更贴合，去答辩被问字段设计时你能说清楚这个区别就是加分项。另一个是订单号order_no，建议用时间戳加随机数生成，不要让外部用户直接通过自增ID猜测系统里有多少订单。

2.2 订单状态流转：最容易画错的一张图

订单状态是整个项目逻辑最密集的地方，设计得清晰不清晰，直接决定你写Service层代码时顺不顺畅。

我建议用整数状态值，通过常量类统一管理，而不是用字符串，更不要用中文存数据库。整数占用小、比较快、不容易出现编码问题，而且前端展示时可以做状态字典映射。

设计状态的时候，最关键的规则是：每个状态变更动作都必须带前置状态条件。比如接单操作，代码逻辑不能只判断“订单存在”，还要判断“订单当前状态是1”，这样的更新语句才能防住并发问题，我在下一章详细展开。

业务上还建议区分“发单人取消”和“接单人取消”，所以有些项目会在状态之外再加一个cancel_by字段记录是谁取消了订单。给前端展示提示、给管理员判断责任归属，都有用。

2.3 几个容易忽略但很重要的设计细节

除了表和状态，还有几个细节是这类项目能不能从“能用”升级到“好用”的关键。

信用分机制。校园代送平台最大的问题是信任，所以用户表里我特意留了credit_score。发单人可以查看接单人的信用分来决定要不要把单子给他，这也逼着接单人不敢随便放鸽子。已经完成的订单，如果发单人评价时给了差评，信用分可以扣5到10分，零分以下禁用接单功能。

时间字段的完整记录。订单表里我加了三段时间：create_time、accept_time、finish_time。别小看这三个字段，管理员后台做“平均接单时长”“平均完成时长”这类统计就靠它们。很多学生做统计报表时发现没数据可查，就是因为建表的时候没预留这些字段。

资金结算。如果系统里涉及虚拟余额，就要设计好结算时机。最安全的做法是：发单人在发布订单时冻结余额，接单人确认送达、发单人确认完成后，再把报酬从冻结金额转入接单人的余额。这个逻辑用简单的事务就能保证，但是新手很容易做成“订单完成时只加接单人余额，忘记扣发单人余额”，这种问题一查一个准。

数据库字符集也别忘了，建库时统一用utf8mb4，否则用户昵称里出现表情符号就会报错，你排查半天也想不到是这个原因。

3. 功能模块实现的关键环节

3.1 登录注册与登录拦截怎么做

几乎所有业务接口都需要知道“当前登录的是谁”，所以安全拦截是第一个要做的公共功能。

注册时的密码不能明文存。虽然只是课程设计，但养成好习惯很有必要。简单方案是加盐MD5，比如把用户名字符串拼到密码后面再算MD5，这样即使两个用户密码相同，存到数据库里的密文也不一样。更专业的做法是用BCrypt，但很多SSM毕设项目里MD5加盐已经够用，答辩时能说出“为什么不能明文存密码”就比很多人强。

登录状态的校验，用Spring MVC的拦截器来完成，比在每个Controller方法里重复写判断要优雅得多。核心代码如下：

public class LoginInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { HttpSession session = request.getSession(); User loginUser = (User) session.getAttribute("loginUser"); if (loginUser == null) { response.sendRedirect(request.getContextPath() + "/login"); return false; } return true; } }

在spring-mvc.xml里配置拦截规则：

<mvc:interceptors> <mvc:interceptor> <mvc:mapping path="/**"/> <mvc:exclude-mapping path="/login/**"/> <mvc:exclude-mapping path="/register/**"/> <mvc:exclude-mapping path="/static/**"/> <bean class="com.school.interceptor.LoginInterceptor"/> </mvc:interceptor> </mvc:interceptors>

这里有个典型的坑：静态资源路径一定要放行，否则CSS、JS、图片全被拦截，页面样式全丢。别问我怎么知道的，这种问题排查起来特别容易让人怀疑人生。

3.2 发单与接单流程的核心逻辑

发单操作相对简单，校验登录、校验标题和内容非空、校验代送费大于等于0，然后插入订单表，状态为1（待接单）。但有一个前端也要配合的细节：发单时如果选择了余额支付，后端要检查用户余额是否足够，不够就直接返回提示，不能让请求落到数据库。

接单是系统里并发风险最高的操作。想象一个场景：一笔代送费给得比较高的订单挂出去，两个用户几乎同时点了接单，如果代码只是先查订单状态再更新，就可能出现两个人都显示“接单成功”。

解决办法是用一条带状态条件的更新SQL来做原子判断：

int rows = orderMapper.updateOrderStatus(1, 2, orderId, userId); if (rows > 0) { // 当前用户接单成功 } else { // 订单已被别人抢走，提示“手慢了” }

对应的SQL是：

UPDATE t_order SET status = 2, taker_id = #{userId}, accept_time = NOW() WHERE order_id = #{orderId} AND status = 1

这种写法的妙处在于，更新操作本身是数据库层面的原子操作，两个并发请求只有一个能把状态从1改成2，另一个受影响行数是0，逻辑上就保证了不会超卖。

3.3 状态变更接口的统一规范

前面说了订单状态不能随便改。落实到代码层面，我建议每个状态变更方法都遵循一条铁律：更新条件里必须包含“当前状态”和“操作人”。

举个例子，发单人确认完成这个操作，SQL长这样：

UPDATE t_order SET status = 3, finish_time = NOW() WHERE order_id = #{orderId} AND status = 2 AND publisher_id = #{publisherId}

为什么要带publisher_id？因为接口如果是/order/finish?orderId=1，任何人都可以去调用，不带归属校验就是越权漏洞。这是很多毕设项目的硬伤，老师随便点两下就能发现“我能操作别人的订单”。这个问题写代码的时候就要从SQL层面堵住。

站内消息通知可以单独建一张t_notice表，主要字段是通知ID、接收用户ID、内容、是否已读、创建时间。当订单状态变化的时候，往这张表里插一条记录，前端在导航栏做个小红点提示。这个功能属于典型的“做出来不一定多难，但体验提升明显”的加分设计。

3.4 后台管理：统计报表怎么做才不Low

管理员后台最忌讳的就是只做一个“查看所有订单”的列表，没有营养。稍微加一点统计维度，整个项目的完成度就不一样了。

最简单的统计是三块：用户总数、今日新增订单数、各状态订单占比。查询用聚合函数就能搞定：

SELECT DATE_FORMAT(create_time, '%Y-%m-%d') AS day, COUNT(*) AS order_count, SUM(CASE WHEN status = 3 THEN 1 ELSE 0 END) AS completed_count FROM t_order WHERE create_time >= DATE_SUB(CURDATE(), INTERVAL 30 DAY) GROUP BY day ORDER BY day;

如果你愿意在统计页面引入ECharts，画一张近30天订单趋势折线图和一张状态占比饼图，整个项目的展示效果直接上升一个档次。这不需要你懂前端框架，引入一个CDN、照着官网示例改几行代码就行，但在答辩演示时非常占便宜，老师会觉得你这人有产品意识。

4. 环境搭建与实操过程复盘

4.1 经典环境的版本搭配

这类SSM项目在本地跑不起来，大半原因出在环境版本上。我直接用最省事、踩坑最少的组合：JDK 1.8、Tomcat 8.5、MySQL 5.7、Maven 3.6.3、IDEA 2021之后任何版本都行。

这里特别说三点。第一，JDK千万别用17往上，很多老项目用的依赖不支持高版本，编译直接报错，没必要给自己找麻烦。第二，数据库连接驱动版本要和MySQL版本匹配，MySQL 5.7用mysql-connector-java的5.1.49就行，如果你本机装的是MySQL 8.x，驱动要用8.0.x对应的版本。第三，连接串里一定要写时区，否则连数据库报错能让人抓狂。

jdbc.driver=com.mysql.jdbc.Driver jdbc.url=jdbc:mysql://localhost:3306/school_express?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai jdbc.username=root jdbc.password=你的密码

4.2 从零到能跑通的三步走

第一步，执行数据库脚本。在Navicat或命令行里建好数据库，然后依次运行你准备的建库建表SQL。建议把测试数据也一起插入，不然前端列表页面空空如也，看着就像没开发完。测试数据尽量造得跟真实场景一样，比如“代取快递”“帮带食堂二楼黄焖鸡”“送文件到行政楼309”，这种数据演示时观感非常好。

第二步，改配置文件。jdbc.properties改成你自己本地的数据库账号密码，spring-mvc.xml里如果配置了上传路径或图片保存路径，也要换成本地存在的目录，很多项目启动失败都是因为配置文件里指向的路径在别人电脑上不存在。

第三步，IDEA里配置Tomcat部署。这里有个常见误区——新手总是选war包方式部署，其实开发阶段应该用war exploded模式，这样修改代码后热部署快很多。进入Run -> Edit Configurations -> Tomcat Server -> Local，在Deployment选项卡里把项目加进去，Application context填/就行了，不建议填项目路径前缀，否则所有前端跳转路径都要带项目名。

我第一次跑这种项目的时候，遇到最多的是启动时tomcat日志还没报错，浏览器却白屏。后来才明白是启动时只部署了空的war包，根本没把项目构建产物装进Tomcat。所以记住：Build -> Build Artifacts -> Rebuild一下，再去启动Tomcat，基本能避免这个诡异问题。

4.3 演示模式下如何准备数据

项目能跑通之后，别急着喊“完了”，给系统里造一组“演示专用数据”特别重要。我的习惯是准备四类订单：一笔正在“待接单”状态的、一笔正在“配送中”状态的、一笔“已完成”带评价的、一笔“已取消”的。为什么？因为你演示的时候要从展示业务闭环的角度讲，而不是从空荡荡的列表开始。

演示顺序建议：先以普通用户身份登录，展示首页待接单列表；点击接单，演示状态从待接单变为配送中；然后切换回发单人身份，确认完成；最后演示评价功能和管理员后台的统计图表。整个过程就像讲一个完整的小故事，老师听着也轻松。

5. 常见问题排查与避坑实录

5.1 MyBatis动态SQL的坑

写多条件查询时，最经典的问题就是条件拼接和AND的位置。如果你手写where 1=1其实也能跑，但不太优雅。正确做法是使用<where>标签：

<select id="selectOrderList" resultType="com.school.entity.Order"> SELECT * FROM t_order <where> <if test="status != null"> AND status = #{status} </if> <if test="publisherId != null"> AND publisher_id = #{publisherId} </if> <if test="type != null"> AND type = #{type} </if> </where> ORDER BY create_time DESC </select>

<where>标签会自动处理第一个条件前面的多余AND，这个特性你用过一次就离不开了。另外记住一件事：动态SQL里的比较值用#{status}，不要用${status}。#{}是预编译占位符，能防SQL注入，${}是字符串拼接，能不用就不用。

5.2 中文乱码的排查三步法

中文乱码是SSM项目的高发问题，从浏览器到数据库每一层都可能出问题。我的排查顺序是固定的：

先看数据库连接串有没有characterEncoding=utf8；再看Tomcat的server.xml里Connector是不是配了URIEncoding="UTF-8"；最后看JSP页面头部的编码声明是不是contentType="text/html; charset=UTF-8"。这三处都对，乱码基本消灭。如果在控制台看SQL日志出来是乱码但数据库存的是对的，那只是日志输出编码问题，不影响功能，别浪费时间纠结。

5.3 本地跑不起来的五个检查点

我总结过一份速查表，遇到问题按顺序过一遍，绝大多数都能救回来。

这些坑每一个我都踩过不止一次，说实话排查能力才是这类项目真正训练人的地方。代码写错能查出来，配置写错也能查出来，最怕的是不知道从哪里下手，学会对着现象找原因，比背十篇原理都管用。

5.4 答辩时怎么把项目讲出彩

项目做完只是第一步，能讲清楚才是毕业设计真正要考察的东西。我的建议是准备四个环节：先讲需求背景，30秒说完“代送场景为什么存在”；再讲系统设计，把角色、核心状态流转对着表结构图讲一遍；接着现场演示，按我前面说的顺序把业务闭环走完；最后准备几个老师高频问题。

高频问题通常是这四个：

最后分享一点个人体会。带过不少学弟学妹做这类项目，我发现一个规律：拿到资料先急着跑通的人，后面往往要花更多时间补基础；而先花半小时把表结构和状态流转理清楚的人，写起代码来反而最快。所以“学得会、做得出、能展示”这三个词，顺序其实是反过来的——你得先能展示出设计思路，才谈得上把代码做出来，最后才能真正学进脑子里。这套SSM校园代送项目本身并不难，难的是把每个细节都当成正经工程问题对待。你不用追求功能多到花里胡哨，把“发单—接单—送达—确认—评价”这条主链路做得干净利落，再补上权限控制和统计报表，这份答卷就已经超过大多数人了。