基于Spring Boot与微信小程序的校园生活服务平台开发实战

1. 项目定位校园生活服务到底要解决哪些问题这两年我接手过的校园类后台项目十个里至少八个是“基于Spring Boot 微信小程序”的组合。这个标题看起来长其实拆开就三层意思前端用微信小程序做载体后端用Java和Spring Boot做服务场景锁定在校园大学生生活和学习两类需求上。说实话这种项目在毕业设计、课程设计和一些小公司的接单项目里出现频率非常高但大部分做出来都是“能跑但不好用”的状态。我这次把整套从设计到落地的过程完整梳理一遍重点讲清楚为什么这么做、哪些地方容易踩坑。先说清这个平台能干什么。所谓“生活学习服务”落到具体功能上通常包括校园二手交易教材、数码产品、宿舍小电器、失物招领、课程表查询、考试安排提醒、校园社团活动信息发布、自习室占座状态查询。看似功能很多但普遍做法是分模块开发后端一套接口服务全部业务小程序端按TabBar划分入口。用户对象非常明确就是本校学生和少量教职工所以不需要复杂的多租户设计只需要做好“校内实名认证”和“按院系、按年级维度的信息过滤”。从需求角度来说这类平台真正核心的痛点不是技术复杂而是信息分散、供需不对称。比如二手教材交易过去靠QQ群转发靠墙上的小广告现在把它收拢到一个平台上用微信免登录直接打开成本极低。再比如失物招领如果能让拾取者拍照上传、失主按关键词检索匹配效率会大幅提高。这些业务逻辑都不难难点在后面怎么把多个模块塞进一个系统里不臃肿怎么在鉴权、状态机、数据隔离这些细节上不搞出漏洞。所以这篇文章的定位不是“从零手把手写代码”而是带着你从全局视角做架构决策和核心模块设计。适合谁看一种是正在做毕业设计、需要快速搭出一个可演示效果的大学生另一种是刚接触Spring Boot实际项目、想知道真实项目的模块划分和坑点在哪的开发者。我会把数据库设计、登录鉴权、核心接口约定、常见故障排查这些都展开讲可以直接“抄作业”的地方我会明确标出来。2. 技术选型与整体架构方案对比2.1 为什么优选Spring Boot 微信小程序而不是Web网页方案先说结论微信小程序 Spring Boot 是目前校园类轻应用里投入产出比最高的组合没有之一。原因分三层。第一层是流量入口。大学生群体是微信重度用户小程序不需要下载安装扫码即可打开。相比传统Web应用小程序有天然的传播优势尤其在校园这种熟人密度很高的环境里一个宿舍群、一个班级群转发一次就能覆盖相当大比例的潜在用户。如果做成H5网页用户得先收藏网址下次想用的时候找不到入口留存率会很差。第二层是开发成本。Spring Boot的生态太成熟了做校园项目几乎不需要引入复杂框架。Spring MVC处理接口MyBatis-Plus做数据访问Redis做缓存和验证码JWT做无状态鉴权这些组合在一周内就能搭好骨架。微信小程序端更是如此一个TabBar页面模板就能覆盖绝大多数场景。第三层是审核准入门槛。校园类目在微信公众平台属于“教育”或“生活服务”类目个体工商户甚至个人主体都可以申请App类项目则需要软著等材料时间成本高很多。小程序在资源这一环就帮你筛掉了大量竞争对手。如果非要用Web方案比如“Spring Boot Vue”管理后台配用户端网页会遇到两个问题一是移动端适配要看屏幕尺寸、要做响应式布局工作量直接翻倍二是没有微信原生登录能力得自己去搞短信验证码或账号密码体系还得操心密码加密存储、找回密码邮件服务等一系列麻烦。微信登录帮我们省掉的不仅仅是代码量更是一整套密码学相关的合规问题。2.2 项目目录结构与后端分层设计后端项目我用的是传统四层结构Controller、Service、Mapper、Entity完全基于Spring Boot的主流规范不用奇怪的架构避免给后来接手的人添堵。大概是这样com.example.campus ├── config # 全局配置跨域、拦截器、Redis配置等 ├── controller # 接口层 │ ├── auth # 登录、注册、token刷新 │ ├── trade # 二手交易模块 │ ├── lostfound # 失物招领模块 │ ├── schedule # 课程表模块 │ ├── announce # 资讯与活动模块 │ └── user # 用户信息管理 ├── service # 业务逻辑层接口 实现 ├── mapper # 数据持久层MyBatis-Plus ├── entity # 数据库实体对象 ├── dto # 前端入参/返回参数封装避免直接用实体类接收 ├── vo # 视图对象给前端展示的聚合数据 ├── utils # 工具类JWT工具、时间工具、课表节次转换等 └── common # 统一返回结果、异常封装、枚举常量这个结构看着普通但越是这种“普通结构”越能承载后续的范围膨胀。项目做到中期最怕的是 Controller 里塞业务逻辑Service 里塞SQLEntity 挂一堆前端字段。我见过不少校园项目就是在代码乱掉之后崩的。前端小程序目录我习惯分两类一类是pages页面目录一类是utils公共方法目录。页面用分包不要把所有东西都装到主包不然微信小程序的主包2MB限制很容易超。常见的做法是把「二手交易」「失物招领」这种比较重的页面放进分包主包只留首页和登录相关页面。这个细节很多人忽视到打包上传的时候才来砍功能非常被动的。2.3 统一返回结构与异常处理的设计究竟有多重要做接口设计时最容易犯的一个错误是每个接口自定义返回格式今天返回一个{code:1, data:...}明天另一个接口返回{success:true, message:...}。一旦前后端联调这就是灾难。我在这个项目里统一用一个Result类来收敛Data public class ResultT { private Integer code; private String message; private T data; public static T ResultT success(T data) { ResultT result new Result(); result.code 200; result.message success; result.data data; return result; } public static T ResultT error(Integer code, String message) { ResultT result new Result(); result.code code; result.message message; return result; } }配合全局异常处理器业务里任何地方只要抛出ServiceException就会自动被拦截并转换成统一的错误JSON返回前端。这样前端只需要在request封装里统一判断code字段不需要每个页面都写一遍错误处理逻辑。提示统一返回结构不是“代码洁癖”这是多端联调的地基。小程序端的基础函数wx.request是需要封装公共逻辑的如果后端返回结构不统一那这个公共封装就无从谈起每个页面都要自己处理JSON字段代码量和出错率直线上升。2.4 数据库表设计的核心思路校园平台的用户量级一般在一万到十万之间不需要做分库分表这类高复杂度设计但要保证表的划分清晰、索引合理、字段命名规范才能支撑后续功能演化。我的表设计大致如下用户相关sys_user用户主表、user_auth微信OpenID绑定、user_profile学号、院系、年级等扩展信息。交易相关trade_item商品发布表、trade_category分类表、trade_order交易订单表、trade_favorite收藏表、trade_report举报信息表。失物招领相关lost_found主表含拾取/寻回状态、lost_image图片附件表。学习相关course_schedule课表数据、exam_remind考试提醒、study_reserve座位预约记录。资讯相关notice_info资讯公告表、club_activity社团活动表、activity_enroll活动报名表。这里特别提醒几个细节问题第一sys_user和user_profile为什么拆开因为微信登录产生的初始数据非常少只要一个OpenID和UnionID其余信息都是用户后续慢慢补充的。如果一开始把几十个可能为空的字段放在主表上表结构会很膨胀也不方便扩展。第二所有业务表都建议加status字段和create_time、update_time字段。status字段的作用在校园项目里尤其明显比如二手商品有“在售、已下架、交易中、已卖出”四种状态失物招领有“未认领、已认领、已过期”三种状态这些状态一旦没有明确枚举代码里到处是魔法数字后期维护会非常痛苦。第三图片不要存二进制到数据库把图片传到对象存储或服务器磁盘数据库只存URL字符串。校园项目的图片量不会大到撑爆存储但如果你把图片写进数据库接口查询时会拖慢整体响应而且数据库备份文件会急速膨胀。业务的查询模式和核心字段二手商品按category_idstatus组合查询所以需要联合索引失物招领按type遗失/拾到和keywords物品名称关键词查询建索引时重点照顾这两个字段课表按user_id和week查询走单字段索引即可。这些索引规划要在建表初期完成等数据量大了再补成本会翻倍。3. 微信登录鉴权与用户体系搭建全流程3.1 微信小程序登录流程从code到openid的链路解析微信小程序登录不是网页网页的那种session机制它有自己的完整链路。小程序侧调用wx.login拿到一个临时凭证code这个code有效期只有5分钟而且只能用一次。然后把code通过后端接口传给我们的服务器由服务器向微信接口发送请求换取openid和session_key。这个过程的时序是这样的小程序前端wx.login()获取临时code。前端把 code 通过wx.request发给后端/api/auth/login。后端拿着 code appid secret 去请求微信的jscode2session接口。微信返回 openid、session_key、unionid如果已绑定开放平台。后端用 openid 查询数据库如果不存在则自动注册新用户如果存在则更新最近登录时间。后端生成自定义登录凭证比如JWT token返回给前端。后续所有请求都带上 token后端通过解析token识别用户身份。有一个常见误区有的新手想自己拼接 appid 和小程序的wx.login返回的 code 做校验这是不对的。code 必须通过后端服务器到微信服务器换取不能在小程序端直接解密。微信服务器要求请求必须携带appid和secret这两个东西不能暴露在小程序代码里一旦被反编译泄露会出大问题。代码上后端登录接口大概是这样的PostMapping(/login) public ResultUserVO login(RequestBody LoginDTO dto) { // 1. 调用微信接口用code换openid WxLoginResponse response wxService.code2Session(dto.getCode()); if (response.getOpenid() null) { throw new ServiceException(50001, 微信登录失败); } // 2. 根据openid查用户查不到就注册 SysUser user userMapper.findByOpenId(response.getOpenid()); if (user null) { user new SysUser(); user.setOpenId(response.getOpenid()); user.setStatus(1); userMapper.insert(user); } // 3. 生成JWT token并返回 String token jwtUtil.generateToken(user.getId(), user.getRole()); UserVO vo new UserVO(); vo.setToken(token); vo.setUserInfo(user); return Result.success(vo); }3.2 会话保持与Token方案选型JWT还是传统Session传统Web项目里常用SessionCookie做会话保持但小程序不支持Cookie机制虽然wx.request可以手动设置header但每次请求都要自己带着Cookie操作很别扭。更关键的是如果后端做了负载均衡部署Session存在单台服务器内存里会导致其他服务器不认识这个用户。所以这个项目我选JWTJSON Web Token。JWT自带用户身份信息服务端不需要存session天然适合前后端分离和无状态接口设计。生成JWT时我在payload里放了userId和role两个核心字段过期时间设置为7天。小程序端把token存到wx.setStorageSync每次请求从本地读取并放在请求头Authorization: Bearer token。具体拦截器实现public class AuthInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 放行登录接口和公开接口 String uri request.getRequestURI(); if (uri.startsWith(/api/auth/) || uri.startsWith(/api/public/)) { return true; } // 校验token String token request.getHeader(Authorization); if (StringUtils.hasText(token) token.startsWith(Bearer )) { token token.substring(7); } try { Long userId jwtUtil.parseToken(token); request.setAttribute(userId, userId); return true; } catch (Exception e) { response.setStatus(401); response.setContentType(application/json;charsetUTF-8); response.getWriter().write({\code\:401,\message\:\登录已过期请重新登录\}); return false; } } }注意JWT最大的坑是“无法主动让某个token失效”。用户退出登录时前端把本地token删除就行但服务端并不知情。如果遇到需要封禁用户的需求只能在数据库里加一个用户状态字段查询时校验状态或者把token的版本号存到Redis每次请求先查版本号不一致就拒绝。校园项目一般用不上这么复杂但你要知道有这个坑存在。3.3 手机号快速验证组件获取微信绑定手机号的方式很多校园平台有“绑定手机号”的需求比如发布商品时预留联系方式。微信官方提供了一个button open-typegetPhoneNumber的能力不需要用户手动输入手机号而是让用户确认授权直接获取微信绑定的手机号。但这个接口有调用成本个人主体的小程序不一定能过审而且新规则下需要支付认证大部分校园毕设项目是用不到的。更稳妥的做法是用户在小程序里自行填写手机号后端用正则校验手机号格式必要时加一个短信验证码。校园项目可以不接短信服务用“学号姓名”验证就已经能挡住绝大多数机器人。为什么这么说因为校园平台的核心信任基础是“你是本校学生”而不是“你有个合法手机号”。如果实在需要手机号也不是必须自己对接短信服务商。注册一个支持短信验证码的服务商控制成本也就几十块钱。但接过来的代码量不大核心逻辑就是在Redis存验证码、设置5分钟过期时间、校验不区分大小写、错误次数限制这些加在一起也就百把行代码。3.4 用户实名认证与学号校验的轻量方案校园平台经常遇到的问题是怎么确认用户是本校学生对接教务系统需要拉取真实学号数据但在毕设阶段或者小型项目中不现实。我的做法是做一个“轻量实名认证”用户在个人中心输入学号 姓名 院系后端把这个信息存入数据库但不做权威验证。这样做的意义在于提高发布门槛减少恶意用户而不是真正防住人肉。如果要升级有一个折中方案创建一人一码的“邀请码”可以找辅导员批量生成后发到各班群用户注册时必须填入邀请码。这比学号校验更轻但已经能建立基本的信任体系了。校园场景尤其适合这种低成本信任方案因为你需要的是“大部分人都是真实学生”而不是“100%防住所有刷子”。4. 核心业务模块的功能拆解与接口实现细节4.1 二手交易模块状态机与幂等设计的落地二手交易是这类平台里最活跃的模块也是最能体现设计功底的地方。核心流程用户发布商品 → 商品审核可选 → 其他用户浏览/收藏 → 买家下单 → 双方线下交易或校内自提 → 卖家确认完成 → 交易闭环。中间还穿插了“下架、举报、删除”等异常情况。商品表trade_item的核心字段字段名类型说明idbigint主键user_idbigint发布者IDcategory_idint分类IDtitlevarchar(100)商品标题descriptiontext商品描述pricedecimal(10,2)价格original_pricedecimal(10,2)原价参考用imagesvarchar(1000)图片URL多个用逗号分隔statustinyint1在售 2已下架 3交易中 4已卖出view_countint浏览量冗余设计create_timedatetime发布时间update_timedatetime更新时间这里重点讲状态流转。商品的状态不能只用一个字段简单存而是要有明确的流转约束1在售可以流转到 2下架、3交易中或 4已卖出2下架只能流转到 1在售或直接删除3交易中只能流转到 4已卖出4已卖出不能再改任何状态我用switch做状态校验如果非法流转直接抛异常public void changeStatus(Long itemId, Long userId, Integer targetStatus) { TradeItem item tradeItemMapper.selectById(itemId); if (item null || !item.getUserId().equals(userId)) { throw new ServiceException(40003, 无权操作该商品); } switch (item.getStatus()) { case 1: if (targetStatus ! 2 targetStatus ! 3 targetStatus ! 4) { throw new ServiceException(40004, 商品状态流转非法); } break; case 2: if (targetStatus ! 1) { throw new ServiceException(40004, 已下架商品只能重新上架); } break; case 3: if (targetStatus ! 4) { throw new ServiceException(40004, 交易中商品只能确认完成); } break; case 4: throw new ServiceException(40005, 商品已卖出无法变更); default: throw new ServiceException(40006, 未知状态); } // 更新状态 更新时间 item.setStatus(targetStatus); item.setUpdateTime(LocalDateTime.now()); tradeItemMapper.updateById(item); }发布商品这个动作还需要注意一个细节发布前必须判断用户是否已完成实名认证即填了学号、姓名否则不允许发布。校园平台的商品帖子里不能留不明联系方式所以我们在页面上会做一层“联系TA”的引导点击后通过内置聊天或电话拨打的方式而不是直接明文展示手机号减少骚扰。幂等问题用户快速连点“发布”按钮可能会产生重复商品。小程序端可以做一个节流禁用按钮1秒后端则可以用idempotent_key字段比如用户ID时间戳商品标题Hash做唯一约束插入时如果冲突则直接报“请勿重复提交”。浏览计数view_count并不需要强一致所以不做锁直接UPDATE trade_item SET view_count view_count 1 WHERE id ?天然防并发叠加比先查后改更正确。4.2 失物招领模块状态设计与关键词检索技巧失物招领是一个看起来简单、实际“公共字段设计”特别容易出错的功能。表结构上我用两条记录来表示两个方向type1表示“我丢了东西”type2表示“我捡到了东西”。两个方向共用一张表查询列表时通过type字段分开。关键设计点是一条失物记录的status不应该是“认领了就不可见”而应该分两条线来处理遗失方向未找回 → 已找回拾到方向待认领 → 已认领 → 已过期超过30天没人来这两个方向的所有者不同失主发起的是“寻找帮助”拾到者发起的是“提供帮助”。当失主看到有一件“拾到”物品和自己丢失的物品描述很接近时可以发起认领申请拾到者收到消息后采取线下核实比如提供购买凭证、说出物品特征等核实通过后状态改为“已认领”。认领申请会产生一张claim_apply表包含id, lost_found_id, apply_user_id, apply_reason, status(0待审核 1通过 2拒绝), create_time, update_time“关键词检索”是这个模块的高频入口。用户丢失了校园卡通常会在首页搜索框直接输入“校园卡”“饭卡”“一卡通”等词。我的实现是用MySQL的LIKE %关键词%配合字段keywords做冗余存储。发布时后端自动从标题和描述中抽取关键词比如“蓝色”“卡套”“图书馆”加上用户手动填写的标签组合到一个字段里。搜索时用WHERE keywords LIKE CONCAT(%, ?, %)。这种做法的检索速度在几千条数据下完全够用而且实现成本极低。只有数据量到百万级时才需要考虑Elasticsearch或者普通的全文索引校园项目大概率到不了这个量级。图片在这个模块里特别重要。失物招领的图片和二手商品的图片不同失物图片通常只有一两张而且目的是“让失主认出来”所以要保证原图上传后不被压缩太狠小程序端压缩设置要放宽。我建议存储时保留原图展示时用压缩图这样既能加快列表加载速度又不影响细节识别。4.3 课程表模块周次计算与节次换算的通用实现课程表在大学校园项目里是一个经典功能但很多人第一次做会卡在时间换算上。大学课程表通常以“周次 星期 节次”来定义比如“第8周周三第3-4节在xxx教学楼上课”。后端接口要做的事情有两件事一是将前端传来的学期起始日期换算成“当前是第几周”二是将“周几 节次”换算成具体的日期和时间点。学期的开学日期一般放在配置表或常量里比如semester_start_date。前端只需要把当前时间传过来后端用ChronoUnit.between()算差值public int getCurrentWeek(LocalDate today, LocalDate semesterStart) { long days ChronoUnit.DAYS.between(semesterStart, today); int week (int) (days / 7) 1; return Math.max(week, 1); }节次换算的核心是“每节课的开始时间和持续时间”每个学校都不一样通常配置成一个常量数组。例如public static final String[][] SCHEDULE_TIME { {08:00, 08:50}, // 第1节 {09:00, 09:50}, // 第2节 {10:10, 11:00}, // 第3节 {11:10, 12:00}, // 第4节 {14:00, 14:50}, // 第5节 {15:00, 15:50}, // 第6节 {16:00, 16:50}, // 第7节 {18:30, 19:20}, // 第8节 };这里有个容易错的地方第3节课前面有个大课间第7节和晚间的第8节之间也有间隔所以不能简单用08:00 n*50分钟来推算。要直接用配置数组每个节次的开始时间独立写而不是公式推导。不然遇到上午第二大节的错位整张表就全乱了。课表数据从哪来两个渠道一是对接教务系统解析课表但大多数学校的教务系统接口不对外开放且验证码、加密搞得很复杂。二是手动录入/导入Excel管理员在后台导一份统一模板的Excel后端解析后按学号批量写入course_schedule表。毕设项目用方案二完全够验证码破解的工作量足以再做一个项目。4.4 资讯公告与社团活动模块消息推送的取舍资讯和活动模块本质上是管理员发布公告、社团发布活动、学生浏览报名技术上是典型的CRUD不复杂。但这里有一个业务取舍问题要不要做消息推送微信小程序给用户发订阅消息需要用户主动点击授权“允许通知”且每次授权只能发一次用户重新授权后才能再发一条。这意味着你不能像公众号那样持续推送。校园项目里我能接受的推送场景是失物招领认领申请通过时、二手物品被下单时、活动报名成功时。其他场景的推送要克制因为用户一旦觉得被打扰下次就不会再授权了。订阅消息的后端调用逻辑也比较简单用户授予订阅消息权限后小程序端会把touser用户的openid和消息模板ID发给后端后端拿到后调微信接口推送。有一个坑是一次前端调用最多只能订阅三条消息如果用户需要订阅多种通知小程序端要做多次授权。活动模块里有一个高频需求是“名额限制”我用stock字段记录剩余人数报名时用乐观锁更新int updateCount activityMapper.reduceStock(activityId, 1); if (updateCount 0) { throw new ServiceException(40010, 活动名额已满); }UPDATE club_activity SET stock stock - 1 WHERE id ? AND stock 0这种写法天然防超卖不需要分布式锁校园项目的并发量完全够用。5. 常见问题与排查技巧实录5.1 高频故障一览表以下这些问题我做的校园项目里几乎每个都会出现而且各有各的“隐蔽性”。整理成表方便对号入座问题现象根因分析解决方案用户登录成功但接口返回401JWT过期或token未放进请求头检查请求拦截器确认每次请求都从storage读取token适当延长token有效期到7天发布图片后列表不显示图片图片URL是相对路径前端无法拼接完整域名后端返回绝对路径域名路径或前端统一加BASE_URL前缀小程序真机调试正常预览版接口报错后端域名没有加到微信公众平台合法域名列表或没配HTTPS到小程序后台配置request合法域名必须为HTTPS并校验域名证书课表显示周次错位后端使用了默认时区导致日期差一天数据库连接串后加serverTimezoneAsia/Shanghai实体用LocalDateTime而非Date失物搜索无结果关键词存的是“校园卡”用户搜的是“饭卡”同义映射缺失发布时自动把别名饭卡、一卡通合并进keywords字段二手商品下单后状态不一致买家点击下单时没有声明事务多个操作部分成功Service方法添加Transactional同时校验商品owner不能是买家自己用户举报后商品仍可展示举报状态只改了举报表没联动商品表status举报通过后由管理员手动下架或定时任务自动扫描举报表中待处理记录5.2 关于事务失效的几个隐藏点校园项目里会用到事务的地方很多发布商品时同时更新用户发布数、下单时同时改商品状态和创建订单、报名活动时同时扣减名额和写入报名记录。但Spring的Transactional有三个非常容易踩的坑我专门标出来第一个坑是自调用失效。同一个类里方法A调用方法BB上有TransactionalA上没有那B的事务不会生效。因为Spring事务是通过代理对象调用的A内部直接调用B绕过了代理。解决办法是把事务方法单独放到另一个Service类或者用Autowired注入自身代理。第二个坑是异常被吞掉。事务只在遇到RuntimeException时回滚如果代码里不小心catch了异常并正常返回事务不会回滚。要养成习惯有事务的方法不要吞异常要么抛出要么用TransactionTemplate手动圈定范围。第三个坑是跨表更新时没有指定事务传播行为。多个Service嵌套调用默认的REQUIRED会加入外层事务这是正确的但有些人图省事把两个Service内的数据更新都拆开调用导致只有部分提交成功数据不一致。校园项目规模不大优先保证所有跨表更新都放进同一个事务方法里。5.3 小程序端常见的小毛病后端排查完了还有前端问题。小程序端最常见的两个低级错误都容易在联调阶段浪费一整天。第一wx.request方法默认使用GET请求如果不显式声明method: POST后端接口正好只接受POST前端就会一直收到“请求方法不允许”。尤其是复制粘贴别人的代码时最容易漏掉method。第二数据回显时的字段名不一致。后端返回userId小程序里写成了userid前端拿到的是undefined导致页面渲染不出用户信息。这个问题的标准解法是后端统一使用前端约定的命名规范比如全部小驼峰或者前端用一个transformResponse函数统一处理字段映射。我后来给自己定的规矩是前端写接口调用前先打印一遍返回结果确认字段名再写页面逻辑。5.4 性能与安全检查你的接口真的“干净”吗校园平台的并发量不高但接口性能和安全问题还是要提前扫掉。我每次做完一个模块都会过三遍第一遍是慢SQL检查。把每个查询的where条件、order by字段过一遍确认都建了索引。比如商品列表如果要按create_time倒序取最新就得建一个(category_id, status, create_time)的联合索引纯单字段索引会让排序退化。第二遍是越权检查。修改操作必须判断当前登录用户是否资源所有者或管理员是否有权限。尤其要注意“批量操作”的接口比如删除商品如果只传了一个id数组一定要逐个校验所有权不能用一个where id in (...)一次性删掉所有人的商品。第三遍是图片上传安全检查。如果用了对象存储要检验文件类型不能只看文件名后缀还要看文件内容头MIME。图片如果支持SVG上传SVG里头可以直接塞脚本会存在存储型XSS风险。我的做法是上传时统一转换为jpg/png去掉SVG支持。后端可以用ImageIO.read()做一次解码验证能正常解码才算通过。6. 部署上线与运营层面的避坑指南6.1 域名、备案与HTTPS的三步落地微信小程序正式版有一个硬门槛所有请求域名必须是HTTPS且域名必须完成ICP备案并配置到小程序后台的合法域名列表里。这一步卡住了很多人的上线计划因为它不是纯技术问题而是流程问题。我自己的部署顺序是买服务器 → 买域名 → 域名备案 → 服务器装Nginx和JDK → 用Nginx托管Spring Boot反向代理 → 申请SSL证书并配置HTTPS → 启动后端服务 → 小程序后台配置合法域名 → 提审发布。这里把“域名备案”放到很前面是因为备案审核通常需要好几天的周期如果等到项目全部做完才去申请会白等很久。大学实验室如果有已备案的域名可以直接用省很多事。关于SSL证书一个小建议第一次没有必要买付费证书用平台提供的免费DV证书就够了。配置Nginx时要注意强制HTTP跳转到HTTPS否则用户通过http访问时接口会报错排查起来很费劲。6.2 小程序的类目与审核注意事项校园服务平台的类目选择会影响审核通过率实名推荐的路径是“教育 教育信息服务”或“生活服务 生活综合”。提审时需要注意几个细节第一隐私政策必须有。小程序后台要求填写用户隐私保护指引比如收集用户微信昵称、头像、手机号、学号等信息都需要在隐私政策中说明用途和存储期限。这个文案可以自己写但一定要真实。第二图片素材不能侵权。小程序图标、启动页、宣传图里不能用别人的商标、名人照片、未授权的海报审核人员对这块盯得很紧连“某某大学的校徽”都可能因为版权问题被拒。第三类目一致性。比如你的小程序叫“校园生活”里面的功能只有二手交易和失物招领这没问题。但如果还包含了“在线订餐”“外卖配送”就可能被要求切换到“餐饮”类目需要额外提供许可证。所以功能范围最好在命名和类目申请时保持一致。6.3 上线后的数据观察与迭代方向项目上线只是开始真正校验设计好不好的是使用数据。我建议在上线后的一两周内重点看三个指标第一个是次日留存率。校园工具类小程序的次日留存如果低于15%说明用户没有找到持续使用的理由。这时候就需要考虑加一些“上瘾”机制比如每日签到、积分系统、二手商品的“求购”信息流。第二个是发布-成交转化率。二手模块的成交流程长用户发布之后是否有人浏览、是否有收藏、是否最终成交这个漏斗能暴露问题。如果浏览量很高但成交率低大概率是撮合机制有问题比如联系方式隐藏太多、线下交易流程没有明确引导。第三个是失物找回率。这个指标比较特殊但很有价值。每次失物招领被用户标记为“已找回”都说明平台的信任机制和撮合能力在起作用。如果这个比例长期为零就得考虑是不是搜索关键词做得太差或列表排序方式导致信息被淹没。迭代方向上校园项目的天花板在于能否“沉淀学长学姐的离校信息”。比如二手教材为什么做得好因为每年毕业季都有大量书籍要处理。如果能在这个场景做好“批量发布”“按课程名称打包卖”就会比普通二手平台更贴合校园使用习惯。同理如果想增加社交属性可以做一个“同专业同学”或“同宿舍楼”的组队学习功能但这类功能要谨慎做避免触及隐私问题。数据库层面上线后建议加一个定时任务每天扫描过期失物超过30天自动标记“已过期”、下架超90天未成交的商品避免信息流里垃圾数据堆积。这类定时任务用Spring的Scheduled注解就能实现配合简单的update语句即可只需要注意设置合理的执行时间不要在高峰期占用数据库负载。7. 我的个人体会与一些补充建议这个项目前后做了将近两个月中间推翻过两次方案。第一次是放弃用纯Vue做Web端转向微信小程序第二次是放弃给每个业务模块单独建用户表统一收拢到sys_user一张主表加不同扩展表。每次推翻都带来了明显的简化也让整个项目变得更“像一个正经项目”而不是玩具。我最想强调的一点是校园类项目的核心不在技术多高深而在关系梳理是否清晰。用户、商品、失物、课程、活动这些实体之间的关系搞清楚了代码怎么写都不会跑偏关系没理清再牛的框架也救不了。写代码之前画一张简单的业务关系图谁拥有什么谁能修改什么状态什么情况下会产生消息通知比直接写Mapper要重要得多。最后给新手一个建议别一上来就想着做“全功能平台”。先把手动录入课表、二手发布、失物搜索这一条闭环跑通再逐步加活动、加订阅消息。功能可以后续迭代但一个能稳定运行的基础架构必须前期打好。我就是因为前期贪多一口气加了六个模块到了联调阶段才发现每个模块都有细碎的边界问题要处理反而拖慢了整体进度。如果一个模块一个模块来每完成一个模块就安排一次完整的前后端联调和自测整个过程会顺畅很多。项目做完后这份“如何拆解一个校园平台”的经验会比多写几百行CRUD代码更有价值因为它代表的是需求分析能力和架构取舍能力这两种能力在任何项目里都通用。