企业官网建设流程全解析

坦白说，第一眼看到“蜗牛兼职网”这个名字，我就觉得这不是一个随便做着玩的课设。兼职类平台最大的难点从来不是“发布职位”和“投递简历”这两个动作，而是怎么把不同角色、不同状态、不同权限之间那些藕断丝连的逻辑理清楚。尤其当你选了SpringBoot2 + Vue3 + MyBatis-Plus + MySQL8.0这套组合，你会发现框架本身能帮你解决七成的问题，剩下三成全藏在表设计和状态流转里。

这个项目从源码到文档都齐备，适合拿来作为毕业设计、课程设计，也适合想完整走一遍“前后端分离 + 管理系统”链路的人参考。我按自己实际接手类似项目时的思路，把整件事从需求拆解到部署上线拆开讲一遍，重点讲那些你看完官方文档也不一定想得到、但联调时一定会踩的细节。

1. 项目定位与需求拆解：先分清“谁在用什么”，再谈技术选型

兼职平台这种项目，需求边界特别容易被一句话带过去。很多人一听“兼职网”，第一反应就是学生发布简历、企业发布岗位，然后双方对接就完事了。真画起原型来你会发现，至少有三类使用者，而每一类人看到的内容和能做的操作完全不同。

1.1 从需求源头拆出的四端模型

我把蜗牛兼职网的参与者拆成四端：游客、求职学生、企业管理员、平台管理员。游客能浏览岗位列表和平台介绍，但不能投递；学生登录后可完善简历、投递岗位、查看进度、结算和评价；企业端负责发布岗位、审核投递、标记雇佣状态、做结算确认；平台管理员则是终审角色，负责企业资质审核、岗位违规下线、用户封禁和内容管理。

与之对应的功能模块就非常清晰了：注册登录与实名认证、岗位发布与管理、投递流程管理、简历管理、结算与评价、消息通知、后台数据看板、系统管理。这套模块列表粗看很常规，但它决定了数据库要建多少张表、每张表的字段要到什么粒度，甚至决定了后面接口的嵌套层级。把模块先拆到这个程度，再去看Maven依赖和Vue页面，你才不会被源码牵着走。

1.2 数据模型是整个项目的主干

表设计是这个项目里最值得花时间的部分。基于上面的功能拆解，蜗牛兼职网至少需要这样几类核心表：

你仔细观察会发现，我没有把“用户”和“学生、企业”直接设计成三类独立的账号表，而是让sys_user作为统一账号基础表，再用student_profile和company_profile做一对一扩展。这样做的直接好处是，无论登录入口是学生端还是企业端，底层都能用同一套账号密码体系做认证，后续做平台管理员也只需要在这张表里加一个role关联就行，不用维护三套session。

同样值得留意的是apply_status_log这类日志表。很多初版项目会把投递状态只做成job_apply里的一个字符串字段，等到要展示“当前状态”“历史流转时间”的时候才发现数据不够用。加一张状态日志表，虽然写代码时多几条insert，但后台的审核跟踪、学生端的时间线展示都变成了简单的列表查询，属于典型的“前期加表、后期省心”。

2. 技术栈选型复盘：为什么是这套组合，而不是“看着更潮流”的方案

SpringBoot2、Vue3、MyBatis-Plus、MySQL8.0这四个词在现在的简历里几乎快变成标配了，但每个选型背后都有具体的现实考量，不是拼盘式堆砌。理解这层逻辑，比单纯跑通源码重要得多。

2.1 后端框架：SpringBoot2与JDK8的稳定组合

在已经有SpringBoot3和JDK17的当下，为什么不少真实项目仍然固定在SpringBoot2环境？因为大量公司和高校服务器上的JDK还是8。SpringBoot3的最低要求是JDK17，SpringBoot2.7.x对JDK8的兼容性已经非常成熟，而且javax.*命名空间在Servlet、Validation等场景里积累了一堆现成代码，迁移到jakarta.*的成本即便不高，也不是“刚把项目跑起来”的人愿意额外承担的。

对蜗牛兼职网这种前后端分离项目，SpringBoot2主要提供这几块价值：

• 内置Tomcat和自动配置，能大幅压缩接口开发时的配置代码；
• Spring MVC注解模型清晰，RESTful接口定义直观；
• 与MyBatis-Plus、MySQL驱动、Redis等第三方库的兼容经验非常丰富，遇到问题随手一搜就有答案。

有人会问，那直接用更老的SpringBoot1.x行不行？不是不行，是它的自动配置机制和较新的依赖体系已经有摩擦，而且安全补丁和社区支持明显不足。2.7.x这个版本段，算是“要稳定有稳定，要功能有功能”的平衡点。

2.2 持久层：MyBatis-Plus解决的是“单表CRUD”的重复劳动

选MyBatis-Plus而不用原生MyBatis，是因为这种业务系统里有大量的单表操作。用户注册插入一条记录、修改简历更新一个字段、查询岗位列表带分页，这些事情如果每件都手写SQL，整个项目会堆积大量同质化代码。

MyBatis-Plus提供的几个核心能力恰好覆盖这些场景：

• BaseMapper提供通用的insert、updateById、deleteById、selectById，基本告别简单SQL；
• 内置PaginationInnerInterceptor分页插件，配合Page对象可以直接拿到total和records；
• 逻辑删除功能可以用一个deleted字段统一实现“软删除”，避免用户误删后无法找回；
• 自动填充机制能统一处理createTime、updateTime这类审计字段。

不过要提醒一句，MyBatis-Plus对单表操作是神器，一旦涉及复杂的多表关联查询，它并不比手写SQL快。蜗牛兼职网里岗位列表要显示公司名和分类名称，这类场景我建议直接在Mapper里写XML，用JOIN把数据查出来，再用DTO接收。别迷信框架，该手写时别犹豫。

2.3 前端：Vue3 + 组合式API更适合中后台复杂度

Vue3相对于Vue2最大的变化不是语法，而是响应式系统的重构和组合式API带来的逻辑复用方式。兼职平台前端页面数量不少，却多属于“表单 + 列表 + 状态展示”的中后台风格。Options API写这类页面时，data、methods、computed会被切成三段，多个页面之间要抽公共逻辑只能靠mixin，混用多了非常难排查。

组合式API可以按业务功能拆出独立的函数，比如把“登录后获取用户信息并写入Pinia”这个动作放在一个useUser函数里，任何页面或组件需要用到时直接调用，逻辑内聚，可读性也更好。配合Pinia做状态管理，token、用户信息、未读消息数这些全局状态都能跨页面共享，不用做事件总线那套绕弯的事。

2.4 数据库：MySQL8.0带来的不只是默认utf8mb4

MySQL8.0较旧版本最直观的变化是默认字符集变为utf8mb4，emoji和特殊字符不再需要额外配置。另一个实用的改进是支持窗口函数和公用表表达式，这让“按分类统计岗位数量并带上排名”之类的查询比MySQL5.7时代优雅很多。同时8.0改进了查询优化器，很多慢SQL的执行计划更合理。

但这个版本也有个坑，后面我会专门讲到：它默认的认证插件是caching_sha2_password，老版本的连接驱动、或者没有配置allowPublicKeyRetrieval=true的JDBC连接串，会在启动时直接报Public Key Retrieval is not allowed。这个错误几乎每个从5.7切到8.0的人都会遇到。

3. 后端核心实现：登录态、数据权限和状态机的设计思路

跑通一个接口容易，把整个系统的权限边界和流程边界划清楚难。蜗牛兼职网的业务中，学生、企业、管理员三类角色频繁切换视角，后端如果不在接口层做严格的控制，很容易被前端操作路径带着走，最终出现越权问题。

3.1 登录认证：一学就会的Token + 拦截器方案

做这个项目时我接触过不少同学的第一版实现，普遍直接用Session存登录态。前后端分离项目用Session不是不行，但要考虑跨域携带Cookie、CSRF攻击、移动端复用等问题，整体不如Token方案干净。

我采用的是“登录成功后签发Token + 每次请求携带Token + 拦截器解析Token + ThreadLocal保存当前用户”这条链路。选Token方案并不意味着必须引入完整的Spring Security，对这个体量的项目来说，手写一个认证拦截器完全够用，而且能让你把每一步都看得清清楚楚。

核心逻辑大概是：

• 登录接口校验用户名密码。密码在数据库里存的是BCrypt密文，Spring Security Crypto包里自带的BCryptPasswordEncoder就能做加密和校验。
• 校验通过后，生成一个Token，负载里放userId和角色代码。生成算法可以用JWT库，也可以用UUID + Token存储在Redis里的方式。蜗牛兼职网考虑到多端登出和账号封禁的实时性，使用Redis存储Token，拦截器每轮查询Redis校验Token是否仍有效。
• 拦截器从请求头取出Token，解析出userId，查出用户基础信息放入ThreadLocal。
• 业务方法里通过UserContext.getCurrentUser()获取当前身份。

public class LoginInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token = request.getHeader("Authorization"); if (token == null || token.isEmpty()) { throw new BizException(401, "未登录"); } LoginUser loginUser = tokenService.parseAndValidate(token); UserContext.set(loginUser); return true; } @Override public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) { UserContext.clear(); } }

这个方案里有两点容易被忽略：一是afterCompletion里必须手动清除ThreadLocal，否则Tomcat线程池复用时，下一个请求可能读到上一个请求的用户信息；二是静态资源和登录、注册、岗位列表等公开接口要配置在拦截器白名单里，否则前端首次加载就会报401。

3.2 岗位和投递的状态机：用一张字段还是用一张日志表

岗位本身有状态：草稿、待审核、审核不通过、已发布、已下架。投递记录也有自己的状态：已投递、已查看、已面试、已录用、已拒绝、已完成、已取消。两套状态不能混在一个字段里，必须分开管理。

每个状态的迁移需要明确约束，我列一下岗位状态的核心流转：

• 企业创建岗位后默认是草稿，提交审核后变成待审核；
• 平台管理员通过后变成已发布；
• 已发布岗位可以被企业主动下架，也可以因为被举报被管理员强制下架；
• 审核不通过的岗位，企业修改后可以重新提交。

投递状态相比之下更复杂，因为它同时牵扯学生和企业两个角色的操作：

状态机的落地方式，我强烈建议配合apply_status_log表。每发生一次状态变更，除了更新job_apply.status字段，还往日志表插一条记录，携带操作人、操作时间、变更前后状态和备注。这样前端展示时间线时一次查询就能拿到全部数据，后台排查问题时也能还原每一次关键操作，比起只更新一个字段，遇到纠纷时省的时间不可估量。

3.3 数据权限：别让普通用户改掉别人的数据

数据权限是这个项目里最容易被轻视的一环。很多初版实现只做了登录拦截，没有做记录归属校验，于是出现了非常典型的问题：一个学生调接口把另一个学生的简历手机号改了，或者一个企业账号把另一家公司的岗位下架了。

实际上解决办法不复杂，就是在更新和删除接口里强制做“归属判断”。企业删除岗位时，先根据jobId查出岗位的companyId，再与当前登录用户所属的companyId比对，不一致就抛403。学生撤销投递时，同样校验apply记录里的studentId和当前用户id是否相等。这个判断不能只依赖前端隐藏按钮，后端接口必须每条都校验，我把这类判断统一封在一个DataScopeHelper里，凡是涉及写操作都调用它，防止漏加。

另外还有一个比较隐蔽的细节：学生浏览岗位列表时看不到企业完整联系方式，只有投递被企业“已查看”或“已录用”后，详情接口才返回手机号和微信。这个逻辑通过动态判断投递状态即可实现，属于业务型数据权限，写进接口文档里，避免前端凭空猜测字段什么时候出现。

4. 前端Vue3工程实践：封装、状态管理和几个容易踩的坑

后端逻辑再完整，前端接不好体验也白搭。蜗牛兼职网的前端采用Vite + Vue3 + Pinia + Element Plus这套常见组合，整体难度不高，但有几个点处理得好不好，直接决定联调时翻不翻车。

4.1 Axios封装：统一错误处理与登录过期

项目里所有接口都走一个封装好的request模块，而不是每个页面单独引入axios发请求。这样做最大的价值在于统一了三件事：Token注入、HTTP错误映射、业务码处理。

const request = axios.create({ baseURL: import.meta.env.VITE_API_BASE_URL, timeout: 10000 }) request.interceptors.request.use(config => { const token = useAuthStore().token if (token) config.headers.Authorization = token return config }) request.interceptors.response.use( response => { const res = response.data if (res.code === 200) return res if (res.code === 401) { useAuthStore().logout() router.push('/login') return Promise.reject(new Error('登录已过期')) } ElMessage.error(res.message || '请求失败') return Promise.reject(new Error(res.message)) }, error => { ElMessage.error(error.message || '网络异常') return Promise.reject(error) } )

这块代码看起来平淡，实际上有个高频问题：401弹窗重复出现。比如列表页同时发三个请求，三个请求都因为Token过期返回401，拦截器里连续执行三次logout和三次router.push，页面会跳来跳去，报错提示弹满屏幕。

我的处理方法是引入一个isRefreshing标记和等待队列，只让第一个401请求触发重新登录逻辑，其余请求排队等待刷新结果。如果刷新Token成功，把排队的请求用新Token重新发起；如果刷新失败，再统一跳登录页。这种并发去重机制在真实项目里用太频繁了，但很多资料里不讲，属于典型的“代码看得懂、遇事不会用”。

4.2 Pinia状态管理：只把真正的全局状态放进去

Vue3推荐用Pinia管理状态，但并非所有数据都该塞进store。如果你把每个页面的搜索条件都放进store，页面刷新后还要想办法恢复状态，纯属给自己加戏。

蜗牛兼职网里我主要放了三类内容：token、用户基本信息、未读消息数。这些数据的特点是“几乎每个页面都要用”且“变化会影响所有页面”。至于岗位列表、投递记录这些页面私有数据，留在组件内部或临时缓存即可，不需要全局共享。

Pinia的store里还有一个容易被忽略的问题：跨标签页同步。用户在一份浏览器里开两个标签登录同一个账号，一边修改了头像，另一边可能还是旧缓存。这个问题不需要做完整的跨标签通信，简单方案是在请求成功修改个人资料后，主动调用一个fetchUserInfo刷新store，并在store里比较更新时间。要更极客一点，可以用storage事件监听token变化，但对我这边项目来说，前者已经足够。

4.3 路由守卫：动态权限与公开页面白名单

前端路由不能当作安全边界，但它直接影响用户体验。蜗牛兼职网采用静态路由表，所有页面写在Routes配置里，再通过meta.requiresAuth和meta.roles做访问控制。

router.beforeEach((to, from, next) => { const authStore = useAuthStore() if (to.meta.public) { next() return } if (!authStore.token) { next({ path: '/login', query: { redirect: to.fullPath } }) return } if (to.meta.roles && !to.meta.roles.includes(authStore.roleCode)) { next({ path: '/403' }) return } next() })

这里有个细节值得展开：用户手动访问一个不属于自己身份的页面时，应该跳转到403页面而不是404。很多人习惯把所有不认识的路径直接引向404，然后在排查问题时分不清是页面没写还是权限没配。区分开用，一句话就能定位问题。

5. 联调阶段实测笔记：六个我几乎每次都会踩的坑

这部分是全文最有操作价值的内容。下面每个问题都来自真实联调场景，我给的不是一句话答案，而是完整的排查链路，方便你遇到类似情况时能顺着思路走。

5.1 MySQL8.0连接时报Public Key Retrieval is not allowed

现象：SpringBoot项目启动，后台日志报java.sql.SQLNonTransientConnectionException: Public Key Retrieval is not allowed。

排查过程：我第一反应是驱动版本不对，把mysql-connector-java从5.1.49换成8.0.33，问题依旧。后来查连接串，发现url里只写了localhost:3306和数据库名。又对照8.0的官方文档，才确认是caching_sha2_password认证插件导致的。

根治方式：JDBC连接串里加上allowPublicKeyRetrieval=true，完事后建议同步加上useSSL=false和serverTimezone=Asia/Shanghai。前者是开发环境下方便调试，后两者是保证SSL验证不打扰本地连接、时区不偏差8小时。这三行参数配上，再没见过这类启动报错。

提示：allowPublicKeyRetrieval=true在生产环境要谨慎开启，因为它允许客户端在建立连接时向服务端申请公钥。如果对传输安全要求高，推荐用SSL方式或配置正确的证书，而不是用这个开关。

5.2 LocalDateTime字段传给前端出现一串数字

现象：数据库里存的发布时间在接口返回里变成了一大串数字，前端拿到后格式化失败。

排查过程：看JSON数据，日期字段被序列化成了时间戳。原因是Jackson默认不认识和LocalDateTime，或者项目中没配置JavaTimeModule和禁用WRITE_DATES_AS_TIMESTAMPS。我最初只在application.yml里设了spring.jackson.date-format，但那是针对java.util.Date的，对java.time包无效。

根治方式：使用Jackson的自定义配置，或者直接给实体类字段上加@JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss")。推荐前者，全局配置一次，所有LocalDateTime字段都生效。

spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT+8

同时新建一个JacksonConfig，注册JavaTimeModule并且不把日期序列化为时间戳。两处配置配合，前端的dayjs格式化压力小很多。

5.3 MyBatis-Plus的updateById更新不了null字段

现象：学生把简历里的“个人简介”清空，保存成功后重新查询，发现字段还是旧值。

排查过程：第一反应是前台传参少了，打开Network面板发现请求体里确实有introduction: ""。再看后端接口，接收对象里的introduction是空字符串而不是null，按理说应该能更新。最后才想到MyBatis-Plus默认的字段策略是NOT_NULL，也就是只更新非null字段，空字符串虽不是null，但String字段再配合策略，容易出现字段被忽略的混淆情况。

根治方式：对这个字段使用@TableField(updateStrategy = FieldStrategy.IGNORED)，或者将实体类全局字段策略改成IGNORED。我建议只在特定字段上处理，因为全局放开后，每次update都会把所有字段拼进SQL，既影响性能又容易误更新。

提示：这里要注意区分两个场景。用户把字段完全清空，前端传的是空字符串，要让它更新；用户根本没传这个字段，对象里是null，通常应该忽略。所以更精细的方案是DTO里单独标志哪些字段需要强制更新，而不是一刀切处理。

5.4 分页查询的total总数和实际记录数对不上

现象：岗位列表用了JOIN查询，关联分类表和企业表，分页正常，但total有时候多出来，有时候变小。

排查过程：MyBatis-Plus分页插件在处理JOIN查询时，自动生成的count语句会简单地对主查询包一层select count(*) from (...)，这种写法在有些JOIN场景下会把笛卡尔积带进count，导致总数虚高。我最初通过手动指定countSql解决，后来又发现只要把主SQL和countSql分开优化就可以。

根治方式：在Mapper的XML里手动写count语句。分页插件允许你在方法上用@Select注解或XML方式显式提供count语句，别依赖自动生成的。把JOIN条件里的多余字段去掉，count语句只统计主表id去重后的数量。

<select id="selectJobPage" resultType="com.demo.dto.JobVO"> SELECT j.id, j.title, c.name AS companyName, t.name AS categoryName FROM job_post j LEFT JOIN company_profile c ON j.company_id = c.user_id LEFT JOIN job_category t ON j.category_id = t.id WHERE j.deleted = 0 AND j.status = 'PUBLISHED' </select> <select id="selectJobPageCount" resultType="long"> SELECT COUNT(DISTINCT j.id) FROM job_post j WHERE j.deleted = 0 AND j.status = 'PUBLISHED' </select>

5.5 修改用户资料后自动填充字段被重置

现象：更新昵称后，createTime竟然变成了当前时间，数据库里的历史创建记录被覆盖了。

排查过程：看实体类里createTime和updateTime都配了MyBatis-Plus的自动填充注解@TableField(fill = FieldFill.INSERT_UPDATE)。意思是插入和更新都会触发填充逻辑。createTime字段本应该只在插入时填充一次，现在却被错误的策略带进去，每次update都刷新了。

根治方式：把createTime改成fill = FieldFill.INSERT，updateTime才能用INSERT_UPDATE。同时检查MetaObjectHandler的实现里，是否用strictInsertFill和strictUpdateFill分别做了处理，不要在更新逻辑里把createTime也塞进来。

@Component public class MyMetaObjectHandler implements MetaObjectHandler { @Override public void insertFill(MetaObject metaObject) { this.strictInsertFill(metaObject, "createTime", LocalDateTime.class, LocalDateTime.now()); this.strictInsertFill(metaObject, "updateTime", LocalDateTime.class, LocalDateTime.now()); } @Override public void updateFill(MetaObject metaObject) { this.strictUpdateFill(metaObject, "updateTime", LocalDateTime.class, LocalDateTime.now()); } }

5.6 前端页面路由刷新后404

现象：部署到服务器，nginx配置了静态资源和反向代理。用户从岗位列表页点击进入详情页，刷新一次，nginx报404。

排查过程：Vue Router用的history模式，页面路径是前端路由，不是真实文件路径。nginx默认只按静态文件定位，刷新详情页时它去磁盘找/site/detail.html，找不到就404。第一反应是改hash模式，但URL带#号不美观，和我预期不符。

根治方式：配nginx的try_files指令，把所有非静态文件请求回退到index.html，由前端路由接管。

location / { root /opt/snail-web/dist; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8080/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; }

6. 打包部署与验收清单：让项目真正可交付

项目写完了、本地跑通了，离“可交付”还有一步。很多课设和简历项目倒在这一步——代码能run，但部署包不完整，环境的差异一换就崩。下面是我自己固定使用的一套流程和检查项。

6.1 前端构建与后端打包顺序

蜗牛兼职网是前后端分离的。前端开发时通过Vite代理访问后端8080端口，但部署时有两种常见方式：一种是前端和后端完全分开部署，前端用nginx提供静态文件，后端只暴露API；另一种是把前端build出来的dist目录直接复制到后端resources/static下，做成单一SpringBoot jar运行。

我更推荐第一种，因为它让接口层和页面层各自独立。运维上只要改nginx配置就能换前端静态文件，后端升级不用动前端。而且如果以后要扩展小程序或App，后端API可以直接复用，不用再抽一层。

前端打包需要注意环境变量。构建前要确保.env.production里的VITE_API_BASE_URL指向可被浏览器访问到的API地址。如果部署在云服务器，这里应该填公网域名或服务器IP，而不是localhost，否则用户在浏览器里请求的地址指向他自己电脑。

npm run build mvn clean package -DskipTests

后端打包时建议跳过测试，避免本地数据库连接不上导致构建失败。打包完成后看jar包大小，正常应该包含依赖和配置，大概几十MB。

6.2 上线前的自测清单

这个清单我每次交付前都会过一遍，推荐你直接照着抄一份：

6.3 文档的价值：从“跑起来的项目”到“能参考的系统”

标题里特意强调了【含文档】，这一点我多说两句。源码再完整，如果没有数据库初始化脚本、接口文档和部署说明，后来接手的同学基本无从下手。建议交付包至少包含：完整的SQL初始化脚本（含建库建表、初始管理员账号、基础数据）、Postman或Apifox导出的接口测试集、部署环境说明（JDK版本、Node版本、MySQL版本、nginx配置示例）、以及一个记录疑难问题的FAQ文档。

文档不是写给答辩老师看的，是写给三个月后的自己看的。我刚做类似系统时也嫌文档累赘，等到回读自己代码时，才发现当初的设计意图全靠文档才能快速还原。说句实在话，有这份文档的价值，和没有这份文档的项目，在真实工程里完全不是一个等级。

整个项目从需求拆解、技术选型、后端状态机、前端封装，到最后部署验收，每一条线都可以单独深挖。蜗牛兼职网这套源码如果只用来“跑起来看效果”，多少有点浪费；把它拆开对照着业务点逐层看，才是收获最大的方式。真动手改几行代码再跑一遍测试，比抱着源码看三遍都有用。