开头如果你在学生时代做过兼职大概率经历过这样的场景招聘信息躺在某个QQ群或者帖吧的角落里真实性全靠运气去现场才发现岗位已经招满遇到纠纷更是连个说理的地方都没有。这就是我选择做“SpringBoot 微信小程序的大学生兼职平台”的直接原因想把信息发布、岗位报名、录取通知、事后评价整条链路放到一个结构化的系统里让找兼职的人和招兼职的人都能少操点心。这个项目从需求梳理到最终跑通大概用了一个半月后端基于SpringBoot前端采用微信小程序原生开发包括登录、兼职发布、多条件检索、报名审核、收藏、消息提醒等完整功能。这篇博文不打算做功能清单式的罗列我会从项目决策和实操细节出发把一个人在独立完成这个项目时最值得注意的技术点、坑点全部摊开来讲希望能给准备做类似校园服务平台的人提供一个可以直接上手参考的路线。老读者可以直接跳到架构和实现部分新手建议从头看每个环节我都尽量给出了可以照用的思路。1. 项目定位先拆清楚大学生兼职平台的核心需求1.1 校园兼职场景的真实痛点与这个项目的机会点校园兼职的需求一直存在但信息流通效率很低。学生找兼职通常靠辅导员转发、班群通知、校内告示板或者零散的中介QQ群。这些渠道最大的问题是什么信息没有结构化。一条兼职信息通常只有一句话描述没有薪酬标准、工作地点、时间要求、联系方式的规范格式学生看完还得自己去私聊、去现场确认整个流程充满不确定性。对发布方来说也一样商家在校内贴个招聘启事来多少人、怎么筛选、怎么通知结果完全靠人肉推进。这个项目的核心价值就是把这些散乱的信息收拢到一个系统里用标准化的数据结构去表达一条兼职信息同时把学生从浏览到报名的动作线上化。一开始我还在犹豫要不要做支付和评价体系后来想清楚了一期版本最核心的闭环是“发布信息 → 浏览检索 → 报名 → 录取 → 通知”先把业务主流程跑通支付、信用评价这些附加能力留到二期。做项目最忌讳一上来就铺大摊子功能边界划得清楚后面才不会写着写着失控。1.2 三类用户角色与一期功能边界的划定大学生兼职平台天然有三方角色学生、岗位发布方、系统管理员。学生端要的是快速找到合适的兼职看到详细的岗位描述方便地报名并查询进度发布方关心的是信息能不能精准触达学生报名的人怎么管理、怎么筛选管理员则要有后台能力去审核岗位和用户保证平台里没有违规、虚假的信息。我在设计时把一期功能限定在一个清爽的范围里。学生端提供微信登录、兼职列表与搜索筛选、岗位详情、在线报名、我的报名记录、收藏岗位、消息通知。发布方提供岗位创建、岗位上下架、报名人员管理、录取或拒绝操作。管理员提供用户管理、岗位审核、举报处理、基础数据统计。这个功能集看起来不小但每个模块之间边界都很清晰底层数据表也容易建模。如果一上来就塞积分系统、聊天功能、在线支付开发周期至少翻一倍而且对核心流程的验证没有任何帮助。2. 技术选型解析SpringBoot 微信小程序的组合逻辑2.1 后端框架选型SpringBoot为什么是稳妥选择做校园类项目后端框架的选择其实很多Python的Django、Node.js的Express都能完成同样的事。但最终选了SpringBoot核心原因有三点。第一生态成熟遇到问题能找到的海量案例最多尤其对于一个人开发的项目来说某个配置不会弄、某个注解想不起来搜一下基本能解决。第二SpringBoot的默认配置和自动装配机制大幅减少了样板代码一个普通的增删改查服务完全不需要自己写配置文件。第三Java在后端领域积累的工程化能力很完整比如事务管理用Transactional就能搞定定时任务用Scheduled几行代码单元测试也有成熟的依赖支持。对于校园兼职这种业务逻辑中包含多个状态流转、需要保证数据一致性的场景SpringBoot提供的抽象工具都恰到好处。我选用的是SpringBoot 2.7版本配合Java 8。为什么不直接上SpringBoot 3因为3.0强制要求Java 17而很多教学环境里的服务器JDK版本还是8或11为了部署和演示方便2.7是兼容性最稳的选择。这个细节看起来不起眼但如果你打算把项目部署到一台共享服务器上JDK版本的冲突会让部署环节非常难受。2.2 前端形态取舍小程序为何优于独立App和H5兼职平台的用户是大学生而大学生使用微信的频次极高。小程序最明显的优势是不需要下载安装扫码或者在微信里直接搜索就能打开传播路径极短。相比独立App省去了应用市场上架的审核和下载安装的转化损耗相比H5页面小程序能获得微信原生提供的登录能力、订阅消息推送能力和内置的组件规范整个用户体感会完整很多。另外小程序端脱胎于微信生态分享给好友、转发到班级群都很顺手非常适合校园场景的社交扩散。当然也要说清楚小程序的局限。微信对小程序包体积有2M的限制图片资源不能随便塞需要靠网络加载部分接口需要在小程序后台配置合法域名个人主体的小程序很多涉及类目权限受限所以如果你只做个人开发测试可能某些功能要申请企业主体才能使用。但综合权衡下来对校园兼职这种高频、轻量、强社交传播的业务场景小程序的综合成本是最低的。开发方面我使用原生小程序框架而不是uni-app或Taro原因是原生框架文档更新及时、真机调试更直接而且这个项目的前端逻辑并不复杂不需要引入跨端框架的额外复杂度。2.3 一个可直接复用的项目目录结构参考项目结构合理后续维护和排错能省很多时间。后端我用了标准的三层结构加模块分包的方式按业务模块而不是按技术层拆分这样改动某个业务功能时能很快定位到相关代码。下面是我的项目目录参考src/main/java/com/xxx/jobhub/ ├── JobhubApplication.java ├── common/ │ ├── Result.java // 统一返回体 │ ├── PageResult.java // 分页返回体 │ ├── BusinessException.java │ └── GlobalExceptionHandler.java ├── config/ │ ├── MybatisPlusConfig.java │ ├── WebMvcConfig.java // 注册拦截器 │ └── RedisConfig.java ├── controller/ │ ├── AuthController.java │ ├── JobController.java │ ├── ApplicationController.java │ ├── FavoriteController.java │ └── MessageController.java ├── service/ │ ├── AuthService.java │ ├── JobService.java │ ├── ApplicationService.java │ └── MessageService.java ├── mapper/ │ ├── UserMapper.java │ ├── JobMapper.java │ ├── ApplicationMapper.java │ └── MessageMapper.java ├── entity/ │ ├── User.java │ ├── Job.java │ ├── Application.java │ └── Message.java ├── interceptor/ │ └── AuthInterceptor.java └── util/ ├── JwtUtil.java └── OSSUtil.java小程序端按页面和组件分好目录miniprogram/ ├── app.json ├── app.js ├── app.wxss ├── utils/ │ ├── request.js │ └── auth.js ├── components/ │ ├── job-card/ │ └── empty-view/ └── pages/ ├── index/ ├── category/ ├── job-detail/ ├── application/ ├── favorite/ ├── message/ └── mine/这种结构在一个人开发时可能感受不明显但如果你需要把代码交给别人接管或者被老师要求进行答辩展示清晰的模块划分本身就是很好的加分项。3. 后端服务端实现从登录鉴权到核心业务流转3.1 微信静默登录与会话保持的完整实现微信小程序的登录流程是整个项目的前置条件几乎每个接口都需要登录态所以这块必须做好。整个流程分四步小程序端调用wx.login()拿到临时code — 把code传给后端接口 — 后端拿着code以及自己的AppID和AppSecret去微信接口换取openid — 后端用openid去用户表查询或注册然后签发一个自定义Token返回给小程序端。后续所有请求都在header里携带Token后端通过拦截器校验。这里最需要注意的一个点是code本身是一次性的而且有效期只有几分钟拿到后必须在后端立刻换取openid不要存储code、不要重复使用。后端换取openid时需要调用微信接口我封装成一个独立的WxService来处理核心逻辑如下public WxSession getSession(String code) { String url https://api.weixin.qq.com/sns/jscode2session ?appid appId secret appSecret js_code code grant_typeauthorization_code; RestTemplate restTemplate new RestTemplate(); String result restTemplate.getForObject(url, String.class); // 使用Jackson解析返回结果失败时记录errcode WxSession session objectMapper.readValue(result, WxSession.class); if (session.getOpenid() null) { throw new BusinessException(微信登录失败 result); } return session; }拿到openid之后我在用户表里按照openid查询找不到就说明该用户是第一次使用直接注册一条新用户记录再生成Token返回。Token我用的是JWT格式核心依赖是io.jsonwebtoken:jjwt。JWT的好处是无状态后端不需要存储会话记录服务器重启也不会影响已经登录的用户。Token过期时间我设置为7天对于校园项目来说让学生频繁重新登录是一种非常糟糕的体验。拦截器的实现也很简单在WebMvcConfig里注册一个继承HandlerInterceptorAdapter的类重写preHandle方法从header里取出Authorization字段解析成功就直接放行失败则返回401。需要注意header字段不要自己改名小程序端和标准HTTP生态统一用Authorization就行。3.2 兼职信息发布、检索与多条件筛选的实现兼职信息的发布是发布方角色的核心操作。发布方提交的表单包含岗位标题、岗位描述、类别、薪酬、招聘人数、工作地点、工作时间、联系方式、图片、以及可选的截止时间。后端接收到之后要做两项主要工作一是基础字段校验比如标题不能为空、薪酬格式是否正确、人数至少为1二是状态初始化新创建的岗位默认进入待审核状态审核通过后才会出现在学生端的列表中。这个审核字段千万别省略后面做安全合规的时候还要靠它兜底。学生端列表页的检索是整个项目最常用的数据库操作。我使用MyBatis-Plus的LambdaQueryWrapper来构建动态条件可以根据前端传过来的参数灵活拼接查询条件不需要手动写大量XML SQLpublic PageJob searchJobs(Integer categoryId, String keyword, Integer minSalary, Integer page, Integer size) { LambdaQueryWrapperJob wrapper new LambdaQueryWrapper(); wrapper.eq(categoryId ! null, Job::getCategoryId, categoryId) .like(StringUtils.isNotBlank(keyword), Job::getTitle, keyword) .ge(minSalary ! null, Job::getSalary, minSalary) .eq(Job::getStatus, 1) // 只查询审核通过且上架的岗位 .orderByDesc(Job::getCreateTime); return jobMapper.selectPage(new Page(page, size), wrapper); }这种写法的好处是条件可选传与不传都能生成正确SQL而且代码可读性很好。实际开发中我的习惯是先用实体字段在代码里设定好查询逻辑再通过MyBatis-Plus的日志输出确认SQL与预期一致避免出现“查询结果对不上”的玄学问题。3.3 报名录取的状态机设计与并发防重报名和录取是整个项目中状态变化最复杂的环节因为涉及学生、发布方、岗位数据三方联动。我定义了一个ApplicationStatus枚举包含待审核、已录取、已拒绝、已取消、已完成五种状态。每个状态之间的合法转换关系需要专门设计否则很容易出现用户点两次按钮导致状态错乱的情况。状态流转的规则如下学生提交报名后申请记录进入待审核发布方查看报名列表可以点击录取或拒绝分别把状态改为已录取、已拒绝学生在待审核状态下可以主动取消报名岗位结束后发布方可以标记为已完成。每当我们更新状态时都要先检查当前状态是否符合转换条件防止不合法状态变更。与状态流转强相关的是一个非常经典的技术难题并发防重。两个学生同时为同一岗位提交报名或者同一个学生双击提交按钮都可能导致数据错误。解决办法有两条腿数据库层面在applications表建立(job_id, student_id)的唯一索引从根源上保证同一学生只能对一个岗位报一次名代码层面在录取人数达到岗位总人数上限时不能再录取这个判断必须使用原子更新而不是先查再改UPDATE jobs SET accepted_count accepted_count 1 WHERE id ? AND status 1 AND accepted_count headcount如果UPDATE返回的影响行数是1说明名额抢占成功如果返回0说明岗位已满或已下架直接提示用户。这个写法比“先SELECT再UPDATE”安全得多因为后者的两步操作之间另一个请求可能已经修改了数据导致超发。3.4 消息通知模块的落地选型报名状态发生变化后学生需要及时收到通知。我最初想直接接入微信订阅消息因为它能触达微信对话列表体验最好。但实际测试后发现有两个问题订阅消息需要用户主动订阅而且一条订阅消息只能触发一次推送要让用户每次都订阅显然不现实另外订阅消息的模板需要在微信公众平台申请审核周期会拖慢开发节奏。所以一期我采用了站内信方案在系统内实现一个消息表报名状态变更时自动插入一条消息记录学生打开小程序在消息页就能看到。消息表的核心字段包括接收者ID、消息类型、关联业务ID比如报名ID、内容、是否已读、创建时间。学生端消息页展示时把未读数量在TabBar上做角标提示。这种方案虽然没有微信推送那么强提醒但胜在稳定可控而且作为后期替换为订阅消息的基础结构字段完全兼容。二期只要在小程序端增加一次用户订阅授权再在后端把发送逻辑从“写站内信”改为“调订阅消息接口”即可。4. 数据库设计与性能优化让列表查询不再慢4.1 核心表结构与关键字段规划附建表SQL数据库设计是这类业务系统最容易一改再改的部分前期没想清楚后期加字段和拆表非常痛苦。我总共设计了四张核心业务表用户表、岗位表、报名表、消息表。字段规划从业务实际需求出发没有刻意追求过度范式化因为校园项目的数据量级不需要那么极端的拆表。用户表的关键字段CREATE TABLE user ( id bigint(20) NOT NULL AUTO_INCREMENT, openid varchar(64) NOT NULL COMMENT 微信openid唯一标识, nickname varchar(64) DEFAULT NULL, avatar_url varchar(512) DEFAULT NULL, phone varchar(20) DEFAULT NULL, school_name varchar(128) DEFAULT NULL, role tinyint(4) DEFAULT 0 COMMENT 0-学生 1-发布方 2-管理员, status tinyint(4) DEFAULT 1 COMMENT 账号状态 1-正常 0-禁用, create_time datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_openid (openid) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;岗位表CREATE TABLE job ( id bigint(20) NOT NULL AUTO_INCREMENT, publisher_id bigint(20) NOT NULL COMMENT 发布方ID, title varchar(128) NOT NULL, description text, category_id int(11) DEFAULT NULL, salary int(11) DEFAULT NULL COMMENT 单位元/时, headcount int(11) DEFAULT 1 COMMENT 招聘人数, accepted_count int(11) DEFAULT 0 COMMENT 已录取人数, province varchar(64) DEFAULT NULL, city varchar(64) DEFAULT NULL, address varchar(255) DEFAULT NULL, work_time varchar(255) DEFAULT NULL, contact varchar(64) DEFAULT NULL, status tinyint(4) DEFAULT 0 COMMENT 0-待审核 1-上架 2-下架 3-审核拒绝, view_count int(11) DEFAULT 0, create_time datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_category_status_time (category_id, status, create_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;报名表CREATE TABLE application ( id bigint(20) NOT NULL AUTO_INCREMENT, job_id bigint(20) NOT NULL, student_id bigint(20) NOT NULL, status tinyint(4) DEFAULT 0 COMMENT 0-待审核 1-已录取 2-已拒绝 3-已取消 4-已完成, apply_time datetime DEFAULT CURRENT_TIMESTAMP, handle_time datetime DEFAULT NULL, PRIMARY KEY (id), UNIQUE KEY uk_job_student (job_id, student_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这个唯一索引uk_job_student就是我在并发防重里提到的那条关键防线。即使后端代码出现了并发漏洞数据库级别依然能挡下重复数据。设计表的时候可以多思考每个字段后续会在哪些查询条件中被用到在创建表时就建立好合适的联合索引比后续再去补更省事。4.2 高频查询的索引设计与分页优化兼职列表页有几个高频查询场景按分类浏览岗位、按关键词模糊搜索标题、按创建时间排序展示最新。idx_category_status_time这个联合索引就是为了支撑“分类 状态 时间”这个最常见的组合查询。要注意索引字段的顺序要和查询条件的顺序匹配如果把status放在第一列而查询时总是带上category_id那么这个索引就无法被充分利用。列表数据的分页是另一个需要用心的地方。用MyBatis-Plus分页时要注意深分页的问题当页码很大时LIMIT 10000, 20会先扫描前10020行再丢弃前10000行效率非常低。校园项目的数据量可能到不了这个量级但为了养成好习惯我在后台管理列表里使用了一种更高效的分页方式记录上一次查询返回的最大ID下一页直接用WHERE id lastMaxId ORDER BY id ASC LIMIT 20来拉取。这种游标分页的写法跳过了偏移量的扫描开销在数据量大时性能优势非常明显。不过它也有个天然限制就是无法随意跳页只适合“加载更多”的无限滚动场景恰好匹配小程序端列表的交互方式。4.3 缓存层Redis在兼职平台中的实际用法我在项目里接入了Redis但用途非常克制只放在两块登录后的用户信息缓存和首页推荐岗位的短时缓存。用户信息缓存是因为用户每次请求都可能需要携带当前用户的身份和基础资料每次都查数据库没必要可以直接用用户ID作为key缓存在Redis里设置30分钟过期。推荐岗位的缓存则是因为首页每次打开都要筛选出最新、最热门的一批岗位如果频繁请求数据库热点时段容易造成压力。我开始就直接把首页查询结果整体缓存到Redis设置5分钟过期过期后回源到数据库。这里有一个需要果断避开的坑不要在缓存里存放复杂业务逻辑的半成品数据比如把某个用户的所有未读消息都缓存起来。因为消息的增量更新很难同步到缓存很容易出现用户已读消息后角标数字不消失的问题。消息这类强一致性的数据直接走数据库只有纯展示类的聚合数据才适合用缓存。5. 小程序端开发与前后端联调要点5.1 页面结构、TabBar 与分包加载小程序端页面结构我在目录里已经提到了这里重点说说TabBar的设计。底部导航固定为四个入口首页、分类、消息、我的。首页承载兼职列表和顶部搜索栏分类页用标签形式展示兼职类别学生可以快速筛选感兴趣的方向消息页展示站内信通知我的页面展示个人资料、我的报名、我的收藏、账号切换等功能。这个四Tab结构符合校园用户的直觉在用宣讲时也容易被理解。由于小程序的包体积限制我把消息页以及一些低频使用的页面放到分包里。通过app.json的subPackages字段配置主包只保留首页、分类、岗位详情、我的报名这些核心页面消息和收藏放分包。这样主包体积控制下来小程序的启动速度会更快。实际体验中这种区分带来的性能提升在开发工具里就能感受到小事也能养成好习惯。5.2 请求库封装与登录态的本地管理小程序端开发最要紧的一件事就是把请求封装成统一方法避免每个页面都重复写wx.request。我封装的request.js核心思路是统一拼接baseURL、统一附加Authorization header、统一处理业务码、统一弹出错误提示。这样后续业务开发时只需要关心数据和页面逻辑不需要反复处理请求异常。登录态的管理要注意及时性。用户打开小程序时我先从wx.getStorageSync里获取token如果存在就默认已登录但如果token过期了首次请求会返回401这个时候需要在请求封装里做一个统一处理调用本地登录接口重新获取token然后重新发起原请求。这里要注意一个细节重新登录必须是串行操作同时多个请求发现401时不要同时触发多次登录否则会白白消耗接口资源。处理方式是在request.js里维护一个isRefreshing标志正在刷新时把其他请求先挂到等待队列刷新完成后再依次执行。5.3 报名交互中的防重复提交与体验细节报名按钮是学生端最核心的交互组件用户在报名时很容易连续点击两次如果后端不做幂等处理就会产生两条报名记录。除了后端加唯一索引之外前端也要做一些交互层面的保护点击报名按钮后立即进入submitting状态按钮文案变成“提交中”同时禁用按钮点击等待接口返回后恢复。我用变量控制按钮的状态再利用disabled属性从视觉和交互上双重锁住避免用户重复操作。岗位详情页还有一个容易忽略的小细节收藏按钮的图标切换需要接口返回成功后再修改UI而不是用户一点就立刻切换。否则网络失败时界面显示已收藏但服务端数据还是未收藏两个状态不一致会让学生产生困惑。正确的顺序是点击按钮 → 调用收藏/取消收藏接口 → 接口成功后更新本地状态和图标。这个小原则在几乎所有点赞、收藏、关注的交互场景下都适用。6. 线上问题排查与避坑记录6.1 登录态频繁失效的根因与修复开发过程中我遇到的最诡异的问题是用户频繁掉线。排查后发现根因不在后端Token过期时间设置上而是用户手机系统时间和服务器时间不一致。JWT的exp声明是按秒计算的时间戳如果用户的手机时间比真实时间慢了几分钟客户端每次携带的Token在服务端验证时都因为“尚未到生效时间”或“已过期”而失败。修复方式有两种一是保证签发Token时使用服务器统一的时钟源二是在生成Token时留一个小的时钟偏移量比如exp设置为当前时间加7天再额外加5分钟缓冲。这个问题的排查经历很有价值因为JWT本身是一个无状态方案它不会主动告诉你“你的机器时间不对”只会默默拒绝请求。6.2 并发报名和名额超发的数据错乱我在模拟测试阶段用两个账号同时报名同一个岗位时发现录取人数偶尔会超过岗位总人数这就是典型的名额超发问题。原因就是我前面提到过的代码逻辑先读数量、再判断、再更新两条请求同时通过了判断阶段然后在更新阶段互相覆盖。数据库层面的唯一索引只能挡住同人重复报名挡不住不同人同时抢名额。解决办法就是用数据库的原子更新把“判断 更新”两步合并成一步UPDATE jobs SET accepted_count accepted_count 1 WHERE id ? AND accepted_count headcount。这个SQL的执行是原子的数据库的行锁会保证同一时间只有一个请求能执行成功第二个请求因为条件不满足而更新0行从而在入口处就拦截下来了。这个方案不需要引入事务、不需要额外的Redis分布式锁对校园项目来说是最简洁可靠的解法。6.3 图片上传失败与列表加载慢的处理岗位图片上传一开始我用wx.uploadFile直接把原始图片传到后端测试时发现经常失败。排查下来有两个原因一是系统默认的本地磁盘存储路径在服务器重启后会丢失二是大图片上传容易超时。后来我调整了策略在小程序端选择图片时启用compressed模式压缩限制图片大小在200KB以内后端改用对象存储保存图片返回URL给前端展示。这样上传速度明显提升也避免了服务器磁盘的空间问题。列表加载慢的问题则是因为首页图片太多、单页数据量太大。我在接口返回的数据里只包含图片URL小程序端的image组件加上lazy-load属性实现懒加载同时把每页条数从20条降到10条。配合前面提到的游标分页整个列表滑动变得顺畅了很多。6.4 后台管理列表的筛选与操作体验管理后台虽然只是给管理员用但排查问题时如果后台不好用效率会非常低。我在管理员端承担了三个核心功能岗位审核列表、用户管理、数据统计。岗位审核列表需要展示所有待审核岗位管理员可以一键通过或拒绝。这里有一个安全细节管理员操作时需要校验当前登录用户的角色确实是管理员否则任何人都可以调用审核接口。数据统计模块我也做了但比较克制只统计了几个关键指标今日新增岗位数、累计注册用户数、报名转化率。这些数据用SQL的COUNT(*)加GROUP BY就能得到不需要复杂的计算引擎。如果你也想加数据看板建议从这类简单指标做起不要一上来就搞实时大屏。7. 安全与合规这类平台最容易忽略的红线7.1 水平越权与垂直越权的检查清单写这种多角色的项目时安全最容易出问题的就是越权。水平越权指学生A尝试访问学生B的报名记录或个人资料垂直越权指学生调用管理员接口试图审核岗位。我的经验是每个查询接口都要显式判断资源的所有者不要只依赖前端隐藏入口。比如查询我的报名记录SQL条件里必须带上当前登录用户的ID而不是通过传入的报名ID直接查询。我在后端做了一层统一的角色校验在preHandle里解析出当前用户的角色后把角色信息和用户ID都放到ThreadLocal上下文中业务方法里再根据需求判断是否允许访问。这样每个接口都不用来回从数据库查用户角色也能保证后续的权限扩展有统一入口。顺手写一个越权自查清单在答辩或联调前系统性检查一遍我的报名列表是否带用户ID条件、岗位编辑接口是否校验发布方身份、管理员接口是否有RequireRole类注解约束。7.2 手机号、身份信息等敏感数据的脱敏与隐私保护校园平台一定会收集学生的手机号因为联系兼职工作需要。但手机号这类敏感数据不能在前端明文展示给所有用户。学生在查看某个岗位时我展示的是发布方的脱敏手机号例如138****1234具体完整号码在真实报名并通过录取后才可以看到。这个规则一方面保护了发布方的隐私另一方面也把“获得完整联系方式”作为成功报名的激励促进线上流程的完善。数据库里的手机号字段也建议加密存储。我在项目里使用AES算法对手机号加密后入库查询时在Service层解密再返回给需要的一方。虽然会增加一点开发量但隐私合规要求的趋势只会越来越严提前把脱敏和加密的思维做到位后续项目评审时也更能经得起提问。7.3 敏感内容的审核与违规处理机制兼职平台发布的内容如果完全放任不管很容易被利用来发布违规兼职信息比如刷单、传销、不实宣传等。因此我在发布端和管理端都设计了审核环节。所有新岗位默认进入待审核状态管理员在后台审核时可以直接看到格式化的岗位信息点击通过后岗位才会进入前台的岗位池中。审核通过的岗位如果被多人举报会被系统标记并重新回到待审核状态。关键词过滤我放在发布提交的后端Service层定义了一个敏感词列表基础版命中就直接拦截并提示发布方修改。虽然这种简单的词表过滤没法解决所有问题但因为成本极低作为第一道防线非常值得。真正复杂的语义审核可以留给后续接入内容安全服务校园项目做到一级审核把关已经能挡住绝大多数明显的违规内容。写在最后这个项目做下来我最深的体会是一个看起来功能并不复杂的SpringBoot加小程序的校园兼职平台真正考验人的地方其实全在数据库设计和状态管理这些“看不见的角落”。很多问题不是写的时候暴露的而是并发请求一到、用户一多才暴露的。如果你也正在做类似的校园服务类项目建议一开始就把唯一索引建好、把状态流转定义清楚、把越权检查写进每个接口这些基础工作做扎实了后面联调和答辩都会轻松很多。最后再分享一个小技巧多利用日志输出确认每个接口实际执行的SQL排查问题的时间能缩短一半。希望这篇记录能帮你在同样的项目里少踩几个坑。