这个选题我在给不少学生做课程设计和毕业设计评审时见过太多次了。每逢毕业季，"校园跑腿任务接单服务平台"这种题目几乎成了Java Web方向的标配，ssm26这种编号一看就是某个课件资源站上的标准命名。说实话，这个题目能火不是没原因的——业务场景贴近生活、功能边界清晰、技术栈经典，特别适合用来检验一个学生是否真正掌握了SSM框架的整合能力。
但我每次看学生交上来的东西，发现一个普遍问题：大家都能把CRUD跑通，登录注册也没毛病，可一旦问到"两个人同时抢同一个订单怎么办""订单状态怎么流转才不会乱"这类问题，基本就卡壳了。这正是我写这篇东西的动机——把"能跑"和"能用"之间的差距补齐，把一个真实的校园跑腿订单系统该有的设计思路、实现细节和坑点全部翻出来讲清楚。
1. 项目定位与核心需求拆解
1.1 业务场景与角色划分
校园跑腿平台解决的痛点非常具体：大学生在校园内有大量"没时间但可以用钱解决"的琐事——代拿快递、代买饭、代打印资料、代取外卖、甚至代上课打卡。而另一部分学生有时间想赚零花钱，却找不到靠谱的信息渠道。以前这事儿靠QQ群、朋友圈吼一嗓子，效率低下且没有保障。这个项目本质上是把线下的零散需求变成一个C2C的交易撮合平台，只是业务范围被限定在校园这个封闭场景内。
从系统设计的角度，封闭场景带来一个天然优势——信任成本低。用户都是在校学生，可以用学号认证，这比面向全社会的众包平台好做得多。但封闭不等于简单，角色划分还是要清晰。整个系统涉及三类角色：
- 普通用户（需求方）：发布任务、查看任务状态、确认完成、评价、充值支付。
- 接单者（跑腿方）：浏览待接单任务、抢单、上传完成凭证、提现。
- 系统管理员：用户管理、任务审核（可选）、公告发布、数据统计、异常处理。
这里有个常见的建模错误：很多学生会把用户和接单者拆成两张完全独立的表。实际上一个人既可以发任务也可以接任务，正确做法是一张用户表加一个"是否开通接单身份"的标记字段，或者用角色关联表。我在实际指导时更推荐后一种——用户表、角色表、用户角色关联表，这样扩展管理员之外的中间角色（比如骑手队长）时不用改表结构。
1.2 功能清单与优先级排序
任何项目的功能规划都要考虑交付周期。如果是课程设计，通常有8到12周时间；如果是毕业设计，时间宽裕些但也不能铺太开。我建议按照下面的优先级来排功能：
| 优先级 | 功能模块 | 核心内容 | 备注 |
|---|---|---|---|
| P0 | 用户认证 | 注册、登录、注销、密码加密 | 一切功能的前提，先做 |
| P0 | 任务发布与浏览 | 发任务、列表查询、关键词搜索 | 核心主流程的入口 |
| P0 | 接单与状态流转 | 抢单、状态更新、确认完成 | 系统的核心闭环 |
| P1 | 订单管理 | 我发布的、我接的，按状态筛选 | 用户自助查询，减少客服成本 |
| P1 | 评价体系 | 星级评分+文字评价 | 构建信任的基础 |
| P2 | 支付与结算 | 虚拟币充值、接单收益提现 | 课程设计可做模拟版本 |
| P2 | 管理后台 | 用户禁用、订单仲裁、数据看板 | 毕设加分项 |
P0必须全部完成并且逻辑严密，P1尽量完成，P2可以做个简化版。很多学生上来就想着做支付订单接入微信支付宝，结果卡在商户资质上，浪费时间。校园场景完全可以用"虚拟币"模拟：充值写成"模拟充值"，提现写成"申请提现，管理员线下转账"，业务闭环一样成立，还能避开第三方支付接口的审核门槛。
1.3 核心业务流程要理顺
先看主流程：用户发布任务，任务进入"待接单"池；接单者看到后抢单，任务变"进行中"；跑腿完成后上传凭证或者标记完成，用户确认，订单变"已完成"；最后双方互评，流程结束。这个链路中间有岔路：用户可以在"待接单"状态下取消任务，如果无人接单超时，系统可以自动取消。
这里特别要强调状态机的设计，因为它是整个系统的"神经网络"。我见过太多人用int数字表示状态，结果代码里到处是if (status == 1 || status == 3)这种魔法数字，后期改一个状态都要全局搜索替换。
我的建议是使用String类型的常量类或者枚举来管理状态，比如用TaskStatusEnum类定义常量：PUBLISHED(0, "待接单")、ACCEPTED(1, "进行中")、COMPLETED(2, "已完成")、CANCELLED(3, "已取消")、OVERDUE(4, "已超时")。好处有两点：一是业务语义清晰，二是后续做状态流转校验时，可以配一张状态流转图——只有合法的状态迁移才允许执行，非法操作直接抛异常。这块的设计深度，恰恰是拉开"及格项目"和"优秀项目"距离的关键之一。
2. 技术选型与SSM整合实操
2.1 为什么选SSM而不是Spring Boot
这是个很实际的问题，毕竟2025年了，新项目默认都是Spring Boot。但作为课程设计/毕业设计，SSM框架组合依然有不可替代的教学价值：它让你被迫去理解Spring容器怎么管理Bean、SpringMVC的DispatcherServlet怎么和容器交互、MyBatis的Mapper代理怎么被扫描注入——这些在Spring Boot里一行注解就搞定了固然方便，但你也失去了理解底层的机会。
面试时，Spring Boot项目很难问出深度，而SSM项目可以追着问"Spring容器和SpringMVC容器是什么关系""为什么Mapper接口不需要写实现类""事务切面是怎么织入的"，这些问题都能体现真实功底。所以如果你的目标是积累技术深度，选SSM是合理的。
2.2 Maven工程结构与依赖版本搭配
工程结构用Maven多模块还是单模块？学生项目建议单模块就够，但包结构一定要按职责分层：
com.campus.task ├── controller # 接口层，只做参数接收和视图/JSON返回 ├── service # 业务层，接口+实现 │ └── impl ├── dao # MyBatis Mapper接口 ├── entity # 数据库实体类 ├── dto # 数据传输对象（页面表单封装） ├── vo # 视图对象（返回给前端的组装数据） ├── common # 常量、工具类、统一返回结果 ├── interceptor # 拦截器（登录、管理员权限） └── config # Spring配置类（如果使用注解配置）依赖版本上给一套经过验证的组合：Spring 5.3.x + SpringMVC 5.3.x + MyBatis 3.5.x + MyBatis-Spring 2.0.x + MySQL驱动8.0.x + Druid连接池1.2.x + Jackson 2.13.x + Lombok 1.18.x。这个组合我实测过，兼容性没问题，不要盲目追新版本，更不要混用Spring 4和JDK 17——那是给自己找事。
提示：JDK版本建议用JDK 8或JDK 11。如果你非要用JDK 17，就要确保Spring版本至少是5.3.x以上，并且注意MyBatis的ASM版本兼容问题，否则运行时容易报奇怪的字节码错误。
2.3 三大框架配置文件的整合细节
SSM整合的本质是：让Spring容器管理service和dao的所有Bean，让SpringMVC的子容器只负责controller，同时两者共享同一个业务层。这里有一个大量初学者踩进去的坑——组件扫描的重复问题。
SpringMVC的配置文件中应该只扫描controller包，Spring的配置中扫描service和dao。如果你在SpringMVC的扫描配置里不小心写成了base-package="com.campus.task"，那么controller和service全被SpringMVC容器管理了，事务配置放在Spring容器里就会失效——因为事务切面织入的是Spring容器中的Bean，而实际调用的Bean却在SpringMVC容器里，结果就是事务完全不管用，数据写到一半报错，数据库里留下一半数据。
我把一个标准的整合方案拆成四步，照着配置即可：
第一步，web.xml里配置Spring的ContextLoaderListener和SpringMVC的DispatcherServlet。注意DispatcherServlet的初始化参数要指定SpringMVC配置文件的位置，并且url-pattern设置为/，走REST风格。
第二步，spring.xml（或applicationContext.xml）里开启注解驱动、配置数据源和事务管理器、扫描service层和dao层：
<context:component-scan base-package="com.campus.task.service, com.campus.task.dao"/> <!-- 事务管理器 --> <bean id="transactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager"> <property name="dataSource" ref="dataSource"/> </bean> <tx:annotation-driven transaction-manager="transactionManager"/>第三步，spring-mvc.xml里只扫描controller，同时配置注解驱动、视图解析器、静态资源放行和文件上传解析器。
第四步，MyBatis整合到Spring里，关键是把SqlSessionFactory交给Spring管理，Mapper扫描用MapperScannerConfigurer：
<bean class="org.mybatis.spring.mapper.MapperScannerConfigurer"> <property name="basePackage" value="com.campus.task.dao"/> <property name="sqlSessionFactoryBeanName" value="sqlSessionFactory"/> </bean>完成这一步之后，你的Mapper接口就能被自动代理注入，不需要手写实现类，这也是MyBatis-Spring的核心机制。这里有一个细节：如果你使用sqlSessionFactoryBeanName而不是sqlSessionFactory，可以避免配置解析顺序导致的问题，我强烈建议用前者。
2.4 前端资源的组织策略
SSM项目的前端不建议做成前后端分离，就用JSP+JSTL+少量原生JS是最稳妥的方案。原因很实际：不分离意味着你不需要额外处理跨域、Token鉴权，Session直接在服务端管理，逻辑简单，也符合课程设计的评分标准。
但JSP有一个致命问题是标准标签库在老版本容器下的兼容性。如果你的Tomcat版本是9.x或者10.x，要注意JSTL的依赖版本要使用jakarta.servlet.jsp.jstl坐标，而不是老的javax.servlet.jsp.jstl，否则页面上的<c:forEach>标签全都不渲染，还报奇怪的TLD错误。
另外，静态资源（CSS、JS、图片）建议放到/static目录下，并在SpringMVC配置中放行：
<mvc:resources mapping="/static/**" location="/static/"/>3. 数据库设计：跑腿平台的核心建模
3.1 概念模型与实体关系
我在设计这一类平台时，脑子里先画的是一张实体关系总图：用户（User）与任务（Task）之间有两种关系——一个用户发布多个任务，一个任务属于一个发布者；同时一个任务被一个接单者承接。任务发布后产生一个订单（Order），订单关联发布者和接单者。订单完成后产生评价（Evaluation），评价针对订单而不是任务，因为一次任务可能反复发布但订单是唯一的。此外还有公告（Notice）、支付流水（Payment）和提现申请表（Withdraw）。
这个关系模型的核心是订单作为连接用户的枢纽。如果你只设计任务表而不管订单表，后面做"我发布的"和"我接的"的时候就要靠两个user_id字段反复查，逻辑容易混乱。把订单抽象出来之后，每个用户的接单记录、收入统计、完成率都有了数据来源。
3.2 核心表结构详解
用户表（t_user）
| 字段名 | 类型 | 说明 |
|---|---|---|
| id | bigint | 主键，自增 |
| username | varchar(50) | 登录名，唯一索引 |
| password | varchar(100) | BCrypt加密后的密码 |
| real_name | varchar(30) | 真实姓名 |
| student_no | varchar(20) | 学号，校园认证用 |
| phone | varchar(20) | 手机号 |
| avatar | varchar(255) | 头像路径 |
| balance | decimal(10,2) | 账户余额（虚拟币） |
| status | tinyint | 0-正常 1-禁用 |
| create_time | datetime | 注册时间 |
密码加密必须用BCrypt而不能用MD5加盐这种自己发明的方案。Spring Security里直接有BCryptPasswordEncoder，即使你不引入完整的Spring Security，单独引入spring-security-crypto包也能单独使用这个类。MD5就算加了盐，在GPU暴力破解面前也不够看。
任务表（t_task）
| 字段名 | 类型 | 说明 |
|---|---|---|
| id | bigint | 主键 |
| publisher_id | bigint | 发布者id |
| task_type | varchar(20) | 任务类型：快递/外卖/打印/其他 |
| title | varchar(100) | 任务标题 |
| detail | text | 详细描述 |
| reward | decimal(10,2) | 悬赏金额 |
| address | varchar(255) | 取件/送件地点 |
| contact_phone | varchar(20) | 联系电话 |
| status | varchar(20) | 状态，见状态枚举 |
| deadline | datetime | 期望完成时间 |
| create_time | datetime | 发布时间 |
订单表（t_order）
| 字段名 | 类型 | 说明 |
|---|---|---|
| id | bigint | 主键 |
| task_id | bigint | 关联任务 |
| publisher_id | bigint | 发布者 |
| accepter_id | bigint | 接单者 |
| status | varchar(20) | 订单状态 |
| accept_time | datetime | 接单时间 |
| finish_time | datetime | 完成时间 |
| cancel_reason | varchar(255) | 取消原因 |
评价表（t_evaluation）
| 字段名 | 类型 | 说明 |
|---|---|---|
| id | bigint | 主键 |
| order_id | bigint | 关联订单 |
| from_user | bigint | 评价人 |
| to_user | bigint | 被评价人 |
| score | tinyint | 1-5星级 |
| content | varchar(500) | 评论内容 |
| create_time | datetime | 评价时间 |
3.3 时间字段与并发字段的设计心得
首先，所有金额字段用decimal不要用float/double。float在MySQL里是近似值，算钱会出精度问题。学生项目里最容易栽的就是这个——存了9.9元，查出来9.899999999。
其次，任务表要加version字段用于乐观锁，这一点在后面的抢单场景里非常关键。另外，如果表里需要状态和时间一起变化，可以考虑把状态变更日志单独建一张表，虽然课程设计阶段不是必须，但如果你在答辩时提到"我设计了状态变更日志表用于审计追踪"一定会加分。
还有一个很容易忽略的问题：索引设计。任务列表页需要按状态和创建时间查询，所以联合索引(status, create_time)是必需品；订单表需要按publisher_id和accepter_id查，两个单列索引即可。这些索引什么时候建？不应该在建表初期就拍脑袋建，而是先在业务代码里梳理高频查询，再针对性地建索引。
4. 核心功能模块实现：从登录到接单闭环
4.1 登录鉴权与角色权限控制
我建议这个项目不要引入Shiro或Spring Security这种安全框架，一是增加了学习成本，二是在课程设计答辩时容易被追问细节答不上来。用拦截器+Session足够支撑需求，而且逻辑直观。
具体做法：登录成功后把用户信息放入Session，自定义一个LoginInterceptor拦截所有需要登录的请求，在preHandle里检查Session是否为空。对于管理员接口，写一个AdminInterceptor继承自LoginInterceptor（或者先过Login再过Admin），检查用户角色。
拦截器的url-pattern要精准设计。通常放行的路径是：登录、注册、首页、静态资源、任务列表（浏览不需要登录）。需要登录的是：发布任务、订单管理、个人中心、接单操作。需要一个容易犯错的点：Ajax请求被拦截返回的是登录页面HTML而不是JSON，前端拿到200状态码但contentType不对，解析就报错。解决办法是在拦截器里判断请求头X-Requested-With是否为XMLHttpRequest，如果是就返回JSON错误信息，否则重定向到登录页。
4.2 任务发布与订单状态机的完整实现
发布任务的业务逻辑不算复杂，但是要在Service层把一件事做对：开启事务。因为发布任务不只插入task表一行，还要处理任务编号字段、初始化订单关联、扣除发布者余额（如果采用发布即扣费模式）、写入支付流水。任何一个步骤失败都要全部回滚。
状态机的核心在于每一步状态变更必须校验当前状态。
举个例子，接单操作的Service方法伪代码：
@Transactional public void acceptTask(Long taskId, Long userId) { // 1. 查询任务，加锁或乐观锁版本判断 Task task = taskMapper.selectByIdForUpdate(taskId); // 2. 业务校验：任务必须处于"待接单"状态 if (!TaskStatus.PUBLISHED.equals(task.getStatus())) { throw new BizException("该任务已被抢走或已下架"); } // 3. 不能接自己发的任务 if (task.getPublisherId().equals(userId)) { throw new BizException("不能接自己发布的任务"); } // 4. 更新状态和接单者信息 task.setStatus(TaskStatus.ACCEPTED); task.setAccepterId(userId); // 5. 写入订单表 taskMapper.updateByPrimaryKeySelective(task); orderMapper.insert(OrderEntity.createByTask(task)); }这套流程的每一步都可以拆开来讲出大量内容，状态机做得严谨，整个项目的"骨架"就立住了。我见过有人把状态判断放在Controller里，Service纯粹做增删改查，这种写法遇到复杂业务会迅速失控——状态校验这种核心业务规则必须下沉到Service层，Controller只做参数接收和结果返回。
4.3 抢单场景下的数据一致性保证
这应该是整个项目里最值得讲的技术点。两个用户同时点击"接单"，数据库层面如果没有控制，就可能出现一条任务被抢两次的脏数据。解决方案有三种：
方案一：悲观锁（SELECT ... FOR UPDATE）。在查询任务时加上for update，数据库会锁住这一行，直到事务提交后其他事务才能读到。这是最简单的方案，但注意它必须配合事务使用，而且要确保走的是主键或索引查询，否则全表锁。
方案二：乐观锁（版本号）。在task表加version字段，更新时带上版本条件：
UPDATE t_task SET status = 'ACCEPTED', accepter_id = ?, version = version + 1 WHERE id = ? AND status = 'PUBLISHED' AND version = ?;更新返回的行数如果是0，说明任务被别人抢走了，业务层抛出"手慢了"的提示。
方案三：状态条件更新（不需要版本号）。其实上面的SQL已经体现了这个思想——where条件里直接包含status = 'PUBLISHED'，只要数据库保证这条update语句的原子性，就不可能出现两个事务同时把一条记录从状态A改为B的情况（MySQL的当前读是行级锁）。所以严格来说，方案二和方案三的思想是一样的，版本号只是多了一层更精确的控制。
我推荐课程设计用方案三+乐观锁的变体，因为它不依赖额外字段也能保证正确性，实现简单，还能在答辩时把"数据库事务隔离级别""行级锁"这些知识点都讲出来，属于投入产出比最高的方案。
4.4 文件上传、分页查询和服务端参数校验
跑腿任务可能需要用户上传图片作为凭证或者任务描述补充，这就需要SpringMVC的文件上传支持。配好CommonsMultipartResolver之后，Controller里用MultipartFile接收，然后保存到本地磁盘路径，数据库只存访问URL。
文件保存路径有两个注意点：一是不能把文件直接存到项目部署的classes目录，因为重新部署会清空；建议存到服务器的某个固定目录，比如/usr/local/campus-task/uploads/。二是文件名要重写，防止中文乱码和路径穿越攻击，用UUID或时间戳重命名，后缀保持不变。
分页查询我建议用MyBatis的PageHelper插件，一行PageHelper.startPage(pageNum, pageSize)后面跟着查询方法，插件会自动拦截SQL拼接limit。但这里有一个必须记住的坑：PageHelper只对紧接着的下一条查询语句生效，如果你在startPage之后又执行了别的查询，分页就污染到错误的语句上了。多表关联查询时，如果先查询了别的表，这条数据就会错乱甚至报错。
参数校验不要只依赖前端，后端也必须校验。至少要对任务发布里的奖励金额、联系电话、地址这些字段做非空和长度校验。手动if判断就可以，也可以通过JSR303注解@NotNull @Size加上@Valid让Spring帮你校验。我倾向于后者，代码干净，答辩也有讲头。
5. 订单查询的性能优化与安全加固
5.1 高频查询与慢SQL排查
任务列表页可能有大量"待接单"任务展示。如果你不做任何优化，每次都把整张task表查出来再在内存里过滤，数据量大了必然卡死。第一层优化是SQL层面用索引覆盖，第二层是列表页只查询必要的字段，不要select *，而是把大字段detail排除在外。
还有一个容易被忽视的性能杀手，N+1查询问题。比如前端显示任务列表时，需要展示每个任务的发布者昵称和头像。初学者常见的写法是循环里查用户表，10条任务就执行11次查询。正确的做法是一次查询出所有任务后用内联查询直接关联用户表返回用户名，或者查完任务后把publisherId收集起来，用IN查询一次性查出用户信息再在内存里组装。
用MyBatis写这种关联查询可以直接用连表：
<select id="selectTaskList" resultType="map"> SELECT t.id, t.title, t.reward, t.status, u.username AS publisher_name FROM t_task t LEFT JOIN t_user u ON t.publisher_id = u.id WHERE t.status = 'PUBLISHED' ORDER BY t.create_time DESC LIMIT #{offset}, #{pageSize} </select>5.2 SQL注入与XSS防护的最低要求
很多人觉得自己的系统没有安全隐患，这其实是错觉。SSM项目里至少有两个高危点需要认真处理。
SQL注入：MyBatis的#{}是预编译占位符，不会注入；但如果你偷懒写了${}拼接排序字段或者模糊查询，就有注入风险。排序字段这种不能预编译的场景，必须用白名单校验——传入的排序字段名不是预定义的可选值，就拒绝执行。
XSS攻击：用户可以在任务描述里插<script>标签，不做处理的话，其他用户一打开详情页就中招。最低限度的防护是在输出到前端时转义HTML。JSP里用${fn:escapeXml()}函数或者<c:out>标签默认都会转义。如果Controller返回的是JSON，建议在序列化层面统一处理。我见过一个真实的案例：用户在任务标题里写了一句话，包含了支付页面的钓鱼链接，管理员后台打开就中招了，这个教训值得重视。
5.3 事务边界与回滚策略
事务不是随便加个@Transactional就完事了。首先要明确：事务应该加在Service层的public方法上，并且不要在同一个类里调用带事务的方法——Spring的AOP代理在内部方法调用时会失效，因为走的是this调用而不是代理对象，这是一个非常经典的事务失效场景。
其次是事务的回滚规则。默认情况下，@Transactional只在抛出RuntimeException时回滚，受检异常（Exception的子类但不是RuntimeException）不会触发回滚。如果你在Service里try-catch吞掉了异常，那事务就彻底没有回滚了。正确的做法有两种：要么不catch让异常继续抛出，由全局异常处理器统一处理；要么在catch之后手动TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()。
注意：使用Spring的声明式事务时，记得在
spring.xml里开启<tx:annotation-driven/>，并且配置事务管理器指向你的数据源。漏掉这一步，@Transactional注解全部白写。
6. 常见问题与排查技巧实录
6.1 问题速查表
| 现象 | 根本原因 | 排查方法 | 解决方式 |
|---|---|---|---|
| 登录后页面跳转404 | 拦截器放行路径配置错误 | 看控制台是否被preHandle拦截 | 精确配置excludeUrlPatterns |
| JSP页面不显示JSTL标签 | JSTL依赖版本不匹配Tomcat | 查看Tomcat版本和jakarta坐标 | 换用jakarta.servlet.jsp.jstl依赖 |
| 事务不生效 | SpringMVC容器扫描了service层 | 检查两个配置文件的扫描范围 | SpringMVC只扫描controller |
| 抢单出现重复接单 | 缺少状态条件更新或锁 | 查看SQL日志里update语句 | 加status条件约束或者version乐观锁 |
| 上传文件乱码 | Tomcat的URI编码不是UTF-8 | 检查请求参数编码 | 配置CharacterEncodingFilter并设置URIEncoding |
| 分页插件导致查错数据 | PageHelper被别的查询"污染" | 查看当前线程的SQL日志 | startPage紧挨真正要分页的查询 |
| 金额计算错误 | 用了double而不是decimal | 打印数值观察精度 | 数据库与Java实体都用BigDecimal |
| 本地图片无法访问 | 静态资源被DispatcherServlet拦截 | 请求路径返回404 | 配置资源映射或放行上传目录 |
6.2 几个我印象最深的坑
第一个坑发生在编码上。学生项目跑到生产环境（或者换一台电脑部署）时突然中文全变成"???", 十有八九是MySQL连接URL里没有配置characterEncoding=utf8。只要在jdbc.properties里加上jdbc:mysql://localhost:3306/campus?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai就能解决。顺手把serverTimezone也配了，不然新版驱动连接会报时区错误。
第二个坑是文件上传大小限制。SpringMVC默认支持的文件大小其实不小，但Tomcat之间还有一层maxPostSize限制。如果你上传超过2MB的图片一直报404或者返回一个奇怪的错误页，先检查Tomcat的server.xml里<Connector port="8080" maxPostSize="-1"/>，把值调大或者设为-1代表不限制。
第三个坑是关于MyBatis的驼峰映射。数据库字段是create_time，实体类是createTime，如果你没有在mybatis-config.xml里开启mapUnderscoreToCamelCase，所有时间字段查询出来都是null。这个配置在开发初期就要加上，不然后面排查起来会怀疑人生：
<settings> <setting name="mapUnderscoreToCamelCase" value="true"/> <setting name="logImpl" value="SLF4J"/> </settings>第四个坑是AJAX请求返回403/404而不是JSON。如果你用到了类似Apache Shiro或者Spring Security做权限控制，未认证的AJAX请求往往被拦截后返回一个HTML错误页，前端fetch处理时会各种报错。核心思路就是上面提过的——拦截器里判断请求头，是Ajax就返回标准JSON错误体，而不是重定向到login页面。
6.3 答辩/汇报时的加分技巧
如果你还需要给老师演示，或者想把项目写进简历，有几个细节可以帮你拉开差距：
- 在首页展示任务时加上"剩余时间倒计时"，体现你对时间字段的处理能力。
- 数据看板用ECharts展示每天的任务发布量趋势图和任务类型占比饼图，只要是后端返回JSON、前端用可视化图表库渲染，技术含量立马提升一个量级。
- 在"接单排行"页面展示接单达人的完成率和好评率排名，这一点侧面印证了你的SQL聚合查询和表设计水平。
- 管理员后台加一个"任务状态异常看板"——超时未接单的任务自动置为超时并通知发布者，这个定时任务的实现（Spring的@Scheduled）是很好的加分项。
这些不是花哨功能，每一个都在真实场景中有明确的业务意义。答辩老师问起来你能讲清楚"为什么"，比做十个无意义的页面强得多。
写项目最忌讳的就是上来就敲代码。我在帮学生理思路时大多时候的流程是：先拿一张纸画出角色和订单流转，再画数据表字段，确定状态枚举和关键SQL，最后才动手搭建工程。只要你把状态机理清楚、把并发抢单的一致性想明白、把事务和拦截器这种基础设施验证透彻，SSM跑腿平台这个项目的骨架就已经立住了，剩下的一切都是往里面填血肉。
如果你正在做类似的选题，我建议你直接打开数据库设计工具，先建t_user表，再建t_task表，写一条带status条件更新的update语句试试能否正确返回受影响行数。这一步跑通了，你就已经领先了百分之八十的同学。
