做基于 Android 的在线招聘平台，是每年毕业设计里都会出现的高频选题，光是我带过的学生里，一届就有至少五六个人报这个方向。表面上看它只是一套“后端 + App”的普通全栈项目，很多同学心里想着“不就是增删改查吗”，结果真动手之后才发现，它横跨用户角色、职位数据、简历、投递、消息、管理后台这几个大板块，只要有一环没设计好，后期写代码都像在补窟窿。
这篇文章把我自己反复迭代过的农业招聘平台类项目的完整路径整理了一遍，覆盖功能拆分、技术选型、数据库设计、接口实现、Android 端架构、联调排错、答辩准备这些环节，重点讲清楚每个选择背后的原因和实际操作中容易踩的坑。选题相近的同学可以直接拿来当参考骨架，已经写了一半卡在 Bug 上的，也能从排错章节里找到对应思路。
1. 项目整体设计与功能拆分
1.1 一条业务主链，三个角色各管一段
在线招聘平台的本质，是解决“企业想招人、求职者想找工作”这个供需匹配问题。整个系统最核心的业务闭环其实就三条链：
- 企业发布职位 → 职位进入平台可被搜索 → 求职者浏览详情 → 投递简历 → 企业查看简历 → 邀约面试
- 求职者注册账号、完善简历 → 浏览职位 → 投递 → 跟踪投递状态 → 接收企业消息
- 管理员审核企业入驻资质 → 审核职位内容 → 处理违规信息 → 维护平台秩序
围绕这三条链，系统里至少要有三个角色：求职者、企业、管理员。这正是设计用户表时必须有角色字段的根本原因，后端的接口鉴权也必须按角色来限制访问。有些同学做到最后，所有接口对所有人都开放，管理员和普通用户没有任何区别，答辩时老师一问角色权限怎么控制的，直接答不上来。角色边界的划分是整个系统设计的第一步，也是被忽略得最严重的一步，我建议动手写代码之前先把这条边界画清楚。
1.2 移动端功能模块怎么拆分
从我实际辅导过的多个类似项目来看，Android 端采用四个底部 Tab 是最合理的结构：职位浏览、消息、投递记录、我的。
职位浏览页承担最核心的“找职位”职责，包含职位列表、搜索栏、条件筛选三个部分。列表要展示职位名称、公司名称、薪资区间、工作城市这些字段，点击进入详情页后再展示岗位描述、任职要求和公司介绍。搜索建议做成“关键词 + 城市 + 薪资区间”的组合查询，这比只做纯关键词搜索体验强很多，答辩时也能体现你在查询逻辑上确实做过思考。
消息页展示系统通知和企业互动消息，比如投递被查看、面试邀约、被婉拒。这里要注意未读消息的样式区分，以及列表分页加载，否则消息一多页面就卡。
投递记录页按状态展示投递记录，常见状态有：待查看、已邀约、已婉拒、已过期。点击记录能跳回对应的职位详情。这块是体现业务闭环的关键点，没有它整套投递流程就是投完就没了。
我的页面负责用户信息、我的简历、企业入驻入口、退出登录。如果登录账号是企业角色，Tab 布局可以切换成企业管理模式：发布职位、管理职位、收到的简历、企业资料维护。移动端功能不需要做太重，但每一步操作都要有反馈，比如投递成功弹出提示，简历不完善时引导用户去完善。这些细节看似不起眼，却是答辩导师能直观感受到的项目完成度。
1.3 后端与数据库视角的模块拆分
后端的模块划分尽量跟业务域对齐，通常拆成六个核心模块：用户模块、职位模块、简历模块、投递模块、消息模块、审核管理模块。
用户模块负责注册、登录、密码修改、角色管理；职位模块负责发布的增删改查和上下架操作；简历模块管理求职者简历的各项内容；投递模块负责投递动作和投递状态流转；消息模块负责各类通知消息的生成与查询；审核管理模块则为管理员提供企业入驻审核和职位内容审核的页面。
这样拆完之后，数据库表也能一一对应：用户表、企业表、职位表、简历表、教育经历表、工作经历表、投递记录表、消息表，再加上城市表和行业表作为基础字典。核心表加起来十来张，只要表之间连成一张清晰的业务关系网，答辩时哪怕只展示关系图，都能让老师觉得你对系统有整体把握。这也是我推荐在写代码之前先把 ER 图画出来的原因，画图的过程本质是在检验业务理解是否完整。
2. 技术选型与架构分析
2.1 为什么 Spring Boot 加 Android 是最稳的组合
选择一个技术栈，不能只看“新”和“酷”，要看能不能在有限时间内做完，以及遇到问题时能不能找到足够的参考资料。Spring Boot 2.x 是目前 Java 后端里生态最完整的框架之一，自动配置、内嵌 Tomcat、独立启动，不依赖外部服务器。用它写在线招聘平台，基础增删改查部分一周左右就能搭完，剩下的时间可以完全投入到接口逻辑和客户端联调上。
Android 端建议用原生开发，语言选 Java 或者 Kotlin 根据学校教学环境和自己的熟练度决定。如果学校课程教的是 Java，就用 Java 巩固基础；如果自己学习能力比较强，用 Kotlin 还能在答辩时展示主动学习能力。为什么不建议小程序或者 Web App？计算机毕业设计的核心是体现你掌握了某一类技术的完整开发流程，原生的 Activity、Fragment、RecyclerView、网络请求、异步处理这些知识点，正是老师希望看到的。
后端持久层用 MyBatis 比 Spring Data JPA 更适合新手驾驭。原因在于 MyBatis 的 SQL 完全由自己控制，一旦列表查询需要做各种条件拼装，动态 SQL 语法非常直观；而 JPA 的自动生成 SQL 对初学者来说不够透明，出了问题不容易定位。数据库选 MySQL，工程上最成熟的选择，参考资料数量也意味着你遇到任何问题搜一下就能找到答案。
2.2 前后端 HTTP 交互与统一响应格式
Android 端和后端之间的通信，最稳妥的方式是走 HTTP 协议，数据格式统一用 JSON。Android 网络层强烈建议用 Retrofit 加 OkHttp 的组合，通过注解把后端接口定义成接口方法，代码结构清晰，调试也好做。
后端这边，接口返回格式必须统一。一个比较合理的响应体设计如下：
public class ApiResponse<T> { private int code; // 200 表示成功，其他为业务或系统错误 private String message; // 给前端的提示信息 private T data; // 具体业务数据 }所有接口都返回这个结构，前端拿到 Response 后先解析外层 code，再决定是直接处理 data 还是弹错误提示。这个约定看起来简单，但能大幅降低联调阶段的沟通成本。多个接口同时开发时，不统一的返回格式就是联调现场最折磨人的问题。
分页数据结构也要提前约定好，建议封装一个通用的分页对象，包含当前页码、每页条数、总记录数、数据列表四个字段。不管是职位列表、投递记录还是消息列表，全部复用同一个分页模型，前后端都省心。
2.3 接口鉴权与角色权限设计
在线招聘平台有三个角色，接口必须按角色做控制。我的做法是登录成功后由后端签发一个 JWT token，客户端存在本地，之后每个请求在请求头里带上 token。后端写一个拦截器，对所有非公开接口统一做 token 校验，并从 token 中解析出用户 ID 和角色字段，写入当前请求上下文。
public class AuthInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token = request.getHeader("Authorization"); // 校验 token 合法性，校验失败则返回 401 并拦截请求 // 校验通过后从 token 中解析 userId 和 role，放行到 Controller return true; } }角色层面的权限，只需对管理员接口和企业接口做一层角色判断。例如发布职位接口要求企业角色，审核接口要求管理员角色，求职者的普通接口登录即可访问。这样控制链路的复杂度可控，不需要引入权限框架也能达到效果。答辩时老师最关心的是你有没有“权限控制”的意识，而不是具体用了哪个框架。
3. 核心模块实操实现
3.1 数据库表设计：字段选择与关联关系
数据库设计是整个项目最容易返工的部分，一定要先想明白再建表。用户表至少要包含这些字段：id、用户名、密码、手机号、邮箱、角色类型、头像、创建时间、账号状态。密码必须用 BCrypt 加密存储，一定不能明文入库。角色类型用 tinyint 或 int，比如 1 求职者、2 企业、3 管理员。
企业表包含 id、用户 ID、企业名称、企业简介、营业执照图片、所属行业、企业规模、地址、审核状态。这里通过用户 ID 关联到用户表的登录账号，审核状态字段为管理员的后台审核操作预留位置。
职位表包含职位名称、企业 ID、工资下限、工资上限、工作城市、经验要求、学历要求、职位描述、发布时间、上下架状态。工资范围用两个 int 字段存储，比存成一个字符串方便后期做区间筛选。
简历表包含姓名、性别、出生年月、手机号、邮箱、求职意向、技能标签、自我评价。教育经历和工作经历会拆成两张子表，通过简历 ID 外键关联。这样设计的好处是简历的“教育经历”和“工作经历”可以单独增删改，不需要每次改简历都传一大坨数据。
投递记录表是关键核心表，字段包括 id、求职者用户 ID、职位 ID、企业 ID、投递状态、投递时间。这里故意冗余存一个企业 ID，因为投递记录列表要展示企业信息，冗余存储能少做一次关联查询，且更符合实际开发习惯。
消息表包含接收者用户 ID、消息类型、标题、内容、是否已读、创建时间。关系上大体是：用户对应企业、用户对应简历、企业对应职位、用户通过投递记录关联职位、用户接收消息。这组关系定了，后端 Mapper 的关联查询基本就不需要大改。
3.2 后端核心接口实现：职位搜索与投递事务
职位搜索接口是后端最有代表性的一个接口，涉及参数组合、动态 SQL 和分页。需求通常是按关键词、城市、薪资区间组合筛选，用 MyBatis 动态 SQL 实现最合适：
<select id="selectJobList" resultType="com.example.entity.Job"> SELECT id, job_name, salary_min, salary_max, city, company_name, create_time FROM job <where> <if test="keyword != null and keyword != ''"> AND (job_name LIKE CONCAT('%', #{keyword}, '%') OR company_name LIKE CONCAT('%', #{keyword}, '%')) </if> <if test="city != null and city != ''"> AND city = #{city} </if> <if test="salaryMin != null"> AND salary_max >= #{salaryMin} </if> <if test="salaryMax != null"> AND salary_min <= #{salaryMax} </if> </where> ORDER BY create_time DESC </select>很多人容易在两个边界上出错：一是 LIKE 查询的占位符写错，导致关键词失效；二是薪资筛选逻辑。求职者希望找“8千到1万”范围的岗位，那岗位的薪资区间必须和目标区间存在交叉，也就是岗位工资上限不小于目标下限，同时岗位工资下限不大于目标上限。直接用交叉区间判断，比单纯拿一个边界值过滤要符合真实场景。
投递接口是另一个容易埋坑的地方。投递动作表面上是往投递记录表插一条数据，实际涉及的逻辑远不止一行，顺序大致为：检查用户简历是否完整、检查职位是否仍然在招、插入投递记录、给企业端生成一条待处理消息。这四个步骤必须放在同一个事务里，否则就会出现“投递记录写了但消息没生成”的半成功状态。
@Transactional public void deliver(Long userId, Long jobId) { // 1. 校验简历是否完整 // 2. 校验职位是否在招 // 3. 插入投递记录 // 4. 给企业用户生成一条新消息 }做项目时就养成习惯：一个用户请求可能涉及多张表写操作的，一律加事务。这个习惯能在后期省下大量 Debug 时间，而且答辩时也是不错的加分回答。
3.3 Android 客户端架构与关键页面
Android 端的工程结构建议按功能包组织：ui、adapter、api、model、repository。ui 目录下按页面继续拆分，每个页面一个包，职责清晰，之后维护也好找文件。
网络层用 Retrofit 接口定义示例：
public interface ApiService { @GET("api/jobs") Call<ApiResponse<PageResult<Job>>> getJobList( @Query("page") int page, @Query("size") int size, @Query("keyword") String keyword ); @POST("api/deliver") Call<ApiResponse<Void>> deliver(@Body DeliverRequest request); }写接口时参数尽量用 @Query、@Body 这种明确语义，不要把参数手动拼到 URL 字符串里。拼字符串特别容易出编码问题，中文关键词拼进 URL 后经常变成乱码，排查起来很浪费生命。
列表页用 RecyclerView 加滑动加载更多，核心逻辑就是页码递增，每次返回新数据追加到列表尾部。这里有两个必须处理的细节：一是加载中要显示底部 loading 状态，二是数据加载完毕要显示“没有更多了”并停止继续请求。如果状态不处理，用户快速滑动到底部会反复触发请求，既浪费流量也影响体验。
简历编辑页是典型的回显型页面：进入页面先去后端拉取当前简历数据填入表单控件，用户修改完再提交。这里最容易出现的问题是异步请求和页面生命周期不同步，请求还没返回用户就退出了页面，回调里继续操作已销毁的视图，直接空指针。常见处理办法是判断 Activity 或 Fragment 是否仍处于可用状态，配合生命周期组件管理异步回调，能彻底解决这类闪退。
3.4 联调阶段的关键操作流程
联调是整项目里最磨人的阶段，建议按三步推进。
第一步，先跑通最简单的接口，比如注册登录。这个环节验证的是网络链路通不通，基础环境有没有问题。第二步，跑通职位列表的完整链路，查询接口、解析响应、渲染列表、滑动加载更多。这一步完成，客户端的基础骨架就活了。第三步，再逐个接入投递、消息、简历编辑等业务接口。每一步都有明确的验证目标，不至于联调到一半不知道问题出在哪。
联调时最常用的调试手段是看日志。后端用日志记录每个请求的路径和异常堆栈，Android 端用 Logcat 输出请求响应信息。接口返回了但前端逻辑报错时，先用 Postman 或浏览器直接请求一次后端接口，判断问题到底出在后端还是客户端，能省非常多无头绪的排查时间。
模拟器里访问本机后端时绝对不能写 localhost 或 127.0.0.1，Android 模拟器中这个地址指向的是模拟器自己，要用 10.0.2.2 才能访问宿主机。真机调试则要保证手机和电脑在同一局域网，填电脑的实际局域网 IP。这个坑我几乎每次带学生都会强调一遍，因为它太经典了。
4. 常见问题与排查技巧实录
4.1 后端高频报错速查
毕业设计项目里后端报错，大多数都集中在启动阶段和接口联调阶段。这里整理一份高频问题速查表：
| 现象 | 常见原因 | 解决办法 |
|---|---|---|
| 启动失败，提示端口被占用 | 之前启动的后端进程没关干净 | 找到占用端口的进程并结束，或修改配置文件里的端口号 |
| 数据库连接不上 | MySQL 服务没启动、账号密码错误、库名不存在 | 先启动 MySQL，再用客户端验证连接参数是否正确 |
| Mapper 找不到 statement | XML 的 namespace 写错、或 Mapper 接口缺少注解 | 核对 XML 的 namespace 是否等于接口完全限定名 |
| 接口返回 500，日志显示 SQL 异常 | SQL 语法错误、表名字段名不匹配 | 阅读异常日志，定位到具体 SQL 再逐项排查 |
| JSON 序列化异常 | 实体类字段类型与数据库类型不匹配 | 核对类型映射，注意 LocalDateTime 需要额外序列化配置 |
namespace 写错导致启动直接报 Invalid bound statement 的频率远超想象。一个字符不一致，整个 Mapper 就找不到方法。排查的时候先核对 XML 里 namespace 的值和接口的包名类名是否完全对应，这类问题往往都是复制粘贴时手滑导致的。
4.2 Android 端疑难问题实录
Android 端踩坑最多的场景集中在网络层，除了一直强调的模拟器 IP 问题，还有两个高频问题值得专门说明。
第一个是明文 HTTP 流量限制。Android 9 及以上版本默认禁止使用明文 HTTP 请求，如果后端地址是 http 而不是 https，App 会直接提示网络请求失败。解决办法是在 manifest 里配置允许明文流量，或者只在调试环境开启。这个知识点教程里经常不写，但真机联调时十有八九会遇到。
第二个是混淆导致的 Release 包启动失败。自定义的 Java Bean 被混淆之后字段名会被缩短，后端返回的 JSON 反序列化时找不到目标字段，各种字段丢失或者为空。解决办法是给实体类和 Retrofit 接口保留混淆规则，或者打包时直接关闭混淆。毕业设计答辩阶段，稳定能跑比花哨的混淆优化重要得多。
再补充一个容易被忽略的性能问题：模拟器默认配置不高时，运行 RecyclerView 大列表会卡顿甚至无响应。可以适当调大模拟器的运行内存，也可以直接用真机调试。真机性能更好，定位问题的置信度也更高。
4.3 答辩准备：导师喜欢问什么
毕业设计答辩的本质，是考察学生有没有真正理解自己写的系统。我把这类项目导师问得最多的问题总结为五个方向：
- 为什么选 Spring Boot，不选其他框架？
- 三个角色之间的权限是怎么控制的？
- 投递状态流转是怎样设计的？
- 如果用户量变大，当前设计有什么瓶颈？
- 密码是明文存储吗？接口有没有做参数校验？
这些问题没有标准答案，但答题的底气全部来自你真做了一遍。比如权限控制，你打开自己的拦截器代码，讲清楚 token 怎么校验、角色字段怎么判断，基本上就过关了。比如性能问题，你能答出“职位列表加了分页，热门查询字段建了索引，列表图片做了压缩”，老师就能判断你思考过实际问题。
我一直建议同学们答辩前准备一份系统演示剧本：从注册求职者、完善简历、搜索职位、投递，到切到企业账号收到消息、邀约面试，再到管理员后台审核职位，把整条链路完整走一遍。这套实际演示比任何 PPT 都更有说服力，答辩时间也基本控制得住。
5. 个人实操经验与后续扩展思路
做完这类完整的全栈项目，我最真实的体会是，在线招聘平台看着简单，实际写下来真正花时间的不是增删改查，而是状态流转设计与前后端联调的细节。如果时间充裕，建议再往两个方向扩展。
第一个是消息推送。招聘平台里面试邀约属于即时消息，如果做成 WebSocket 推送，或者接入现成的消息推送服务，用户体验会明显提升，答辩时也是一个很大的亮点。第二个是数据可视化。给管理后台加一个简单报表页面，展示职位发布量、投递量、用户增长趋势，用开源图表库画几条曲线，项目质感会立刻上一个档次。
最后分享一个小技巧：开发过程中一定要写接口文档，不必做得非常复杂，一张表格明确列出接口路径、请求参数、返回字段就够了。联调需要来回沟通时，文档就是最大的安全感来源。我见过太多同学口头对接口，几十个接口互相之间对错参数，改了三四轮才收敛，完全是浪费时间。
这个项目真正的价值不在于用了多高深的技术，而在于把一套完整的业务流程从前到后落到了代码上。做完它，你等于把用户注册、权限控制、数据建模、列表分页、状态管理、网络请求、联调排错这些软件开发通用能力完整地练了一遍。后面无论换什么业务场景，这套思路都能平滑迁移。
