1. 校园跑腿的困局：为什么我最终做了这套爱心互助系统
上半年在学校信息中心帮忙，接触了不少同学关于校园跑腿的真实诉求。代拿快递、代买食堂饭、图书馆占座、临时帮忙打印资料，每天这类需求在微信群和 QQ 群里少说有几百条。但群里的接单模式非常混乱：需求发出去没人响应，价格不透明，跑腿的人拿了钱不办事也没人管，甚至出现过个别同学借着“帮忙取快递”的名义骗走贵重物品的情况。老师那边也头疼，群里刷屏太快，想要追溯都找不到记录。
正是在这种背景下，我决定用 Spring Boot 3 + Vue 3 + 微信小程序这套组合，做一套高校跑腿接单爱心互助管理系统。系统的核心定位不是简单做一个“校园外卖配送平台”，而是强调“互助”属性——学生之间可以发布跑腿需求，其他同学可以凭“爱心值”或小额酬劳接单，同时系统提供信用评价、订单追踪、异常申诉、管理员兜底等机制，让互帮互助这件事变得有序、可追溯、可持续。
这套系统适合谁参考？如果你是在校学生、正在做毕业设计、或者想给学校信息中心做一个轻量级校园服务工具，那这篇文章里从数据库设计到微信登录、从订单状态机到管理后台权限控制的完整链路，都可以直接参考。我不打算只讲代码，更想把选型理由、踩过的坑、真实校园场景里容易忽略的设计细节一并讲清楚。
2. 技术选型背后的取舍逻辑
2.1 Spring Boot 3 到底值不值得用
先说一下后端。Spring Boot 3 相比 2.x 最大的变化是底层从 Java EE 迁移到了 Jakarta EE 9+，javax 包名全部变成了 jakarta。这个变化意味着以前很多老项目的代码直接搬过来会编译报错，需要手动改 import。另一个明显的升级是 Spring Security 6 全面支持了 OAuth 2.1 和更严格的默认安全配置，传统基于 WebSecurityConfigurerAdapter 的写法被废弃，现在要求用 SecurityFilterChain 的 Bean 方式配置。我在迁移过程中就遇到了不少旧教程代码直接跑不起来的状况。
那为什么还选 Spring Boot 3？两个原因：一是这已经是当前 Spring 社区的主线版本，新项目没必要逆着技术趋势走；二是它的启动性能、GraalVM 原生镜像支持、对容器化和云原生部署的友好程度，都让后续维护省心很多。只要注意两点：JDK 必须 17+，引入依赖时尽量用 Spring Initializr 生成的 BOM 版本，避免手动管理版本号。
2.2 前端为什么拆成两个端：Vue 3 管理后台 + 原生微信小程序
这套系统天然有三个用户入口：学生发布需求（小程序）、跑腿者接单（小程序）、管理员处理订单与用户（后台网页）。小程序端没有选择 uni-app 或 Taro 跨端框架，而是直接用了微信原生开发。原因是这个场景的页面复杂度不高，主要以列表、表单、地图为主，原生小程序的性能表现和调试体验反而更好。管理后台选了 Vue 3 + Vite + Element Plus，这是目前搭建后台管理系统效率最高的组合之一。Vite 的开发服务器启动速度快到基本无感，配合<script setup>语法，组件代码量比 Vue 2 时代少了一大截。
2.3 系统整体交互流程
整个系统从用户视角看是这样的：学生打开小程序，微信授权登录后，可以发布跑腿需求（包括取件地址、送达地址、期望时间、酬劳或爱心值）。需求进入待接单池后，其他同学浏览订单列表，觉得合适就可以抢单。接单后进入配送中状态，跑腿者送达后拍照确认，需求方确认收货并给评价。管理员在 Vue 3 后台可以看到全量订单、用户信用数据、异常申诉记录，也可以手动介入处理纠纷。
从技术视角看交互流程则涉及三端联动：小程序通过 HTTPS 调用后端 REST API，后端连接 MySQL 存储业务数据、Redis 缓存验证码和 Token，管理后台通过另一套 API 前缀调用同样的后端服务。权限上小程序用户只能操作自己的数据，管理端走独立权限体系。
3. 数据库设计：跑腿业务的核心表结构拆解
数据库设计决定整个系统能不能撑住真实业务。我按照“用户体系、订单体系、爱心值体系、评价申诉体系”四个模块来建表。
3.1 用户表：openid 关联与角色边界
用户表是整个系统的基础。微信小程序登录后拿到 openid，这是用户在微信生态里的唯一标识，存储时设置了唯一索引。用户角色用 role 字段区分 student（普通学生）和 admin（管理员），跑腿者不需要单独建表，接单行为用 is_runner 标志位表示。信用分 credit_score 初始值是 100，每次被投诉或超时未接单会扣分；爱心值 love_points 则用于体现“互助”属性，每次帮助他人完成订单可以获得对应爱心值。
CREATE TABLE `user` ( `id` bigint NOT NULL AUTO_INCREMENT, `openid` varchar(64) NOT NULL COMMENT '微信openid', `nickname` varchar(64) DEFAULT NULL, `avatar_url` varchar(512) DEFAULT NULL, `student_no` varchar(32) DEFAULT NULL COMMENT '学号', `phone` varchar(20) DEFAULT NULL, `role` tinyint NOT NULL DEFAULT 0 COMMENT '0-学生 1-管理员', `is_runner` tinyint NOT NULL DEFAULT 0 COMMENT '是否允许接单', `credit_score` int NOT NULL DEFAULT 100, `love_points` int NOT NULL DEFAULT 0, `status` tinyint NOT NULL DEFAULT 1 COMMENT '1-正常 0-禁用', `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_openid` (`openid`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;设计时有个容易踩坑的点：是否要把“跑腿者”做成独立角色表？我在第一版确实这么做了，结果发现一个学生今天可能是需求方、明天可能就变成接单者，角色并不是固定的。后来把 is_runner 做成布尔字段，接单资格由信用分和实名认证状态动态决定，灵活很多。
3.2 订单表：状态机是跑腿系统的灵魂
订单表的设计核心是状态字段。我定义了完整的订单状态流：0-待接单、1-已接单、2-配送中、3-待确认、4-已完成、5-已取消、6-申诉中。每个状态之间的流转有严格限制，比如取消操作只允许在待接单或已接单但配送开始前执行。这张表还需要冗余存储发布者的昵称、头像，避免每次查询订单列表都 JOIN 用户表，这是典型的空间换时间策略。
CREATE TABLE `orders` ( `id` bigint NOT NULL AUTO_INCREMENT, `order_no` varchar(32) NOT NULL COMMENT '订单号', `publisher_id` bigint NOT NULL COMMENT '发布者', `runner_id` bigint DEFAULT NULL COMMENT '接单者', `title` varchar(100) NOT NULL, `description` text, `item_type` tinyint DEFAULT 0 COMMENT '物品类型', `pickup_address` varchar(255) NOT NULL, `delivery_address` varchar(255) NOT NULL, `reward_type` tinyint NOT NULL DEFAULT 0 COMMENT '0-爱心值 1-酬劳(元)', `reward_value` decimal(10,2) NOT NULL DEFAULT 0, `expect_time` datetime DEFAULT NULL, `status` tinyint NOT NULL DEFAULT 0 COMMENT '订单状态', `finish_time` datetime DEFAULT NULL, `create_by` bigint DEFAULT NULL, `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, `update_time` datetime DEFAULT NULL ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_publisher` (`publisher_id`), KEY `idx_runner` (`runner_id`), KEY `idx_status` (`status`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;订单表里的 reward_type 字段体现了这套系统的特殊定位：纯商业跑腿平台都以“金额”为唯一衡量标准，但校园互助场景里，很多需求是“帮打印一份文件”“帮占个座位”这种不好定价的事情。所以系统允许选择“爱心值”模式，完成订单后接单者获得爱心值累计，将来自己有需要时也可以“花费”爱心值求帮助。运营一段时间后发现，采用爱心值模式的订单完成率反而高于现金单，因为同学们对“互助”的心理认同感更强。
3.3 评价表和申诉表：信用体系闭环
评价表和申诉表是完整闭环不可缺少的部分。评价表记录订单完成后双方的互评，包括评分（1-5星）和文字内容。申诉表则记录异常订单的情况：跑腿者未按时取件、物品损坏、发布者恶意不确认收货等。管理员在后台看到申诉记录后，可以根据双方提交的证据（聊天记录截图、照片）进行判定，判定结果会影响双方的信用分。
这个设计也是从微信群接单乱象里总结出来的。在群里，跑腿者送了东西却被放鸽子，或者需求方发布了需求却没人接，都很难追责。有了评价和申诉机制，即使出现问题也有据可查，管理员能快速介入。
4. 后端核心实现：微信登录与订单状态机的完整链路
4.1 微信小程序 code 换 token 的完整流程
小程序的“微信登录”是很多人理解起来最绕的地方。实际流程分为三步：
小程序的 wx.login() 接口会返回一个一次性临时凭证 code，这个 code 有效期只有 5 分钟，而且只能使用一次。前端拿到 code 后调用后端/api/auth/wx-login接口，后端拿着 code 去请求微信官方接口https://api.weixin.qq.com/sns/jscode2session，换回 openid 和 session_key。然后后端用 openid 查数据库，如果查到就说明是老用户，直接返回登录成功；如果查不到，就自动创建一个新用户。
关键点在最后一步：这时候后端不是把 openid 直接返回给前端，而是生成一个自定义的 JWT Token，后续小程序请求其他接口时，在请求头里带这个 Token。这种设计的好处是 openid 永远不会暴露给前端，所有身份验证逻辑统一收敛在 Spring Security 6 的过滤器链里。
@PostMapping("/auth/wx-login") public Result<String> wxLogin(@RequestBody WxLoginRequest request) { // 1. 调微信接口换取 openid WxSessionResult session = restTemplate.getForObject( "https://api.weixin.qq.com/sns/jscode2session?appid={appid}&secret={secret}&js_code={code}&grant_type=authorization_code", WxSessionResult.class, appid, secret, request.getCode()); // 2. 判断用户是否存在 User user = userMapper.selectByOpenid(session.getOpenid()); if (user == null) { user = createUser(session.getOpenid()); } // 3. 生成 JWT 返回 String token = jwtUtil.generateToken(user.getId(), user.getRole()); return Result.ok(token); }需要特别强调的是 session_key 的敏感程度。它在微信官方文档里被明确标记为“不应下发到小程序客户端”，因为它是后续解密手机号、获取用户敏感信息的密钥。所以我只拿它来做登录态确认，后端拿到后立即丢弃，不缓存、不落库，这样即使数据库泄露也不会波及微信侧安全。
4.2 Spring Security 6 与 JWT 的无状态认证
Spring Boot 3 集成的 Spring Security 6 写法和旧版差别很大。我采用的是无状态 JWT 认证方式，核心是自定义一个 OncePerRequestFilter，在每次请求进来时从 Authorization 请求头里解析 Bearer Token，验证通过后把用户信息塞进 SecurityContextHolder。伴随着 Security 6 的默认配置，csrf().disable()必须显式声明，Session 配置也要设置为STATELESS。这里最容易踩的坑是 SecurityFilterChain 的放行规则顺序——比如/api/auth/**必须放在认证规则之前，否则登录接口本身也会被拦截。
@Bean public SecurityFilterChain filterChain(HttpSecurity http) throws Exception { http.csrf(AbstractHttpConfigurer::disable) .sessionManagement(session -> session.sessionCreationPolicy(SessionCreationPolicy.STATELESS)) .authorizeHttpRequests(auth -> auth .requestMatchers("/api/auth/**").permitAll() .requestMatchers("/api/admin/**").hasRole("ADMIN") .anyRequest().authenticated()) .addFilterBefore(jwtAuthenticationFilter, UsernamePasswordAuthenticationFilter.class); return http.build(); }这里有一个容易踩的坑：角色前缀。.hasRole("ADMIN")会在内部自动拼接成ROLE_ADMIN去比对，而我们在 JWT 里生成角色时如果只放了ADMIN，生成的鉴权对象权限也要写成ROLE_ADMIN，否则接口一直报 403，排查半天发现是对不上的问题。
4.3 订单状态机的实现与并发控制
状态机是后端业务逻辑里最有价值的部分。我没有引入 Workflow 引擎这种重型框架，而是用一个简单枚举 + 状态流转校验方法实现：
public enum OrderStatus { PENDING(0), ACCEPTED(1), DELIVERING(2), CONFIRMING(3), COMPLETED(4), CANCELLED(5), COMPLAINING(6); public boolean canTransitTo(OrderStatus target) { switch (this) { case PENDING: return target == ACCEPTED || target == CANCELLED; case ACCEPTED: return target == DELIVERING || target == CANCELLED; case DELIVERING: return target == CONFIRMING; case CONFIRMING: return target == COMPLETED || target == COMPLAINING; default: return false; } } }接单环节的并发问题值得单独说一下。一个订单只能被一个人接走，而“抢单”场景下可能有十几个同学同时点击接单。如果直接用 update 语句判断，会出现“超卖”问题。我的做法是利用数据库的乐观锁：update 时带上WHERE status = 0 AND runner_id IS NULL条件，受影响行数为 0 则说明已经被别人抢走。这个方案看起来简单，但比分布式锁更高效，而且完全满足校园场景的并发量。
5. 微信小程序端：从登录到接单的完整实现
5.1 小程序项目结构与 request 封装
小程序端我用原生开发，项目结构按照标准习惯分成 pages（页面）、components（组件）、api（接口封装）、utils（工具函数）。pages 下面分为 index（订单列表）、publish（发布需求）、detail（订单详情）、mine（个人中心）、login 等模块。
请求封装是所有页面开发的基础，核心思路是在 wx.request 外层包一层 Promise，统一带上 Token，处理过期重登，并把错误码统一弹 toast。这样所有页面调接口时只需关心业务逻辑。
const request = (url, method, data) => { return new Promise((resolve, reject) => { wx.request({ url: BASE_URL + url, method: method || 'GET', data: data || {}, header: { 'Authorization': 'Bearer ' + wx.getStorageSync('token'), 'Content-Type': 'application/json' }, success: (res) => { if (res.data.code === 200) { resolve(res.data.data); } else if (res.data.code === 401) { wx.navigateTo({ url: '/pages/login/index' }); } else { wx.showToast({ title: res.data.msg, icon: 'none' }); reject(res.data); } }, fail: (err) => { wx.showToast({ title: '网络异常', icon: 'none' }); reject(err); } }); }); };5.2 订单列表与发布页：地图选点真的别用基础组件
订单列表页是用户进入小程序后的第一个页面，设计上采用了“顶部 Tab 切换状态 + 订单卡片流”。每个订单卡片显示标题、酬劳类型与金额、取送地址、发布时间，并区分“我发布的”和“我接到的”两个视角。列表用 onPullDownRefresh 做下拉刷新，触底加载用 onReachBottom 实现分页。
分页这块有一个后端配合的关键点：后端接口接收 page 和 size 参数，返回数据时除了当前页列表，还需要返回 total。前端记录当前页码，每次触底时 page+1 再请求，把新数据 concat 到旧数据后面。这个逻辑看起来简单，但如果不注意“刷新时页码重置为 1”这个细节，会出现翻页后数据重复或丢失的问题。
地图选点是发布页最容易踩的坑。微信小程序自带的 map 组件和 wx.chooseLocation 在某些安卓机型上会出现定位偏差大的问题。实测下来更稳定的方案是引入腾讯地图 API（申请微信小程序专用的 key），用qqmap-wx-jssdk把地址解析成经纬度存入后台，取货时再根据经纬度显示位置。另外发布页还有个细节：预计送达时间不能早于当前时间，否则后端校验会直接拒绝创建订单。
5.3 接单与确认收货：拍照留痕保证可信
接单按钮的逻辑不复杂，就是一个 PUT 请求，把订单 id 传到/api/orders/{id}/accept接口。需要注意的点是确认收货。跑腿者送达后必须上传一张照片证明物品已送达，比如放在代收点的照片或当面交给对方的照片。后端限制只能上传图片类型文件，大小限制在 5MB 以内，使用 wx.chooseMedia 选择图片后，通过 wx.uploadFile 将文件以 multipart 方式传到后端，后端返回文件 URL，再调用确认收货接口。
上传文件这块的小程序端写法有个特点：wx.uploadFile 不能像 wx.request 那样直接传 JSON 对象，必须以 formData 方式携带业务参数。我第一版把订单 id 放在 URL 路径参数里传，结果发现服务端收到的路径参数被 URLEncode 代码后又多了一层转义，处理起来很别扭。后来干脆把订单 id 作为 formData 的一个字段和服务端约定好，省去很多麻烦。
5.4 实战中遇到的一个经典报错：组件方法不存在
调试过程中遇到一个非常典型的小程序报错：Component "pages/index/index" does not have a method "navigatorcl..."。这个错误表面上是说页面方法不存在，实际上是因为我在 list 组件里调用了bindtap="navigateToDetail"，但这个页面用原生自定义组件重构后，事件绑定的方法名拼写错误或没有定义在 methods 中。排查方式是在 app.json 里把对应页面设为首页，打开页面后右键选择“检查”，看控制台的具体调用栈。这个报错本身不难，但很容易发生在“从别人的代码复制过来改页面”的场景，因为复制时方法名忘了同步改。
6. Vue 3 管理后台：订单监管与异常处理的落地实践
6.1 后台技术栈与跨域问题
管理后台使用 Vite 创建 Vue 3 项目，状态管理用 Pinia，UI 组件库用 Element Plus，路由用 Vue Router 4。项目初始化直接用命令：
npm create vite@latest admin-web -- --template vue cd admin-web npm install element-plus pinia vue-router本地开发最闹心的是跨域。前后端分离模式下，前端跑在 5173 端口，后端跑在 8080 端口。我直接通过 Vite 的 proxy 配置把/api前缀的请求代理到后端，而不是后端做 CORS 全局配置。代理配置在 vite.config.js 里，这样既解决了跨域，又避免后端接口对所有人开放跨域带来的安全隐患。
export default defineConfig({ server: { port: 5173, proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } } });6.2 订单管理页：状态筛选与数据可视化
后台最核心的页面是订单管理页。顶部是 Element Plus 的筛选栏，支持按订单状态、发布时间、发布者姓名模糊查询。表格里展示核心字段，比如订单号、标题、发布者、接单者、状态、奖励、创建时间。操作列根据状态动态显示可用按钮：待接单订单管理员可以“强制取消”，异常状态订单可以“介入处理”。
数据统计用 ECharts 做了两个图表：一个是近 7 天订单量趋势折线图，一个是订单状态分布饼图。这里有一个 Vue 3 + ECharts 的坑值得记录：图表容器在 Tab 切换时如果宽高为 0，ECharts 渲染出来就是空白。解决办法是给图表容器设置固定高度，或者在 onMounted 和选项卡切换后用 nextTick 调用chart.resize()。我在热词里看到有人提到“pxtorem 对 echarts 没起到效果”，本质也是类似问题——ECharts 的 canvas 渲染机制不响应 CSS 字体转换，如果页面里配了 postcss-pxtorem，不要指望图表内部的文字单位会被自动转换，需要单独处理。
6.3 管理员权限控制
管理后台必须做权限控制，否则普通学生登录后台就能看到所有用户订单数据，属于严重的数据越权。我的做法是：后端 Security 配置中，所有/api/admin/**接口必须具有 ADMIN 角色才能访问。前端页面登录时拿到用户信息后，根据角色字段判断是否渲染管理菜单。菜单是隐藏了，但真正起作用的还是后端角色校验，前端隐藏菜单只是体验层面的东西。
这里补充一点：Spring Security 6 的注解使用方式也变了。以前用@PreAuthorize("hasRole('ADMIN')")，现在同样可以，但要确保在配置类上加了@EnableMethodSecurity注解。我刚升级到 Spring Boot 3 时因为没有加这个注解，所有方法级别的权限校验直接失效，接口匿名也能访问——这种接近裸奔的配置在真实环境里非常危险。
7. 部署上线与真实踩坑记录
7.1 后端打包与服务器部署
后端使用 Maven 打包成 fat jar，部署在云服务器上。我习惯用 Docker 部署，不仅环境一致性好，还方便后续迁移。Dockerfile 很简洁，基于 Eclipse Temurin JDK 17 镜像：
FROM eclipse-temurin:17-jre WORKDIR /app COPY target/runner-system.jar app.jar EXPOSE 8080 ENTRYPOINT ["java", "-jar", "app.jar"]启动命令用了 Docker Compose 编排 MySQL、Redis 和应用三个容器，应用容器依赖数据库容器健康检查通过后才启动。这一步别看简单，实际部署时如果没有配健康检查，应用启动时数据库还没就绪，会导致 Spring Boot 启动报错重试，体验极差。
7.2 小程序发布的注意事项
小程序端开发完成后，需要在微信开发者工具里点击“上传”，然后到微信公众平台提交审核。这里有几个细节非常影响效率：一是开发时要在“详情-本地设置”里勾选“不校验合法域名”，但上线前必须把 request 合法域名配置成自己的 HTTPS 域名，否则真机访问会直接白屏；二是小程序审核时比较严格，涉及订单交易的类目可能要求提供《增值电信业务经营许可证》或学校相关资质证明，校园内部系统建议申请“教育-校园生活服务”类目，审核通过率更高；三是正式版的小程序码需要管理员扫码预览，体验版也有人员白名单限制，找人帮忙测试时要提前把对方微信加入开发者或体验成员。
7.3 踩过的三个典型故障
第一个是 WebSocket 握手失败报错：handshake failed due to invalid upgrade header: null。这个报错出现在我用 SockJS + STOMP 做“新订单实时提醒”功能时。排查发现是 Nginx 代理配置少了 Upgrade 头与 Connection 头的转发，导致 WebSocket 升级请求被吞掉。修复方式是给 location 配置加上：
location /ws { proxy_pass http://127.0.0.1:8080; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; }第二个是服务器时间与本地时间不一致导致的“新发布订单排序错乱”问题。MySQL 默认使用数据库服务器时区，而微信小程序客户端又使用本地时区，结果用户发布订单后显示的“刚刚”其实已经过去 8 小时。统一方案是数据库连接串加serverTimezone=Asia/Shanghai，后端统一用 UTC 存储，前端渲染时再转本地时间。
第三个是图片上传后无法访问。这个坑特别隐蔽：后端把文件保存在本地磁盘/app/uploads目录，返回给前端的 URL 是/api/file/xxx.jpg。但 Spring Boot 默认不会把磁盘目录映射为静态资源，所以我不得不写一个静态资源映射配置类。后来我用WebMvcConfigurer的addResourceHandlers方法解决，不过再后来我干脆换成了云存储，毕竟服务器磁盘空间有限，而且多实例部署时本地文件不共享。
7.4 安全管理不容忽视
最后说说安全，这部分往往是被校园项目低估的。微信小程序端的登录态是 token 机制，token 一旦泄露，别人就能冒用你的身份操作订单。我做了三个层面的安全防护：JWT 设置 7 天有效期，并滑落刷新机制；管理端接口除了 JWT 鉴权外，再校验管理员 IP 白名单；用户修改手机号等敏感操作前，必须进行微信手机号快捷验证。此外所有接口都做了参数校验，防止 SQL 注入和 XSS 脚本注入。数据库账号也独立建了用户，只授予应用所需的最小权限，而不是直接拿 root 连接。
从第一版只有“发单-接单-完成”三个状态的简陋原型，到后来拥有信用体系、爱心值互助、异常申诉、管理后台可视化统计的完整系统，这个过程最大的感触是：技术本身并不复杂，真正复杂的是把校园里的真实业务场景抽象成有序的流程。如果你也在做类似的系统，建议先把用户角色、订单状态流转、异常处理路径想清楚，再动手写代码。把状态机设计好了，后续加功能只是填空，而不是推倒重来。
