你手机里的互助群是不是经常变味儿？开学拼单、二手教材、代取快递、课设答疑、组队比赛，这些需求明明每天都在发生，但群里的消息总是被闲聊和广告淹没。晚上十点想找一个会改格式的学长，翻了两小时聊天记录还是一无所获。这个“木成林”学生互助平台，就是想给这些需求一个正经的归属地：不是让大伙儿在群里吼，而是用 Spring Boot 把“发布需求—精准推送—接单处理—完成确认—互评积分”这条完整链路做成产品。平台设计里我同时用了“学林互助”“林聚学”这两套命名思路，前者强调校园林荫下的学习场景，后者把“聚”字放在中心，本质都是同一件事：把零散的学生互帮互助，变成可沉淀、可追溯、可激励的在线服务闭环。如果你是正在准备计算机毕业设计，又恰好对 Spring Boot 前后端分离项目感兴趣，这篇文字可以当作一份带排雷记录的项目复盘来看，我会把从需求拆分到技术选型，从建表到上线踩坑的整个过程都摊开讲。
1. 互助平台到底解决什么问题
1.1 一个真实场景
我见过太多类似的情况：大一新生入学，需要一套高数复习资料，能在宿舍楼下转一圈就借到的人不多，而去表白墙发帖又容易石沉大海。另一边，大四学长毕业前有成箱的考研书不知道怎么处理，最后只能按废纸称斤卖掉。两边都有明确需求，信息却从来没被有效连接过。问题出在哪里？不是学生不愿意互助，而是现有的渠道——QQ 群、微信群、校园论坛——本质上都是“广播式”的，没有结构化字段，没有状态管理，也没有信用评价体系。互助信息一旦被刷上去，它的生命周期就结束了，下一次再有相同需求，又得重新问一遍。
我在设计这个平台时，第一个动作不是写代码，而是把学生互助这件事拆成四个阶段：发需求、找人接、验收成果、留评价。任何脱离这四个阶段的附加功能都是锦上添花，四个阶段跑不通，平台就是个空壳。“木成林”这个名字也是在这个阶段定下来的——单棵树容易被风吹倒，连成林子才能互相支撑，学生互助平台的价值不是让你交到更多“好友”，而是让你在需要帮忙的瞬间，能有一个可信的、效率够高的渠道，找到愿意且有能力帮你的同学。
1.2 三种核心角色
平台上线前，我花了很多时间访谈周围的同学，最后把使用者收敛成三种角色：发起人、接单者、旁观者（也就是还没产生互助行为，但会浏览内容、搜索信息的用户）。很多同类项目把用户简单分成管理员和普通用户，这是不够的，因为学生互助场景里，同一个人可能上午发布求助，下午就去接别人的单，角色是动态切换的。
发起人：核心诉求是“快”和“靠谱”。他们需要清楚地描述自己要什么、愿意付出什么（可以是积分，也可以是虚拟币），还需要看到接单者的历史完成率和评价。
接单者：核心诉求是“信息值得接”。他们不想做看不见回报的活，所以平台必须提供明确的奖励规则，让人能快速判断“这个单值不值得接”。
旁观者：虽然是低频用户，但他们是平台冷启动阶段最重要的传播节点。他们会因为看到有人成功互助了，才注册账号，所以平台必须有“公开互助案例”的曝光机制。
管理员的角色当然存在，但我不建议让它承担过多它处理不了的业务。后台只做三件事：内容审核、用户封禁、数据统计。审核一定要放在发帖时，因为发布即公开，如果发完再人工巡查，平台里早就堆满垃圾信息了。
1.3 项目边界：哪些功能必须砍掉
学生互助平台有一条天然的扩张诱惑：既然大家要拼单，那就做购物；既然大家要聊天，那就做即时通讯。我自己的切身体会是，做毕设项目最容易死掉的不是功能太少，而是功能太多。一个几万行代码的项目如果什么都能干，说明它什么都没想清楚。
我最终划定的范围是这样的：核心模块包括用户注册登录、互助信息发布与管理、接单与交付确认、积分与评价体系、私信通知、后台审核。砍掉的功能包括站内交易支付、社团活动管理、课程表同步、二手商城。为什么砍二手商城？因为二手物品需要图片多、规格乱、物流不确定，它就是一个独立的产品形态，强行塞进互助平台会让主流程变臃肿。砍掉交易支付则是因为学生间小额代购、课设代做的边界本来就模糊，一旦引入真实资金结算，项目复杂度会指数级上升，而且还涉及合规风险，不是学生项目该碰的。
这个边界划完后，整个项目的业务逻辑就变得非常清晰：平台不碰钱，只碰“事”。所有的激励都基于积分系统，用户可以拿积分换别人的帮助，也可以因为帮助别人获得积分。这套逻辑避免了支付合规问题，也让数据模型变得简单可解释。
2. 技术选型的理由与前期准备
2.1 为什么是 Spring Boot 3 + MyBatis-Plus
这个项目在技术选型上没有特别激进，但也不是用得越旧越稳。我选用 Spring Boot 3.2.5，搭配 JDK 17，原因很简单：Spring Boot 3 已经全面拥抱 Jakarta EE，Spring 官方对 2.x 的维护力度持续下降，新项目的依赖解析更快，启动内存占用也更友好。如果你还在用 JDK 8 + Spring Boot 2.x，不是不能跑，而是当你去调研、去答辩时，面试官只要追问一句“为什么不用新版本”，你就会很被动。
持久层我选了 MyBatis-Plus，而不是 Spring Data JPA，也不是原生 MyBatis。理由是我需要快速开发能力：学生互助平台的查询条件很多——按分类、按学号、按状态、按积分区间——这些组合查询用 MyBatis-Plus 的 LambdaQueryWrapper 写起来非常高效，可以避免手写大量 XML 映射文件。JPA 虽然抽象程度高，但在复杂分页和动态 SQL 上反而不如 MyBatis-Plus 直观，尤其对于不熟悉 Hibernate 缓存机制的同学，很容易写出烂查询。
这里有一个容易被人忽略的点：MyBatis-Plus 的字段自动填充。平台里的用户表、互助单表、评论表都涉及 createTime、updateTime、deleted 这些字段。用 @TableField(fill = FieldFill.INSERT) 配合 MetaObjectHandler 全局处理器，可以在插入和更新时自动填充，不需要在每个业务方法里手动 set 一次时间。这个操作能省掉大量重复代码，也是我在答辩时喜欢拿出来当细节讲的地方。
2.2 前后端分离还是服务端渲染
这个问题的答案直接决定了整个项目结构。我做的是前后端分离，前端用 Vue 3 + Vite + Element Plus，后端纯提供 JSON API。前端项目独立在 ui 目录下，后端代码在 server 目录下，两者通过 Nginx 或代理方式进行联调。
有人问为什么不直接用 Thymeleaf 做服务端渲染，那样省事很多。我的理由是：第一，学生互助平台有大量的状态交互，比如接单按钮要在不同状态间切换可用性，用 Vite 的热更新开发体验远好于刷新页面等渲染；第二，毕业设计答辩时，面试官大概率会问前后端交互、跨域、鉴权请求头、接口幂等设计这些问题，如果你用服务端渲染，这些话题根本展示不出来；第三，Vue 3 的组合式 API 写起来本身并不复杂，反而能体现你对现代前端工程的理解。
我给的目录结构参考如下：
helpler-platform ├── server │ ├── src/main/java/com/campus/helper │ │ ├── common（全局异常、返回体封装、工具类） │ │ ├── config（MyBatis、Redis、WebMvc、WebSocket配置） │ │ ├── controller（REST接口层） │ │ ├── service（业务逻辑层） │ │ ├── mapper（MyBatis-Plus接口） │ │ ├── entity（数据实体） │ │ ├── dto（前端入参对象） │ │ └── vo（接口出参对象） │ └── src/main/resources │ ├── application.yml │ ├── db/migration（SQL脚本） │ └── mapper（自定义XML，如果有多表联查） └── ui ├── src/views（页面组件） ├── src/api（接口请求封装） └── vite.config.ts（代理配置）注意，dto 和 vo 必须和 entity 分开。很多初学项目直接在 controller 层返回 Entity，字段暴露太多不说，前端还会拿到 createTime、deleted 这些完全不该它关心的内部字段。我在项目里强制约定：Controller 不直接接收 Entity，必须用 DTO 接收请求参数，用 VO 返回给前端，每个字段都要有明确的命名注释。
2.3 环境准备与初始化要点
环境这块不要踩版本坑。我推荐你锁定如下版本组合，这些是我实测过能正常运行的组合，不要随便升小版本：
- JDK 17（不要用 21，有些依赖还没完全适配）
- Maven 3.9.6
- Spring Boot 3.2.5
- MyBatis-Plus 3.5.7
- MySQL 8.0.36（注意驱动是 com.mysql.cj.jdbc.Driver）
- Redis 7.x（用于验证码、JWT黑名单、缓存）
数据库初始化时，推荐在 application.yml 里配置initialization-mode: always，配合schema.sql创建表结构。不过我更建议你用 Flyway 做版本化迁移，因为毕设项目开发周期通常有几个月，表结构一定会变，没有迁移工具的话，改一次表就要手动在本地删库重建，非常痛苦。Flyway 的脚本命名规范是V1__init.sql、V2__add_help_order.sql，它能保证不同开发环境的数据库版本一致，这个习惯进了企业团队也同样适用。
3. 数据库设计：表结构、状态机与冗余字段
3.1 核心表拆解
学生互助平台的核心表比我一开始预想的多。最初的模型只有用户表、互助单表、评论表，后来发现根本不够。真实业务里还需要：分类字典表（用于前台按类别筛选）、关注表（用于用户订阅某个分类）、积分流水表（用于记录每次变动）、通知表（用于站内信）、举报表（用于违规处理）、接单记录表（同一单可能出现多次被接又取消的情况）。
我挑几个关键表重点说一下设计思路。用户表 user 里除了常规的 username、password、nickname、avatar，还必须有 college、grade、major（学院、年级、专业）这种校园字段，因为互助平台需要做同一校区的匹配，比如帮拿快递这种需求，跨校区接单毫无意义。密码字段用 BCrypt 加密存储，长度至少定 60 位。
互助单表 help_order 是业务的中枢，字段包括：title、description、category_id、publisher_id、receiver_id、expect_time、end_time、address、reward_points、status。这里有一个很容易忽略的设计点：status 要保存当前状态，同时整张表要保留历史轨迹，所以我会额外建一张 help_order_log 表，记录每一次状态变更的发起人、动作、备注和时间。作用有两个，一是运营仲裁时能还原事实，二是排查 bug 时能知道用户究竟点到什么按钮导致状态异常。很多同学只在内存里打日志，线上环境出问题时完全没抓手，这不是一个健壮系统该有的样子。
分类表可以做得灵活一点：id、parent_id、name、sort_order。我内置了学习资料、取件代跑、课程答疑、组队竞赛、生活互助、二手信息共六个一级分类，再在每个一级分类下挂二级分类。注意不要为了灵活就做成无限级分类，学生互助场景两级已经够用，更深层级只会让前端的筛选项变得难以理解。
3.2 互助单的状态流转：从发布到完成的五个阶段
互助单的状态设计是我在写代码前就敲定好的，因为这直接决定了接口的校验逻辑。它总共五个状态：
- WAIT_RECEIVE（等待接单）：发布成功后进入此状态，任何符合条件且未被拉黑的用户都可接单。
- RECEIVED（已接单）：用户接单后进入，此时发布者能看到接单者联系方式，但不能再次被其他人接。
- DELIVERING（交付中）：接单者标记“开始处理”，双方进入沟通阶段。
- COMPLETED（已完成）：发布者点击“确认完成”，积分结算触发。
- CANCELED（已取消）：发布者主动取消，或在接单前超时未处理。
状态机的关键是，不是每条路径都允许直接跳跃。比如已接单状态下，发布者不能直接把单改成已完成，必须先等接单者标记交付中。比如等待接单状态下，接单者不能取消，只有发布者能取消。这些约束写在哪？写在 service 层而不是前端隐藏按钮，因为前端只是体验优化，真正的业务规则必须由后端强制执行。
我额外加了一个超时自动关单的机制：发布后超过 24 小时没人接单，系统自动把状态改成 CANCELED，并给发布者推送提示。这个需求看起来简单，实现时要注意定时任务不要用简单的@Scheduled(cron = "0 */10 * * * ?")去扫全表，那样数据量大了会很难受。更合理的方式是记录 expire_time 字段，定时任务只查expire_time < now AND status = 'WAIT_RECEIVE'，并且利用索引。
3.3 为什么要冗余积分字段
积分系统的设计也是同样的道理。我在 user 表里维护了一个points_total字段，同时在积分流水表里记录每一次加减明细。这种做法在数据库设计上属于“冗余”，但它是刻意为之的、可控的冗余。原因很直接：如果在页面上展示用户积分时每次都去SUM(积分流水表.value)，那查询会随着流水增长越来越慢，而且一旦历史数据被归档，甚至算不出正确结果。
具体到结算逻辑，我设的规则是：发布者初始有 100 积分，每发布一个互助单冻结 5 分作为担保，单子完成后从保证金扣除 3 分奖励给接单者，另外 2 分退回。接单者完成一单得 3 分，被举报且审核成立扣 5 分。这个比例听起来随意，但它的核心思想是设置一个“惩罚成本”：用户不会因为积分太少而完全无法发布，但会珍惜自己的积分，不会随意放鸽子或乱发无用需求。
要注意的是，积分扣减和发放必须在一个数据库事务里完成，不能先改 help_order 的状态，再调积分接口，因为这两者之间任何一步失败都会造成账目不平。我在后面第四章的踩坑部分会详细讲这个事务问题。
4. 关键接口实现思路与代码骨架
4.1 登录鉴权：JWT + Redis 双保险
学生互助平台的登录鉴权我用的是 JWT 加 Redis 的组合方案，没有引入 Spring Security，因为平台的角色权限模型很轻，引入重型安全框架反而增加学习成本。我写了一个自定义的拦截器，校验流程如下：
- 用户登录成功后，服务端生成一个 JWT，其中 payload 只放 userId、role、expiresAt 三个字段，不存放密码等敏感信息。
- 同时在 Redis 里写入
login:token:{userId}作为当前有效会话的 key，value 是 token 的 hash，过期时间设为 24 小时。 - 请求进入拦截器后，先从 Header 里取 token，解析出来 userId，再检查 Redis 里的 token 是否和当前 token 一致，不一致就说明用户在别处登录或者已经退出登录。
这个方案有一个值得说的细节：如果只验证 JWT 的有效性，那么当用户修改密码或被管理员封禁后，旧的 JWT 依然有效，这是安全隐患。而 Redis 的存在保证了服务端可以主动吊销某个会话，这就是“状态化认证”的价值。还有一点，Redis key 过期时间要和服务端设置的 JWT 过期时间保持一致，否则会出现 Redis 里会话还在、JWT 却已经过期的情况，导致用户莫名被踢下线。
4.2 发布互助单与同校区匹配
发布互助单的接口逻辑不复杂，复杂的是推送匹配。我的做法是这样：用户提交互助单时带上 categoryId、address、expectTime，后端保存成功后，异步查询符合条件的潜在接单者——他们需要满足三点：当前没有重复接同类型的单、和发布者在同一个校区、近期活跃度大于某个阈值。这个查询不需要非常精准，因为互助平台不是高并发的电商系统，只要保证候选池合理即可。
为了后续扩展，我把匹配逻辑做成策略模式，先定义 MatchStrategy 接口，然后实现 CategoryMatchStrategy、CampusMatchStrategy、HistoryMatchStrategy 三个策略。当前版本用的是组合策略：先按分类圈定用户，再按校区过滤，最后按历史完成率排序。即使现在只用到其中两步，这个结构也能让你在答辩时说清楚“可扩展”这件事，而不是嘴说设计模式却没有任何落地。
发布成功之后，同步给候选接单者发送站内通知。这里我用的是 Spring 自带的事件监听机制：ApplicationEventPublisher 发布 HelpOrderCreateEvent 事件，NotifyEventListener 负责处理通知。这么做的好处是业务方法和通知逻辑解耦，后续你加短信、加邮件推送，都不需要改动发布接口的核心代码。
4.3 接单与完成确认的幂等处理
接单接口是整个系统里最容易出并发问题和重复问题的点。两个学生同时点击同一个互助单的接单按钮，如果代码只做了“状态判断”而没有加锁，最终结果可能出现两个人都显示接单成功，但由于单子的 receiver_id 只有一个，数据库会更新两次，第二次覆盖第一次，造成数据错乱。我的解决方案有两层：第一层在 help_order 表上加乐观锁版本号字段，更新时带上WHERE status = 'WAIT_RECEIVE' AND version = ?，如果影响行数为 0，则说明已经被抢先；第二层在 Redis 里加一个分布式锁，key 是lock:order:{id}，用 setIfAbsent 加过期时间，成功获取锁的请求才可以继续执行。
当然，分布式锁对于一个毕设项目来说有点重，但我觉得这恰恰是该掌握的东西。因为当你同时为用户增长预留空间时，重复下单问题的概率会显著上升，与其等到答辩时被问“你的接口支持并发吗”才发现没锁，不如一开始就说明掉。具体的代码骨架大致是这个思路：
@Transactional public boolean acceptOrder(Long orderId, Long userId) { String lockKey = "lock:order:" + orderId; Boolean locked = redisTemplate.opsForValue() .setIfAbsent(lockKey, "1", Duration.ofSeconds(10)); if (Boolean.FALSE.equals(locked)) { throw new BizException("订单正在处理中，请勿重复点击"); } try { int rows = helpOrderMapper.updateStatusWithVersion(orderId, HelpOrderStatus.RECEIVED, userId); if (rows <= 0) { throw new BizException("手慢了，该单已被接走"); } return true; } finally { redisTemplate.delete(lockKey); } }注意这里的要点：Redis 锁一定要设过期时间，防止拿到锁的线程崩溃导致死锁；释放锁放在 finally 里；数据库的状态更新是唯一的事实来源，Redis 锁只是降低冲突概率。
4.4 私信与通知：从轮询到 WebSocket
学生互助平台的通知功能不能做成用户每次进来都拉全量通知列表，那样效率太低。我用的是 WebSocket 加 STOMP 协议，前端连接后，后端通过SimpMessagingTemplate.convertAndSendToUser按 userId 定向推送。关键点有两个：第一，WebSocket 握手时要能从 URL 参数或 Header 里解析 token，我实现了一个自定义的 HandshakeInterceptor，在握手前把 userId 放入 session 属性；第二，通知消息落地到数据库 notification 表，WebSocket 只是给它加了一层实时性，不落库的推送是无效推送，因为用户一旦断线就再也收不到。
在私信聊天场景里，我并没有把每条消息实时存数据库，而是通过 WebSocket 直接发送给在线用户，落库操作由消息生产者异步写入。这样聊天的实时性有保障，数据库的压力也小。对离线用户，私信会在 Redis 里缓存最近心跳时间，前端进页面后主动拉取离线期间未读消息数。这个设计思路不算新，但确实是学生项目里很少见到的完整实现。
5. 开发过程中真正踩到的坑
5.1 列表页 N+1 查询：一条 SQL 解决不了的事
互助单列表页一开始展示很正常，但用户量和数据量上来之后，响应时间从 50ms 飙升到了 900ms 多。通过日志分析，我发现每一行互助单都要额外查一次发布者昵称、一次分类名称、一次接单者头像，三条 SQL 在一页 20 条数据时就是 60 多次查询。这就是典型的 N+1 问题。
解决方法是把列表页从单表查询改成一次联表查询，用 MyBatis-Plus 的 mapper 自定义 SQL，把 user 表和 category 表联进来，一次性查出列表所需的全部字段。这里要注意，联表查询出来的字段要映射到专门的 HelpOrderVO，而不是直接塞进 Entity。如果你有需要频繁变化的组合字段，可以在 VO 里用@TableField(exist = false)标记为非表字段，这样查询和返回都很干净。
5.2 事务不回滚带来的积分账目不平
我前面提到积分结算要在一个事务里完成。开发时我就栽在这上面：发布者点击“确认完成”，我写了一个方法，先更新互助单状态，再调用积分服务扣减和发放，最后写积分流水。看起来逻辑没问题，但测试时发现，如果积分流水写入失败，前面的状态更新和积分扣减不会回滚。原因是我没有在方法上标注@Transactional，这个方法实际上在两个事务里执行了。
更隐蔽的问题是，@Transactional默认只回滚 RuntimeException 和 Error。某个分支我抛的是自定义异常，继承的是 Exception，结果事务静默提交了。排查了很久才想起来 Spring 的事务规则。解决办法是自定义异常继承 RuntimeException，或者在注解上显式写@Transactional(rollbackFor = Exception.class)。
5.3 分页查询的 count 查询太慢
学生端首页使用了分页组件，每页 10 条。MyBatis-Plus 会自动生成SELECT COUNT(*) FROM ...的 count 语句，但在一些带复杂 WHERE 条件的查询里，count 的速度远慢于实际数据查询。尤其是筛选条件里加了对 JSON 字段的模糊匹配后，count 直接跑出了 2 秒。我的优化办法是：去掉不必要的 count，如果数据量在可控范围，让前端用“加载更多”代替页码分页，每次只查询下一批 10 条数据，不需要 count。或者对 count 语句做简化，只数主键，避免它扫描全字段。
5.4 用户越权：前端隐藏不等于后端安全
开发接单接口时，一开始我在前端根据状态隐藏了接单按钮，以为用户不能操作就安全了。后来做安全性测试，用 Postman 直接往后台接口发请求，发现只要给一个 WAIT_RECEIVE 状态的互助单传任意 userId，就能把 receiver_id 改成别人。这就是典型的越权漏洞。我修复的方案是在所有涉及资源操作的接口里增加归属校验：查一下当前登录的 userId 是否等于资源的 publisher_id 或 receiver_id，不相等就抛出 403。
这和权限角色的判断还不一样，它是数据级权限控制。学生项目里通常涉及大量“我的订单”“我发布的”这类查询，如果只过滤前端展示而不在后端参数校验，直接用一个循环脚本就能刷遍全站数据。在这里我的经验是：过滤器里处理登录状态，拦截器里处理角色权限，每个 service 方法里处理资源归属，三道防线缺一不可。
5.5 文件上传引发的内存溢出
头像上传功能最初用 MultipartFile.transferTo() 直接写入本地目录，看似没问题。但有一次用户上传了一个 200MB 的视频文件伪装成图片，导致 Tomcat 默认的临时目录瞬间被打满，应用直接 OOM 重启了。处理方式是三层：限制文件大小（图片不超过 5MB，文件不超过 20MB），限制 MIME 类型和扩展名，然后把上传文件放到 OSS 或 MinIO 这样的对象存储里。本地目录只保留临时文件和压缩后的小尺寸缩略图。毕设项目不一定要引入 OSS，本地 MinIO 就用 Docker 跑一份，代码逻辑和企业场景是一致的。
6. 部署到服务器之后的优化与复盘
6.1 部署方案：一台学生服务器够不够
这个项目我最后部署在腾讯云轻量应用服务器上，2 核 4G 配置，系统 Ubuntu 22.04。部署用 Docker Compose 编排了三个容器：MySQL、Redis、后端应用。前端产物用 Nginx 镜像单独起一个容器跑，再用 Nginx 的 location 规则把/api前缀的请求反向代理到后端容器。这个方案的好处是干净且容易迁移，如果你想在答辩现场演示，只需要在一台新服务器上执行docker compose up -d --build，几分钟内就能拉起整个环境。
关于进程守护，容器本身有自动重启策略restart: unless-stopped，后端应用不需要额外装 supervisor 之类的东西。但有一个关键点：Spring Boot 的application.yml里数据库密码、Redis 密码这些敏感配置，不能写死在镜像里。我通过环境变量注入：在 application.yml 里写${DB_PASSWORD}占位符，在 docker-compose.yml 的 environment 里配置。这样做既保证配置灵活，也不会把密码提交到 Git 仓库。
6.2 缓存与索引：从列表响应看性能调优
首页互助单列表在数据库里加了联合索引(category_id, status, create_time)，查询逻辑是先按分类过滤，再按状态过滤，最后按时间倒序。加了索引后，同样一条查询语句的执行计划从全表扫描变成了索引范围扫描。Redis 缓存我并没有直接缓存整个列表，因为互助单是强动态数据，接单状态一变列表就要更新，缓存一致性反而会成为负担。我只缓存了热点分类的统计数量和前三名活跃用户，这两部分数据不会被频繁修改，缓存命中率很高。
另外，我配置了 MyBatis-Plus 的二级缓存吗？没有。原因是在多表关联和实时状态修改场景下，二级缓存很容易出现脏数据，一个更新操作下去，缓存没有及时失效，用户看到的就是旧状态。考虑到系统的并发量并不高，数据库加索引后的响应时间已经在 200ms 以内，我选择放弃二级缓存，用 Redis 做定向缓存来保证一致性，这个取舍我觉得是合理的。
6.3 用户反馈驱动的下一轮迭代方向
平台在测试环境跑通后，我邀请了几十个同学真实验收，最有价值的反馈有三个。第一个是“发布互助单时不知道应该写多详细”，前端需要提供示例文案和字段提示；第二个是“接单者完成之后发布者忘记确认，积分迟迟不到账”，我后来加了一个 72 小时未确认自动完成机制，同时给发布者推送提醒；第三个是“希望有‘同班同学优先匹配’的选项”，这是比校区更细粒度的匹配维度，在校园场景里确实很有意义。
这几个反馈说明，学生互助平台的难点其实不在技术，而在于对业务细节的洞察。技术上，所有问题都能被标准化处理，但用户是否愿意持续使用，取决于你是否理解了“学生互助”这件事的真实心理：人们想得到帮助，更想在帮助别人的过程中获得对自我的认可。所以下一轮迭代我会重点打磨信用画像：接单者的响应速度、完成质量、活跃时间段都会变成可视化的标签，让“靠谱”这件事变得可感知。
从最初“木成林”的命名联想，到“学林互助”的功能骨架，再到“林聚学”式的地域匹配，整个开发过程让我最有成就感的地方，不是某张表设计得有多规范，也不是接口写得有多精准，而是真的看到有同学在平台上找到了同门的学长借到操作系统课设的参考资料，还有人在上面发布考研搭子匹配成功。这种互助闭环的形成，说明最初的产品假设是被验证了的。如果你也准备做类似的毕业设计，我建议你先问自己一个问题：这个平台是只为了展示 CRUD，还是真的想解决校园里那个让你不舒服的痛点？想清楚这一点，代码怎么写、框架怎么选都会顺很多。
