企业官网建设流程全解析

前几年我带毕设的时候，一个很奇怪的现象就是：选校园外卖、跑腿、二手交易这类课题的学生最多，但真正能把这一类项目讲清楚、做完整、最后答辩不被问倒的，反而最少。原因其实不复杂——这类系统看似就是“下单、接单、派送、完单”四个词，一旦落到注册登录、权限控制、订单状态流转、支付回调、消息通知这些细节上，很多同学一下子就懵了，表格建得乱，接口写得糊，前后端联调全靠玄学。

今天我把这个基于微信小程序 + Spring Boot的校园外卖直送/跑腿平台从头到尾拆一遍，把需求怎么理、技术选型怎么定、数据库怎么建、核心接口怎么写、小程序端怎么做、论文和答辩怎么准备，全部串成一条实操线。尤其适合正在做毕设、又不想只做一个“增删改查壳子”的同学。

1. 项目需求拆解与整体设计思路

1.1 先把业务场景想透，再动手建表写代码

校园跑腿和校外外卖平台有一个本质区别：服务范围是闭环的。用户是校内的学生和教职工，配送方是校内兼职的学生骑手，商家要么是校内食堂档口、小卖部，要么是校门口被学生高频依赖的几家餐饮店。所有角色都集中在“校园”这个物理围墙内，所以配送距离短、交付时效强、高峰期集中（中午11点到12点半几乎是大爆发）。

这意味着什么呢？系统设计上就要照顾两个很现实的点：一是订单密度大但客单价低，所以骑手结算、平台抽成这些逻辑不能做得太重，最好就是按单计价加个跑腿费；二是角色天然互信度高，但又要避免纠纷，所以订单状态必须留痕清晰，用户和骑手在订单详情页都能看到每一次状态变更的时间节点。

我建议把整个系统拆成三个端来看：

• 用户端（微信小程序）：注册登录、浏览商家/商品、下单支付、订单跟踪、评价投诉。
• 骑手端（微信小程序）：接单大厅、抢单/系统派单、取货确认、送达确认、配送收益统计。
• 管理端（Web/或小程序内嵌管理页）：用户管理、商家审核、订单管理、投诉处理、基础数据统计。

这里我遇到过很多毕设组直接用一张用户表扛所有角色，用个 userType 字段区分学生、骑手、商家、管理员，结果后面前后端联调时越写越难受。这个做法在小Demo里看着省事，但骑手有接单状态、商家有营业额、用户有常用收货地址，这些角色化字段如果全塞在一张表里，查询和权限判断都会变得极其别扭。

更合理的做法是：一套登录账号体系搞定认证，再按角色建各自的扩展表，比如t_user（账号表）、t_student_profile（学生资料表）、t_rider_profile（骑手资料表）、t_merchant（商家表）。账号表只管登录和基础身份，把跟业务强相关的字段下沉到对应的角色表里。这样既符合Spring Security做统一认证的习惯，后面给运营方加个导出报表的接口也清爽。

接单模式上，我建议不要两条路都做——既做抢单大厅又做系统派单，是典型的“毕设设计过度”。实际需求里，早高峰和午晚高峰的订单密度根本不足以支撑完整的抢单调度算法，你做成“抢单大厅+管理员手动调派兜底”就已经比很多跟风项目合理得多。系统派单要做到“自动分配最优骑手”，背后又是一个完整的路径规划题目，这在论文里摊开来说会非常吃力，不如把主要篇幅放在订单全生命周期管理和支付对账上，这两块才是答辩老师最容易追问的地方。

1.2 功能清单要控制边界，别把需求做成百科

需求边界控制不好，是所有校园业务类毕设最要命的坑。我列一个我认为合理的、能在周期内完成且逻辑自洽的MVP功能清单：

• 微信授权登录 + 手机号绑定，维护学生基础身份信息。
• 校园地址管理，支持按宿舍园区/楼栋预设地址。
• 商家入驻申请 + 平台审核，维护营业状态。
• 商品分类、菜品列表、库存扣减。
• 购物车 + 下单 + 微信支付（可用模拟支付，走真实支付需要商户资质）。
• 订单状态机：待支付→待接单→配送中→已送达→已完成/已取消，售后单独立。
• 骑手接单、取货、送达三步确认。
• 用户端催单、取消、投诉。
• 骑手收益记录与提现申请（后台审核制）。
• 平台端数据看板：今日订单量、成交额、接单时效、热门商品Top10。

像“用户积分”“营销裂变”“多商家活动”“骑手身份认证KYC”“实时物流地图”这些如果是加分项，最多做一两个点到为止的演示功能，千万别图大求全。地图定位可以用腾讯地图或高德的小程序SDK做一个“假轨迹”演示——骑手点击发车后，地图上的标记按预订路径平移即可，这种程度的展示对毕设已经绰绰有余，且不会把工期拖垮。

2. 技术选型分析与项目搭建方案

2.1 后端：Spring Boot 的版本与组件搭配

Spring Boot 3.x 是当前新项目的合理默认选择，但结合毕设周期和网上资料丰富度，我个人更建议从 Spring Boot 2.7.x 起步。原因很现实：2.7 的教程、源码解析、踩坑记录在中文社区几乎“想要什么有什么”，而 3.x 对 JDK 17 的要求、Spring Security 6 的配置变更，会让联调出现很多“找不到对应版本答案”的卡顿。

推荐这一套组合，都是我前后带过多个同类项目验证过的：

• 基础框架：Spring Boot 2.7.x
• ORM：MyBatis-Plus（代码生成器直接生成 entity / mapper / service / controller 四层）
• 权限认证：Spring Security + JWT（小程序端通过 token 鉴权）
• 数据库：MySQL 8.x
• 缓存：Redis（存会话、商品热点数据、订单乐观锁版本号）
• 接口文档：Knife4j（增强版Swagger，用来给论文附图特别合适，可以直接生成接口文档目录）
• 构建工具：Maven

Spring Security 在小程序前后端分离项目里不需要写得太重。小程序端发请求没法像Web端那样自动携带Cookie，所以要走无状态登录：用户用微信的code换取 openid，后端拿到 openid 后签发 JWT，小程序端把 token 存在本地存储里，之后每次请求放在 header 的Authorization字段。

如果担心 Spring Security 这一套配置对小白不太友好，有一个折中方案：核心认证用拦截器（HandlerInterceptor）实现，JWT 校验也放在拦截器里，Spring Security 仅保留密码加密器（BCrypt）。这个做法写进论文可以被解释为“轻量级前后端分离认证方案”，答辩时讲起来压力更小。

2.2 小程序端：原生开发还是 uni-app ？

这俩我都用过，给个实际结论：如果只做微信小程序一个端，直接用原生开发——WXML、WXSS、JavaScript，配合微信开发者工具调试，没有额外学习成本，真机预览直接用手机扫码就能测。如果想着“将来可能要上支付宝小程序、抖音小程序”，才值得用 uni-app，因为跨端的收益是建立在一个几年内都不一定兑现的假设上的。

我在指导毕设时推荐的目录结构是这种业务优先的划分方式：

pages/ index/ // 首页（商家列表/商品推荐） merchant/ // 商家详情+菜单 cart/ // 购物车 order/ // 下单确认页 orderDetail/ // 订单详情与进度 orderList/ // 我的订单 mine/ // 个人中心 rider/ // 骑手接单大厅 riderOrder/ // 骑手配送列表 login/ // 登录授权页

每个页面目录下方放四个文件：.wxml、.wxss、.js、.json。只要保持这个结构一贯性，后面写论文的“系统实现”章节时，每个功能模块对应到页面和接口，脉络非常清晰。

小程序端的全局状态不推荐引入 Redux 或 Vuex 这种重量级方案。微信自带的app.globalData结合本地存储已经能覆盖80%的场景，需要全局共享的只有登录态token、用户信息、未读消息数。状态一多，反而容易在页面生命周期里找不到数据来源。

2.3 开发者账号和支付资质这些前置条件

微信小程序真机运行需要注册小程序账号，个人主体就能满足开发需求。但个人主体有一个限制：微信支付没法开通，支付功能只能走“模拟支付”——前端调起一个支付确认弹窗，后端把订单状态置为待接单，并把支付单号记录下来。企业主体的小程序才能开通微信支付，但绝大多数本科生手里没有公司资质。

如果学校或者学院有校企合作渠道，能借用企业资质注册小程序是最理想的，真实支付链路跑通，论文的“系统测试”章节也会更有分量。没有的话也不用焦虑，模拟支付完全能撑起完整的业务流，重点在微信支付的流程图、回调时序、订单幂等性设计，这些逻辑研究透彻了，文字上依然能体现出工作量。

3. 数据库设计与核心表结构

3.1 订单表是整个系统的“定海神针”

数据库设计中我特别想讲的是订单表。校园跑腿的外卖订单与标准电商订单有个很大区别：订单涉及用户、骑手、商家三方，还多次变更状态，所以订单表要拆成主表和子表分层管理。

我的建议是拆四张核心表：

订单主表t_order：order_id、order_no（业务编号）、user_id、rider_id、merchant_id、total_amount、delivery_fee、status、pay_status、create_time、accept_time、deliver_time、finish_time。订单号建议直接用yyyyMMddHHmmss + 随机6位的方式生成，不要用数据库自增ID直接暴露给前端，避免被遍历。

订单明细表t_order_item：item_id、order_id、product_id、product_name（冗余商品名，避免商品改名后历史订单对不上）、price、quantity。商品价格必须下单时快照，不能实时关联当前商品表价格，这是电商系统的常识，答辩时也可以主动提这一点作为亮点。

配送信息表t_delivery：delivery_id、order_id、rider_id、pickup_location、send_location、recipient_name、recipient_phone、delivery_status、expect_time。配送地址和联系方式不要和订单主表混在一起，独立出来，既方便骑手端按配送维度查询，也为将来做配送轨迹回放留结构余地。

骑手收益表t_rider_income：income_id、rider_id、order_id、amount、type（配送收入/平台补贴/提现扣除）、status（待结算/已入账/申请提现/已打款）。收益表单独建，是为了避免骑手每天查账单时去聚合订单表，大大减轻单表查询压力。

其他像用户表、商家表、商品表、地址表、评价表、投诉表，结构都比较常规。有一点细节要注意：素质和答案里希望做到“软删除”——所有表都带deleted字段（0/1），查列表时统一过滤。你可能觉得多此一举，但论文的功能测试章节里，“商品下架后历史订单还能正确显示商品名称”这类场景，靠冗余字段和软删除就能非常干净地解释清楚。

3.2 订单状态机设计：不要让状态随意跳

外卖类系统的状态比普通购物订单复杂得多，我见过很多同学的代码里status字段就是 “0未支付 1支付 2完成 -1取消”，然后所有模块都拿同一套值做判断。这种写法短期能跑，但一旦要加售后、退款、配送超时，代码里全是散落的魔法数字，排查问题全靠眼睛找。

我建议在项目里就用一个枚举类把状态机固化下来，例如：

public enum OrderStatus { UNPAID(0, "待支付"), PENDING(10, "待接单"), DELIVERING(20, "配送中"), COMPLETED(30, "已送达"), CANCELED(40, "已取消"), REFUNDING(50, "退款中"), REFUNDED(60, "已退款"); }

状态流转无外乎这几条合法路径：待支付→待接单（支付回调成功）；待接单→配送中（骑手接单并取货）；配送中→已送达（骑手确认送达）；待支付/待接单→已取消（用户主动取消或超时未支付）；已送达→退款中→已退款（售后申请通过）。把状态流转写成单独的OrderStateService，不要让Controller里的业务代码随手order.setStatus(20)。这个设计写到论文的“系统设计”章节非常加分，答辩时老师问“订单状态你是怎么管理的”，你能直接从枚举类讲到状态机，再讲到每一步操作的时间节点记录，整个回答的严密性完全不一样。

3.3 数据库字段设计的几个常见坑

校园项目的数据量虽然不大，但字段规范还是要认真对待，否则后面写复杂查询时很痛苦。

• 所有金额字段用DECIMAL(10,2)，不要用float/double，浮点精度问题在涉及对账时迟早会捅娄子。
• 所有时间字段用datetime，不要用varchar，否则“统计今天订单量”这类SQL写起来让人怀疑人生。
• 手机号加密存储还是明文存储，这个看系统需要，内部测试系统明文无所谓，但论文里如果能写出“用Hutool的DesensitizedUtil对手机号进行脱敏展示”，这就是一个专业细节。
• 建立索引不能省：t_order里的user_id、rider_id、status，t_order_item里的order_id，t_delivery里的rider_id。不需要太多，够用就行。

4. 后端核心接口与业务逻辑实现

4.1 登录认证流程：小程序 code 换 token

小程序的登录和传统的前后端分离登录不一样，它依赖微信生态的wx.login()。简单说，前端调用wx.login()拿到一个临时code，后端拿到这个code去微信的接口换openid，然后在自己的用户表里查这个openid是否存在，不存在就自动注册一个账号，存在就直接签发JWT返回给前端。

核心代码大致长这样：

@PostMapping("/login") public Result login(@RequestBody LoginRequest request) { // 用code换openid String openid = wxService.code2Session(request.getCode()); User user = userMapper.selectByOpenid(openid); if (user == null) { user = userService.registerByOpenid(openid); } String token = jwtUtil.generateToken(user.getUserId(), user.getRole()); return Result.success(new LoginVO(token, user.getRole())); }

这里有个易踩的坑：换openid是后端去调微信的接口，所以需要配置小程序的appid和appsecret。很多同学图方便，把appsecret直接写在小程序前端代码里，这是完全错误的。appsecret泄露后别人可以伪造接口请求拿你的用户数据，必须放在后端配置文件。用application.yml统一管理，再按环境区分dev和prod配置。

JWT的有效期一般设为7天，小程序端每次冷启动时检查一下本地token是否过期。过期就让用户重新走一遍wx.login静默登录，不需要用户的额外操作。

4.2 下单事务与库存扣减

用户从购物车提交订单到扣减库存，是一组必须保证原子性的操作。初学者最容易犯的错是：先创建订单，再扣库存，中间如果库存不够了订单还要回滚，结果只在报错里打了日志，没有抛异常触发事务回滚。

我用一个下单方法来讲清楚：

@Transactional(rollbackFor = Exception.class) public OrderVO createOrder(CreateOrderDTO dto) { // 1. 校验商家营业状态 // 2. 结算商品价格，生成订单快照明细 // 3. 扣减库存（带乐观锁） int rows = productMapper.deductStock(productId, quantity); if (rows == 0) { throw new BizException("商品库存不足"); } // 4. 插入订单主表和明细表 // 5. 清空购物车对应项 }

扣减库存用了UPDATE product SET stock = stock - #{quantity} WHERE product_id = #{id} AND stock >= #{quantity}这种写法，用受影响行数判断是否成功，比先查库存再判断的“先查后改”方式在高并发下更稳妥。写论文时这个点也值得单独讲一段，属于能体现思考深度的细节。

4.3 订单状态流转与超时处理

外卖系统天然要处理“超时无人接单”“超时未支付”这些情况。最简单落地的方式是用Redis存储订单创建时间和状态，配合一个延迟队列做超时任务。前缀建议order:timeout:支付超时，到期后查询订单状态，如果还是待支付状态，就把它置为取消并释放库存。这个小模块做好了，答辩讲“你系统里有哪些异步处理”，这个就是最扎实的素材。

从项目复杂度的角度，不推荐引入完整的MQ中间件来做延迟消息，一个ScheduledExecutorService或者Spring自带的@Scheduled定时扫描就够用了。每5秒扫一次待支付订单，如果创建超过15分钟，置为取消。扫描频率和订单超时时间可以写成配置文件里的可调参数，演示的时候直接改时间参数给老师看效果，非常有演示冲击力。

4.4 支付回调的幂等处理

如果做了真实微信支付，回调接口必须做幂等：微信支付回调可能因为网络原因重复推送，后端不能因为重复回调给用户重复更新状态。

处理方式很简单：用订单号+回调单号作为唯一约束。回调进来以后，先查本地是否存在该回调编号，存在直接返回成功，不再重复处理；不存在则开启事务更新订单状态。这样做既能保证不丢单，也能保证不多更。真实支付和模拟支付在代码路径上可以保持一致，只是模拟支付省去了微信服务器回调那一步，由前端直接通知后端“我模拟支付成功了”。

5. 微信小程序端核心流程与实现要点

5.1 页面导航与角色切换

小程序端最大的体验痛点是“一个包，两种身份”：同一个用户可能既是下单的学生，又是骑手。我在设计的时候把“身份切换”做成了个人中心里的一个明显的滑块：切到“骑手模式”，底部Tab栏切换为接单大厅、配送中、我的收益；切回“用户模式”，Tab栏变回首页、购物车、订单、我的。

这种切换不需要单独开发两套包，一个tabBar配置里包含超过四个主入口会太挤，我选择的是同一个mine页面，根据角色动态渲染菜单。页面内部逻辑保持单一路径，用globalData.currentRole标记当前角色，发起请求时把这个角色字段一并带给后端，后端根据角色判断数据范围。角色切换后，全局刷一次相关列表页，界面清爽，逻辑也简单。

5.2 下单支付流程的交互细节

从商品详情页点击“立即购买”到跳转支付，整个流程中我建议在几个关键节点做“防呆”：

• 收货地址必须校验在可配送范围内——在小程序里维护一个校区地址经纬度白名单，超出范围直接提示“当前地址不在配送范围”。
• 购物车里每个商品要展示实时库存，库存为0的商品置灰，用户没法提交一个缺货的订单。
• 提交订单前二次确认配送费。校园跑腿的配送费通常是阶梯式：同一宿舍园区3元，跨园区4元，恶劣天气可临时加价配置。让用户在支付前就明确看到这个费用，能减少大量“为什么多了几块钱”的客诉。

支付页面的处理逻辑上，微信支付要求“先下单、再支付”。用我的流程来讲就是：前端先把订单信息提交给后端，后端返回prepay_id和订单号；然后前端调wx.requestPayment拉起支付面板；支付成功回调里更新本地订单状态并跳转到订单详情页。模拟支付模式下，省掉requestPayment那一层，直接弹一个“模拟支付”按钮，点了以后调后端模拟支付接口。

5.3 骑手接单大厅的实时性实现

骑手接单大厅要看到实时新的订单，如果用传统“下拉刷新”，骑手得一直手动刷新，体验很糟糕。小程序里做最简单的“伪实时”方案就是轮询：接单大厅页面onShow时启动定时器，每5秒调一次接口获取待接单列表。复杂度再高一点，接单成功后把该订单从列表里剔除，避免同一个人看到自己已经接过的订单。

更进一步的方案是使用小程序的WebSocket通道，后端在订单状态产生变化时主动推送消息。对毕设来说这属于加分项，但如果做，要注意断线重连和心跳保活。难度在于小程序在后台会被冻结，WebSocket连接很容易被系统切断，真机测试时要允许用户主动收回到前台后重建连接。我建议轮询足够，论文里在“进一步工作”章节留一句“引入消息中间件与WebSocket优化实时性”即可。

5.4 小程序端常见报错与调试建议

开发小程序时，百分之八十的报错都能在微信开发者工具的“Console”面板直接看到。我想特别提醒几个高频问题：

• request合法域名报错：调试时勾选“不校验合法域名”就能访问本机后端接口，但真机预览时必须用https域名。毕设演示用本地局域网IP是可行的，手机和电脑连同一WiFi，把接口地址改成电脑的局域网IP即可。
• app.json里注册的页面路径写错，会直接白屏并报“页面路径错误”，排查时先看这个。
• 用户授权弹窗必须用小程序的button组件加open-type="getPhoneNumber"才能拿到手机号，用普通view标签绑定点击事件是拿不到的。
• 本地存储的token在用户重新编译后会丢失，所以每次冷启动都要做一次静默登录校验，不要把用户信息全埋在本地持久化里。

6. 毕设文档撰写要点与答辩准备

6.1 论文结构怎么排，工作量最容易体现

学校对毕设论文的要求大同小异，但真正决定论文质量的往往不是篇幅而是结构完整性。以这个项目为例，我建议的大纲是：

1. 绪论：研究背景、国内外研究现状、研究内容与章节安排。
2. 需求分析：可行性分析、角色分析、用例图（用户/骑手/管理员）、功能需求与非功能需求。
3. 系统设计：系统架构图、技术选型、数据库设计（E-R图/核心表结构）、接口设计。
4. 系统实现：按模块写实现——登录模块、商家商品模块、下单支付模块、配送模块、骑手收益模块、管理后台模块。
5. 系统测试：测试环境、功能测试用例表、性能测试或并发测试、测试结论。

论文里凡是能画图的都建议画图：用例图、时序图、E-R图、架构图、状态图，一张图的信息量顶得上大段文字。学校里一般要求用特定画图软件，但先用ProcessOn这些在线工具画好底稿，再按学校模板重绘，效率高很多。

6.2 答辩中老师最可能追问的问题

答辩提问大多集中在几个方向，提前准备好就不会卡壳：

“你为什么选Spring Boot而不选SSM？”——回答角度：起步依赖简化配置、内嵌Tomcat便捷部署、生态成熟找资料容易、MyBatis-Plus进一步减少样板代码。

“订单并发时数据库怎么保证一致性？”——回答角度：事务注解、乐观锁扣库存、Redis缓存热点数据、支付回调幂等表。

“如果骑手接单后不配送怎么办？”——回答角度：超时未取货可以自动取消资格并释放订单回池，超时送达降权处理，这些规则可以在后台配置。

“你这个系统怎么保证用户信息安全？”——回答角度：密码BCrypt加密、手机号脱敏展示、Token有效期校验、接口返回时剔除敏感字段。

这些问题没有标准答案，但如果你在项目文档里对每一个都有具体的代码位置和逻辑描述，答辩现场就会从容得多。我见过不少同学做的东西很扎实，演示环节很流畅，却被一句“你讲讲测试用例是怎么设计出来的”问住了。所以测试章节不要只写SQL脚本跑通，可以把边界情况写进去：比如库存为0下单、重复请求支付回调、骑手重复接同一单，这些异常用例比纯功能用例更能体现工程思维。

6.3 演示环境的准备与节奏把控

答辩演示通常要求三分屏：电脑屏幕投屏、手机端小程序操作、后端日志或数据库实时变化。我会建议把演示脚本固定下来，每个步骤控制在1分钟内：

• 先用“商家端”添加一个商品，切到“管理端”审核通过。
• 打开小程序端，登录，选商品、加购物车、下单、模拟支付。
• 切到骑手端，看到新订单并接单，触发配送状态流转。
• 回用户端观察订单状态变成配送中，随后骑手确认送达。
• 打开管理后台，展示今日订单统计和骑手收益结算。

整个过程5分钟，Roles切换清晰，每个模块都有交互变化，比停留在静态界面更有说服力。真机飞行模式下如果网络不稳，建议先把录屏存一份，网络上出现波动时切换录屏兜底，这属于经历过现场翻车以后才会懂的细节。

7. 常见问题与避坑技巧实录

7.1 联调阶段最容易出现的后端问题

前后端联调时，接口统一返回格式能省掉大量沟通成本。我习惯所有接口返回Result<T>，结构固定为{code: 200, message: "ok", data: ...}。前端拦截器统一判断code，非200就弹Toast。这个约定一定从头贯穿到尾，否则每个接口单独判断成功标志，联调起来极其痛苦。

跨域问题，小程序端其实没有浏览器的同源策略限制，但如果管理后台Web端要调同一个后端，Controller上就需要处理CORS。直接在配置类里加一个WebMvcConfigurer统一配置允许跨域，别在每个Controller上加@CrossOrigin。

Redis连接不上导致登录接口报错是出现频率最高的环境问题。排查顺序一般是：先看Redis服务是否启动，再看application.yml里的端口和密码是否匹配，最后确认本地有没有多个Redis进程占用端口。这一套排查下来，大部分问题都能解决。

7.2 小程序端数据缓存与更新的坑

购物车数据一定不能只存在本地缓存里。本地缓存一旦清掉，用户重新打开小程序购物车就空了，体验极差。我的做法是把购物车数据结构存在globalData中，每次登录成功或切换校区时从后端重新拉取。加购、删购、改数量这些操作先更新本地界面，再异步同步到后端，同时在服务端保留一份购物车表，保证用户在任意设备登录都能恢复。

订单详情的状态，用一个“定时轮询 + 微信订阅消息通知”组合，不要只依赖订阅消息。小程序的订阅消息是一次的，用户订阅一次只能推送一条，用户不订阅就没法推送。所以订单详情页要允许前端主动刷新，骑手端每次状态变更后推送一次订阅消息，并在订单详情页提供“刷新”按钮兜底。我在做这个项目的时候，测试中最常见的“用户端订单状态不更新”，又有大半是忽略了轮询刷新，改完立刻清爽。

7.3 这些坑我踩过一次就不会再踩

• 不要把数据库的编码设置成默认的utf8，要指定utf8mb4，否则用户昵称带个emoji，直接整条插入失败，报错还很误导人。
• 时间格式化统一用Jackson的全局配置，spring.jackson.date-format配合@JsonFormat，防止前端拿到“2024-06-01T12:00:00”然后不知道该不该加8小时时区。
• 文件上传（比如商品图片、学生证照片）尽量存本地目录，配置一个虚拟路径映射到磁盘路径，不要直接把文件写进数据库的longblob。图片路径存字段，文件落在磁盘，读写都高效。
• 后台管理的图表不要自己用Canvas手绘折线图，直接引入ECharts的仪表盘，把今日订单量、营业额、接单时长放一起，十分钟搞定，视觉效果好到超出答辩预期。

写在最后的一点体会

这类校园跑腿/外卖直送系统，从技术难度上说，远没有大家想象的那么高，它最考验人的其实是梳理业务的能力和保持状态一致性的细心程度。我做这个选题的体会是：如果你把订单状态流转、支付幂等、用户与骑手权限边界这三个核心问题想透了，整个项目的骨架就立住了，剩下的页面堆积和接口增删只是时间问题。

实际带项目的过程中，不少同学前两周信心满满，到联调阶段因为一个小字段问题卡一整天，就想把锅甩给“前后端不熟”。其实这些都不是不可逾越的技术障碍，而是缺少一份能够把系统边界、字段定义、状态流转讲清楚的全局设计文档。论文和代码的配合，恰恰是解决这种问题的钥匙——文档把“你要做什么、状态怎么走、字段怎么存”定下来，代码只是翻译这份约定罢了。

希望这篇拆解能帮你把整个项目的链路看通透，也希望你在做的时候多给自己留出联调时间。校园这个场景太适合练手了：需求自己就经历过，业务流程来自真实生活，写代码的时候天然带着场景感，哪怕是一个小小的“催单”按钮，也能直接想到它针对的是午间高峰的焦急等待。带着这种真实感去做项目，你的每一行代码都会比纯虚构的练习多一层扎实的味道。