1. 这个项目到底解决了什么问题先说个场景大学校园里下午四点半食堂还没开饭但你已经饿得不行想吃食堂二楼的黄焖鸡米饭可你和宿舍距离食堂走路十五分钟加上排队来回起码半小时。这时候如果有个东西能让你花两块钱喊个没课的同学帮你跑腿买饭送到宿舍楼下——你会用吗绝大多数学生都会用。这就是校园跑腿任务接单平台的商业逻辑。市面上很多外卖平台覆盖不到校园内部的“最后一公里”外卖骑手进不了宿舍区食堂取餐高峰排队时间长快递代取、文件打印、超市代买这类零散需求又太小太杂大平台根本看不上。这些需求恰恰是校园里最真实、最高频的痛点。本文要说的是一个基于Java和SSM框架Spring SpringMVC MyBatis实现的校园跑腿任务接单服务平台。整个系统的功能定位很简单用户学生发布跑腿任务指定报酬和时限另一个用户跑腿者浏览任务并接单完成任务后通过平台确认完成交易闭环。平台侧提供用户注册登录、任务审核、订单追踪、评价体系等基础支撑。这个项目适合谁来参考两种人最受益Java后端学习者尤其是正在做课程设计、毕业设计需要一个完整SSM项目的开发者。这个系统麻雀虽小五脏俱全注册登录、角色权限、任务流转、订单状态机、搜索筛选、统计报表该有的都有用来练手或答辩都拿得出手。有一定Spring基础、想理解“多人协作业务”怎么落地的人。跑腿平台表面上是个简单C2C交易系统实际上涉及用户角色划分、任务状态流转、并发抢单、交易安全校验等一系列问题是一块很好的“中型业务”练手田。我对这个项目的评价是技术上不炫技但业务逻辑足够典型。它不是一个“能跑就行”的CRUD示例而是一个需要你认真设计数据表关系、处理状态流转、考虑异常情况的真实业务系统。Lofter局部小规模跑腿业务里的每一条细节比如“发单人能不能撤单”“跑腿者能不能转单”“被放了鸽子怎么处理”都是在写代码之前需要想清楚的产品问题。2. 核心业务链路与数据模型设计2.1 从需求到表结构先想清楚三种角色的边界校园跑腿平台的核心参与方就三类发单人需求方、跑腿者服务方、平台管理员审核与仲裁方。但有一个细节很值得注意同一个用户可以既发单又接单。比如上午帮别人取了个快递下午自己懒得动又发了个代买咖啡的任务。这种“身份动态切换”在数据模型上意味着用户表不需要再额外区分角色表而是通过“用户当前发单和接单状态”动态判断。这一点是很多初学者会搞错的地方。有人一上来就搞 user_role 关联表把用户硬性分成“顾客”和“骑手”两张表结果需求一变就傻眼了。实际上这属于C2C平台很典型的设计思路平台不设定身份只有行为。你发了任务你就是当前的发单人你接了任务你就是当前跑腿者。基于这个逻辑我在数据建模时使用了以下核心表表名核心字段作用userid、username、password、phone、student_id、avatar、credit_score用户基础信息信用分用于后续派单优先级taskid、publisher_id、category、title、description、reward、deadline、status、pickup_location、deliver_location任务主表状态字段是整个流程的“主动脉”task_orderid、task_id、taker_id、accept_time、finish_time、status订单表记录谁接了单、何时接单、何时完成commentid、order_id、rater_id、ratee_id、content、score、create_time评价表区分“对发单人的评价”和“对跑腿者的评价”admin_logid、admin_id、operation、target_id、create_time后台操作日志用于审核和仲裁留痕如果你去看很多开源的校园跑腿项目会发现他们把 task_order 和 task 合并成一张表。我不建议这么做。原因很直白一个任务发布之后可能被接单、被转单、被取消也可能在无人接单时反复编辑重新上架。任务Task描述的是“需求本身”订单Order描述的是“一次成交关系”。如果合并在一起任务每次被接单就要改写状态前面接单人留下的记录全被覆盖后续审计、结算、对账都无从谈起。把任务和订单拆开之后还有一个额外好处一个任务可以支持“多次接单尝试”的扩展。虽然当前版本是“一人接单锁定”但表结构上保留了未来做“多人竞标”的可能。给后面做功能迭代留了余地这在课程设计答辩里会是一个很好的加分点。2.2 任务状态机整个平台的“心跳”校园跑腿平台能不能顺畅运转全看任务状态流转做得稳不稳。我用一张图概括核心状态节点这里没有用时序图纯文字状态流转说明初始等待接单→ 已接单进行中→ 待确认跑腿者标记完成→ 已完成发单人确认→ 已评价除了这条主链路还有三条分支已取消发单人在未接单状态下取消或管理员审核不通过强制取消申诉仲裁中订单完成或取消后任何一方对结果不满意可发起申诉超时关闭超过任务截止时间仍未有人接单系统自动关闭。这里特别强调“发单人确认收货”这一步。很多校园跑腿项目为了省事跑腿者一标记“完成”系统就直接把状态改成“已完成”报酬立刻入账。这个设计在真实场景里会出大问题跑腿者拍了一张照片说“放楼下了”但饭实际被别人拿走了怎么办跑腿者说“送到了”发单人压根没收到货怎么办所以在我的项目里状态机必须经过“待确认”这个中间态。跑腿者提交完成证据可以是照片或备注文字发单人确认后任务才真正闭环。这和我们网购的“确认收货”逻辑一模一样。它加了一次人工确认但把交易纠纷减少了一大半。状态机的实现我放在一个独立的TaskStatusManager里所有状态转移必须走这个类。不做“状态流表”把每一步流转记录成独立行的原因是SSM项目普遍追求性价比一个状态字段加严格的流转校验已经够用。减少冗余也不至于在答辩时被问“为什么这个状态流转表没有索引”。这类“够用且合理”的设计判断其实比堆技术概念更让面试官认可。2.3 并发抢单一个容易暴露基本功的细节校园跑腿任务发布后可能同时有三五个人盯着刷新点“抢单”。如果直接在 service 层写Task task taskMapper.selectById(taskId); if (task.getStatus() 0) { task.setStatus(1); taskMapper.updateById(task); }并发一上来两个人都查到了 status 0然后都去 update最后两个人都会“接单成功”完蛋。这里的最优解是在数据库层面做乐观锁或行锁。我的做法是直接在更新语句里带条件int rows taskMapper.acceptTask(taskId, userId, oldStatus); // SQL: UPDATE task SET status 1, taker_id #{userId} // WHERE id #{taskId} AND status #{oldStatus}关键点用rows受影响行数判断是否抢单成功。rows 1说明更新成功自己拿到了rows 0说明别人抢先一步。这种“状态条件更新”在并发业务里是基本功面试八股里叫“乐观锁”但真正动手写过的人比例真不高。还有一点顺带提一句创建任务时报酬、截止时间、配送地址这些字段要做一个同步的冗余快照到订单表。不然用户把任务报酬从 3 元改成 5 元订单表里还是 3 元结算就会对不上。这是典型的数据一致性血泪教训我在项目里踩过一次之后所有涉及金额的字段都不再“连表实时查询”而是“创建时写死一份副本”。3. SSM框架落地Spring MVC分层搭建的完整链路3.1 分层架构的取舍为什么Controller里不能堆业务代码SSM项目最容易写崩的地方就是 Controller 越写越肥一个方法几百行。我见过太多课程设计代码Controller 直接调用 mapperSQL 拼在业务方法里换一个条件就要改 Java 代码。这种代码不是不能跑而是改不动、没法测、答辩时也讲不清。我这个项目坚持了四层结构Controller参数接收、权限校验、结果封装 ↓ Service业务编排、事务控制、状态流转 ↓ MapperSQL与Java映射 ↓ MySQL数据存储Controller 层只做三件事接参数、调 Service、封装返回体。业务规则一律下沉到 Service。这种分层最大的好处是可测试性好。我写了一个模拟抢单的并发测试直接注入 Service 调acceptTask()不比启动 Tomcat 再模拟 HTTP 请求省时间。对于课程设计答辩你可以随手写一个 JUnit 测试证明“抢单并发安全”比口头说“我用了乐观锁”有说服力得多。3.2 SpringMVC的参数校验用注解替代手写 if-else任务发布表单有七八个字段如果每个字段都手写if (reward null || reward 0) { return Result.error(报酬必须大于0); }代码会又臭又长还容易漏校验。我在项目中引入 JSR-303 的Validated注解做参数校验Task实体类上直接声明约束NotBlank(message 任务标题不能为空) Size(max 30, message 任务标题过长) private String title; NotNull(message 报酬不能为空) DecimalMin(value 0.01, message 报酬必须大于0元) private BigDecimal reward; Future(message 截止时间必须晚于当前) private LocalDateTime deadline;Controller 里只需要写PostMapping(/publish) public Result publish(RequestBody Validated TaskDTO taskDTO) { taskService.publish(taskDTO); return Result.success(); }效果是直观的一个注解代替五行 if-else而且校验规则和实体绑定改动一处全局生效。单个参数比如查询时的页码直接用RequestParam(required false, defaultValue 1)这类声明式写法也少写好多 null 判断。这种“约束内聚”的习惯是 Java Web 项目从“能跑”走向“规范”的第一步。3.3 MyBatis的动态SQL列表页搜索的灵魂校园跑腿首页的任务列表看起来简单实际要支持的条件很多按分类筛选、按关键词模糊搜索、按报酬排序、按发布时间倒序、按状态过滤、分页。如果用 Java 代码拼 SQLif-else 写到你怀疑人生。MyBatis 的whereif动态标签就是为这个场景设计的。我写了一个典型的动态查询select idqueryTaskList resultTypecom.demo.entity.Task SELECT * FROM task where if testcategory ! null AND category #{category} /if if testkeyword ! null and keyword ! AND (title LIKE CONCAT(%, #{keyword}, %) OR description LIKE CONCAT(%, #{keyword}, %)) /if if teststatus ! null AND status #{status} /if /where ORDER BY choose when testsortBy timecreate_time DESC/when when testsortBy rewardreward DESC/when otherwiseid DESC/otherwise /choose /select顺带提醒一个坑LIKE CONCAT(%, #{keyword}, %)不要写成LIKE %${keyword}%。${}是字符串拼接有 SQL 注入风险#{}是预处理参数安全。把“搜索跑腿任务”拆成第一个版本的人几乎都会踩一次这个坑包括我。3.4 事务边界哪里该加 Transactional任务发布、接单、确认完成这三个核心操作动作本身看着不复杂但都涉及多次数据库写入。以“确认完成”为例需要做的事包括更新 task 状态为“已完成”更新 task_order 状态为“已完成”给跑腿者账户增加本次报酬给发单人扣除本次报酬余额。这四件事任何一件失败都会导致数据不一致比如跑腿者收到钱但任务还挂在“进行中”。解决办法就是给方法加Transactional让四个操作要么一起成功要么全部回滚。Transactional(rollbackFor Exception.class) public void confirmFinish(Long orderId, Long userId) { TaskOrder order orderMapper.selectById(orderId); // 校验当前用户是发单人 // 更新订单状态 // 更新任务状态 // 更新双方账户余额 }这里有三个细节容易被忽略rollbackFor一定要写默认值只回滚 RuntimeException检查异常不回滚。我见过有人自定义了一个BizException extends Exception结果方法里抛了异常数据依然提交了查了半天才发现。事务不要跨 Service。一个Transactional方法里只调用当前类的私有方法或 Mapper不要边调 A Service 边调 B Service两个事务互相嵌套后期排查问题想哭。不要在事务里做远程调用或休眠等待。比如事务里上传图片到第三方对象存储OSS如果 OSS 挂了几秒钟事务一直不提交连接池瞬间就会被占满。4. 平台周边的关键模块评价、信用与申诉仲裁4.1 双向评价谁评谁评什么跑腿任务完成后的评价体系我一开始想得很简单订单完成后双方各给一个评分和文字评价完事。但细想发现一个问题——跑腿者给发单人打分和发单人给跑腿者打分评的内容完全不一样。发单人评价跑腿者关心的是是否按时送达、物品是否完整、服务态度如何。跑腿者评价发单人关心的是是否按时确认收货、地点描述是否清晰、有没有临时加价。评价内涵不同如果共用一组“好评/差评”标签后期分析用户质量时数据基本没用。所以我在 comment 表上做了一个字段comment_type区分为TO_TAKER和TO_PUBLISHER。前端展示评价时按类型用不同的标签模板。这个设计的价值在答辩时特别好讲不需要啰嗦一张表就说明你对业务有思考。4.2 信用分计算别用复杂的权重公式很多跑腿平台喜欢搞“信用分 加权评分 成单率 × 0.3 响应速度 × 0.2 ...”之类的复杂公式。听起来高大上但实际在校园场景里落不了地。数据量不大、用户行为不稳定复杂的公式只会让你没法解释“为什么我的分数突然降了”。我采用的是最简单也最稳健的方案基础操作加分 违规扣分。行为信用分变化成功完成一单1收到好评2被差评-3超时未完成且未提前说明-5恶意取消-5被管理员仲裁判定违规-10信用分下限是 0不发负分。信用分低于 60 分的用户发任务必须全额预付报酬接单优先级自动排到最低。这个设计虽然朴素但胜在规则透明、可解释性强。用户知道自己做了哪件事导致分数下降比面对一个黑箱权重公式更容易接受。校园场景里用户申诉频繁规则可解释才是第一位的。4.3 申诉仲裁流程管理员怎么介入既然有了信用分和评价就一定会有争议“我明明送到了他说没收到”“他私自改了取货时间害我白跑一趟”。没有仲裁机制的跑腿平台是走不远的。我的实现方式如下用户对某笔订单发起申诉上传证据聊天截图、照片该订单状态变为“申诉仲裁中”双方均无法再操作管理员在后台查看订单完整轨迹、聊天记录、上传证据管理员判定责任方选择“维持原状”“退款”“赔偿跑腿者”等操作。整个仲裁过程通过 admin_log 留痕。仲裁处理的硬性规则是证据优先。如果没有关键证据偏向于“按流程无过错方”判定而不是各打五十大板。因为各打五十大板看似公平实际会伤害认真履约用户的积极性做跑腿这种低客单价服务保护履约方利益非常重要。5. 从JSP到接口设计前端交互的关键拆解5.1 页面结构和用户路径这个项目的前端主体是 JSP Bootstrap服务端渲染为主。用户全局登录后会进入“首页”看到所有可接单的任务列表点击任务详情可以看到完整的发布信息和“我要接单”按钮发布者点击“我发布的”能看到自己的任务实时状态和进度。用户核心操作路径发单人发布任务 → 等待接单 → 收到通知 → 跟踪进度 → 确认收货 → 评价跑腿者浏览任务 → 抢单 → 开始执行 → 提交完成证据 → 收到报酬 → 评价。全程没有复杂的多级菜单每个角色首页呈现的内容完全不一样。跑腿者的首页顶部是“当前接单中的任务”发单人的首页顶部是“等待确认的任务”。这种“按角色切首页”的设计在校园这种轻度用户场景里比做一堆功能菜单有效得多。用户不需要学习进来就知道下一步该干什么。5.2 接口返回体统一设计SSM项目最容易出现的另一个问题是每个接口返回格式五花八门。有的返回 JSON有的直接返回字符串有的直接把实体类序列化出去前端拿到数据还要猜字段。我统一封装了一个ResultT返回体所有接口一律按这个格式返回public class ResultT { private Integer code; // 200成功400业务错误401未登录500服务异常 private String msg; private T data; public static T ResultT success(T data) { // ... } public static T ResultT error(String msg) { // ... } }统一返回体配合前端$.ajax的全局拦截前端代码里不再需要写 per-接口 的散乱判断。所有人只需要看codecode 200就把 data 渲染到页面否则弹 msg。别小看这个习惯统一契约是多人协作项目能推进的前提。哪怕你是一个人写前后端统一了返回体后续想加页面、加接口也顺畅得多。5.3 文件上传的坑图片证明怎么处理跑腿者完成订单时可能需要上传“已送达”的图片证明比如放在宿舍柜子里的照片。SSM项目上传文件走得最多的方案还是 MultipartFile存到本地磁盘再把图片 URL 存到数据库。这里有几个真实踩过的坑提醒一下绝对路径和相对路径要分开配。图片存本地时如果存的是绝对路径/root/upload/xxx.jpg前端拿到这个 URL 根本无法访问。我现在是磁盘上存文件数据库里只记/upload/20240503/xxx.jpg这种相对路径再由项目的前缀统一拼成完整 URL。文件类型要白名单校验。不要只看文件扩展名要看 MultipartFile 的类型字段后端再做一层文件头校验比如 JPEG 文件头是0xFFD8FF。这个防护能滤掉大部分伪造扩展名的恶意文件。上传目录要按日期分目录避免一年后一个文件目录几十万个文件。否则列表遍历、清理都极度痛苦。6. 部署上线与性能优化一些值得记录的经验6.1 从本地到服务器最小的上线方案这个项目部署成本很低。我当时用的是阿里云也可以换成任何云服务器的 2C4G 起步档装好 JDK 8、Tomcat 9、MySQL 8再配一个 Nginx 反代 Java 接口和静态资源流程就能跑通。上线流程大概如下用 Maven 打包成 WAR 包直接扔到 Tomcat 的 webapps 目录服务器上用nohup java -jar启动如果你改造为 Spring Boot或依赖 Tomcat 自动热部署MySQL 建库建表导入初始化数据确保utf8mb4字符集Nginx 配置/api/前缀转发到后端端口静态资源直接交给 Nginx启用 HTTPS解决浏览器混合内容拦截问题。一个经验不要把数据库用户名密码明文写在配置文件里更不要把配置提交到公开仓库。用环境变量或者在启动脚本中动态注入哪怕只是课程设计也应该培养这个习惯。6.2 性能优化哪些改动成本低收益大校园跑腿项目的用户量级通常不会太大初期不需要上 Redis 缓存、MQ 消息队列等重型组件。真正值得做的低成本优化有三个第一分页必须加索引。ORDER BY create_time DESC LIMIT 20这种查询如果没有给create_time建索引数据库会把表里所有任务全排一遍再取 20 条。任务表涨到 3 万条后这个操作就会变慢。第二任务列表的查询字段要不要全查默认SELECT *会把 description 这种大字段也读出来列表页根本不需要。改成只查 title、reward、status、create_time 这些列表字段响应体量和数据库 IO 都会明显下降。第三数据量大的评论接口可以做一次冗余统计。每个用户的信用分、完成单数、好评数与其每次实时聚合不如在用户表上冗余几个统计字段评价写入时同步更新。这在数据一致性要求没那么高的场景下是非常实用的“降本”办法。7. 安全加固登录态、越权与口令安全7.1 登录态管理Session还是TokenSSM 传统项目里很多人默认用 Session 存登录状态JSP 页面配合c:if test${sessionScope.user ! null}判断是否显示“发布任务”按钮。这在单体应用里是够用的浏览器帮你管 Cookie服务端存 Session没什么大问题。但有一个隐患很多人忽略Session 默认超时时间要显式配置。Tomcat 默认会话超时是 30 分钟如果用户正在编辑任务详情或者犹豫要不要接单Session 突然失效再提交数据就会因为“未登录”被拒——学生用户会觉得“这平台也太难用了”。我后来把 Session 超时调成 2 小时体验才正常。如果项目想脱离 JSP、做前后端分离版本建议切到 Token 方案比如 JWT。登录成功签发 Token前端每次请求带在 Header 里后端拦截器统一校验。这种方案对移动端小程序更友好校园跑腿场景最终基本都会向小程序靠拢。7.2 越权问题为什么必须有权限校验这是整个安全环节我最想强调的一点。很多课程设计项目接口是裸奔的。登录接口随意、发任务接口随意、确认订单接口随意。导致的问题是只要知道接口地址任意用户都能操作别人的订单。我在拦截器里加了基于 Session 的登录校验public class LoginInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { if (request.getSession().getAttribute(userId) null) { // 前端跳转到登录页 response.setStatus(HttpServletResponse.SC_UNAUTHORIZED); return false; } return true; } }配置到 SpringMVC 的拦截器注册里registry.addInterceptor(new LoginInterceptor()) .addPathPatterns(/api/**) .excludePathPatterns(/api/user/login, /api/user/register, /api/task/list, /api/task/detail);除了“有没有登录”还要管“有没有权限操作这个订单”。任务确认完成时必须校验当前操作人就是该订单的发单人。我的实现是在 Service 层查一次订单归属后立刻做状态判断if (!order.getPublisherId().equals(currentUserId)) { throw new BizException(您不是该订单的发单人无法执行此操作); }“接口可用 权限正确 归属校验”三层都做全了才能避免最尴尬的答辩场景老师随手改了个 userId 参数就把别人的订单给确认了。7.3 口令安全MD5直接存密码是劝退级操作这个问题在 Java 项目里太常见了。MD5 加密是单向散列但不是口令存储的安全方案它速度太快GPU 算力可以轻松暴力破解更不用说还有彩虹表。我的做法是使用 BCryptString encodedPwd BCrypt.hashpw(rawPassword, BCrypt.gensalt());BCrypt 内部自带随机盐相同的密码每次生成的哈希都不同而且计算慢能显著提升暴力破解成本。Spring Security 的BCryptPasswordEncoder也可以直接复用不用额外引包。这个点不多但写进项目简介里懂行的面试官会默默给你加分。8. 实际测试中容易暴露的问题与修复记录8.1 并发测试模拟三个用户同时抢一个任务我把“并发抢单”的测试放在项目里用 JUnit 模拟 3 个线程同时调用acceptTask()最终断言只有 1 个成功另外 2 个失败。第一次跑这个测试时我直接看到失败结果原因就是上面说的“先查再改”的并发窗口问题。改成“条件更新”后测试稳定通过。这个测试用例保留在工程里既是功能保障也是课程设计里能直观展示的一个“技术点”。8.2 时间问题前端传的截止时间总是相差8小时任务发布表单里用户选择“截止时间今天 18:00”前端传过来到后端成了 10:00。排查后发现问题出在 JSON 时间格式上。JSP 面页用$.ajax传 JSON各浏览器默认走 UTC 时间后端用RequestBody接 LocalDateTime 时没有指定timezoneJackson 解析时就用 JVM 默认时区做偏移。解决方案是双向统一Jackson 配置设置时间格式和时区 ObjectMapper setDateFormat(yyyy-MM-dd HH:mm:ss) setTimeZone(TimeZone.getTimeZone(GMT8))同时前端提交前用dayjs或原生Date对象转成yyyy-MM-dd HH:mm:ss字符串前后端都不再解析时区。这种“前后端统一字符串格式不依赖隐式时区转换”的思路比追着零时区问题到处打补丁要省心得多。8.3 图片跨域和防盗链一个容易被忽略的坑如果图片服务器和页面不同域页面里img srchttp://xxx/upload/123.jpg被浏览器拦截主要就是防盗链问题。Nginx 上加Referer校验可以解决。不过校园网环境有时会屏蔽外部 Referer所以“同源部署 相对路径”在校园场景依然是省心方案图片接口和页面走同一个域名不存在跨域问题。8.4 日志排查接口报错不要只打印堆栈开发过程中最痛苦的是接口报错控制台打出一堆 stacktrace但没人知道用户当时做了什么操作。我后来给项目写了一个OperationLogAspect基于 Spring AOP 对 Service 层的关键方法做日志切面Around(annotation(OperationLog)) public Object log(ProceedingJoinPoint pjp) throws Throwable { long start System.currentTimeMillis(); Object result pjp.proceed(); logger.info(调用方法: {}, 参数: {}, 耗时: {}ms, pjp.getSignature(), args, cost); return result; }有了这层操作日志线上出问题后能根据“哪个人在什么时间做了什么操作”回溯问题链。很多人都说课程设计不用生产级日志但我自己的体会是哪怕项目很小把关键写操作打上日志测试和演示时的debug成本能下降一个数量级。这个方面值得尽早投入不要等出了问题才想到补日志。9. 从SSM到Spring Boot这个项目的演进方向9.1 SSM基础扎实了再谈“去XML化”现在的 Java 后端新项目已经很少从零搭 SSM 的 XML 环境了大多直接上 Spring Boot。但我始终觉得用 SSM 做一次完整项目对理解 Spring 的底层装配逻辑非常有价值——因为你必须自己配数据源、事务管理器、Mapper 扫描路径你才知道 Spring Boot 的“自动配置”到底帮你省了什么。SSM 项目改成 Spring Boot 并不麻烦核心的变化其实只有几点配置文件换成application.yml数据源、端口、时区统一声明不再需要spring-dao.xml三个分片MyBatis 用mybatis-spring-boot-starter引入Mapper 扫描用MapperScan注解原来用 XML 定义的 Bean改为注解或 JavaConfigConfigurationBean拦截器、AOP、文件上传的配置位置从 XML 移到 Java 配置类里。改完之后代码逻辑基本不用动Service、Mapper 那层完全保留只是“装配方式”从 XML 变成注解。这个迁移过程本身就是很好的学习过程讲清楚可以做一期非常好的博客补充。9.2 从单机到分布式校园跑腿什么时候才需要微服务很多初学者喜欢一上来就拆微服务用户服务、订单服务、支付服务、通知服务……看起来架构很漂亮但这种复杂度对校园跑腿项目是纯粹的性能浪费。两台服务器加一个数据库就能跑得很好搞微服务反而引入服务发现、配置中心、链路追踪一大堆运维负担。我认为合理的演进路径是SSM/Spring Boot 单机起步——用户量增长后加 Redis 缓存热点数据——加MQ削峰处理抢单——订单模块按需独立拆分。每一步演进都有明确的数据驱动力不是因为“大家都在用”。能在答辩现场说清楚“为什么不拆微服务”和“什么时候才需要拆”比列一堆技术名词更能体现架构思维。9.3 前端从JSP到小程序校园跑腿的最终形态一定是微信小程序或者公众号H5。学生手机上直接点小程序就能发单、接单、收通知比打开浏览器输网址再登录流畅太多。如果你要把这个项目做深建议把 JSP 页面逐步抽离成 Vue/小程序前端Java 后端只提供 JSON API。那时需要统一设计的内容包括登录态建议换 JWT、接口版本号、统一异常体、文件上传直传 OSS对象存储等。后台管理端如果不想写用现成的若依RuoYi这类脚手架也能改造成自己的运营后台速度很快。但工程的骨架——任务状态机、订单拆分、信用分体系——依然是这个 SSM 版本里沉淀下来的东西不会因为换前端就推翻重来。10. 最后说几句实操心得这个项目从头到尾完整做一遍我个人的体会是校园跑腿业务看着简单真正把状态流转、订单拆表、并发安全、权限校验这些细节都理顺是能把Java后端基础能力扎扎实实梳理一遍的。有几个最想告诉你的关键点状态机是灵魂。任务状态流转能不能严谨决定平台会不会出各种“卡死”的莫名其妙订单。并发抢单用条件更新解决不要靠锁表。锁表简单但性能差而且很容易因为事务没提交导致死锁。条件更新是更优雅的方案。订单表和任务表必须分开。哪怕当前功能用不到订单表的所有字段分开也是为后续审计、仲裁、结算铺路。权限校验是三层登录校验、权限校验、归属校验。漏任意一层用户都能在系统里制造出意想不到的破坏。日志从第一天就要打。不要等出了问题再补那种时候你连补日志的机会都没有。如果你顺着这条思路把一个完整的校园跑腿平台做出来你会发现它对标的不只是“SSM能做什么”而是“一个真实业务从需求到落地的完整分析方法”。希望对正在做类似项目的朋友有帮助。