企业官网建设流程全解析

最近在整理一套办公管理系统源码，技术栈是SpringBoot2 + Vue3 + MyBatis-Plus + MySQL8.0，附带完整部署文档和二次开发说明。写这篇不是为了展示架构有多炫，而是因为每年都有不少开发者拿到这种类型的源码后，第一步就卡在环境配置、权限模型和启动问题上。这篇会把选型逻辑、表结构、权限设计、审批流、前端封装、性能安全、部署交付这些关键点拆开讲一遍，适合正在做OA、CRM或者中小型管理系统的后端开发者参考。

1. 为什么我选了这套技术栈，而不是微服务全家桶

1.1 办公管理系统的真实诉求

办公管理系统这类项目，业务功能翻来覆去就那么几块：组织架构、员工档案、考勤请假、审批流、公告通知、附件上传下载、系统设置。真正常年让人头疼的并不是业务功能本身，而是权限模型和数据流转。比如“这个角色能看到哪些菜单”“这个人能查哪些人的申请单”“审批过程中间被驳回之后怎么回流”。这些需求用微服务去拆，不仅不会让代码变清晰，反而会让一次跨服务调用变成一场灾难。

我做过的几个内部管理系统的实际状况是：用户几千人，并发高峰出现在工作日早上九点，集中在考勤打卡和待办查询，QPS并不高。此时瓶颈在数据库的慢查询，而不是应用服务器不够用。对这类系统，单体应用反而是最优解——部署简单，链路清晰，出了问题看一份日志就能定位。

1.2 SpringBoot2的价值判断

SpringBoot2在现在这个时间点不算最新，但它的生态沉淀非常厚。网上随便搜一个问题，基本能找到对应的解决方案。SpringBoot3虽然对标Java 17和GraalVM，但对办公系统来说，这些新特性带来的收益远低于兼容性成本。尤其当项目里要对接一些老旧的硬件SDK或者内网遗留系统时，SpringBoot2更稳。

还有一个很现实的点：团队协作。现在很多公司的开发团队并不是全员都能熟练使用SpringBoot3，你拿SpringBoot3写出来的项目，新员工上手成本明显更高。SpringBoot2在启动速度、配置方式、依赖管理上都足够成熟，对中小型办公系统来说，它就是顺手的那把螺丝刀。

1.3 MySQL8.0和MyBatis-Plus组合的化学反应

MySQL8.0真正让我觉得香的地方，是窗口函数和JSON类型。部门排名的统计SQL，用窗口函数一条语句就写完了；审批表单里动态字段的存储，用JSON列比搞一张复杂的EAV表舒服得多。MyBatis-Plus的价值在于单表CRUD几乎不需要手写SQL。一个实体类加一个BaseMapper，selectById、selectPage、updateById这些方法就直接能用了。

LambdaQueryWrapper写出来的查询条件，编译期就能校验字段名，不会出现xml里SQL字段拼错导致运行期才报错的问题。配合分页插件，一个简单的列表查询接口，从接收参数到返回分页结果，半小时内就能全部搞定。这也是我为什么一直强调，中小型项目没必要一上来就引入JPA或QueryDSL，MyBatis-Plus的“够用且简单”才是关键。

提示：如果团队还在Java 8，SpringBoot2就是最舒服的选择。SpringBoot3强制要求Java 17，很多老项目的公共组件还在Java 8上跑，强行升级只会给自己找麻烦。

2. 权限模型和表结构：办公系统的地基怎么打

2.1 五张核心表的建模思路

办公系统里表很多，但真正决定系统上限的是用户表、部门表、角色表、菜单表、用户角色关联表。这几张表如果设计得不好，后面加什么功能都会觉得别扭。我的习惯是先画出“用户属于一个部门，用户拥有多个角色，角色关联一组菜单权限”这样的模型，然后在这个基础上做扩展。

用户表上除了常规字段，还有一个data_scope字段，用来控制数据权限。比如1表示全部数据，2表示本部门及以下，3表示仅本部门，4表示仅本人。这个字段看起来简单，却是整个系统数据隔离的关键。对应建表SQL可以这样写：

CREATE TABLE sys_user ( id BIGINT PRIMARY KEY AUTO_INCREMENT, dept_id BIGINT NOT NULL COMMENT '所属部门', username VARCHAR(50) NOT NULL UNIQUE, password VARCHAR(100) NOT NULL, nickname VARCHAR(50), status TINYINT DEFAULT 1, data_scope TINYINT DEFAULT 2 COMMENT '1-全部数据 2-本部门及以下 3-仅本部门 4-仅本人', create_time DATETIME, update_time DATETIME ); CREATE TABLE sys_role_menu ( role_id BIGINT NOT NULL, menu_id BIGINT NOT NULL, PRIMARY KEY (role_id, menu_id) );

我没有在数据库里创建物理外键。所有关联关系都靠MyBatis-Plus的注解和服务层去维护。虽然这样看起来不够“严格”，但实际维护时灵活得多。办公系统的组织架构经常要调整，物理外键往往是改动时最先被骂的东西。

2.2 RBAC权限控制的落地细节

RBAC模型本身很简单，但实现时很容易在菜单权限和数据权限上打架。菜单权限控制的是“能不能看到某个按钮”，数据权限控制的是“能查哪些人的数据”，两者必须分开处理。

后端我用Spring Security拦截请求，校验接口需要的角色或权限标识。前端菜单通过Vue Router的路由守卫来按需加载，登录成功后一次性返回当前用户有权限的菜单树和按钮标识。这里要特别注意：不要把所有路由都打包进前端静态资源里，否则用户虽然看不到隐藏路由，但只要打开控制台就能手动跳转，安全风险很大。

权限修改后的缓存问题也很常见。用户权限被管理员改了，如果后端还缓存着旧权限，那用户要等缓存过期才能生效。我当时的做法是权限变更时主动清理缓存，并在用户表上加一个version字段。权限变更时version加一，前端每次请求带上这个版本号，后端发现不一致就强制刷新权限缓存，既减少了缓存击穿，又保证了权限生效的实时性。

2.3 部门数据权限的一个通用实现

普通员工只能看到自己提交的申请单，部门主管能看到本部门所有申请单，分管领导能看到自己分管范围内的数据。这套逻辑如果每个查询都手写条件，很容易写漏。我用的方案是查询时根据当前用户的data_scope动态拼接WHERE条件。

如果data_scope是“仅本人”，就拼and create_by = ?；如果是“本部门及以下”，先查出部门树的所有子部门id，再拼and dept_id in (...). 在MyBatis-Plus里，这些逻辑可以封装成一个自定义拦截器，业务代码里只需要正常写selectPage，完全不用关心数据隔离。拦截器里记得排除超级管理员和登录模块自己的查询，否则会出现逻辑死循环。

3. SpringBoot2集成MyBatis-Plus与MySQL8.0的坑

3.1 分页插件不生效的根源

第一次集成MyBatis-Plus时，我导入依赖后以为分页功能就可以直接用了，结果列表数据永远只有十条。排查了半天才发现自己漏掉了最关键的一步：MyBatis-Plus的分页插件必须显式注册到MybatisPlusInterceptor里，而且顺序不能乱。

@Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; }

如果你用的是旧版本3.4.x依赖，还要注意mybatis-plus-boot-starter和mybatis-plus-generator的版本号保持一致，否则启动时会直接报错。分页不生效还有一个隐蔽分支：在自定义XML里写了JOIN查询，结果limit被加到了错误的位置。这种情况建议不要在XML里手动写limit，统一用分页插件传入的Page对象。

3.2 MySQL8.0连接串的时区与SSL问题

MySQL8.0和旧版最大的区别是驱动类名改成了com.mysql.cj.jdbc.Driver，同时默认开启SSL和时区校验。如果不配置useSSL=false和serverTimezone，启动时大概率报“Public Key Retrieval is not allowed”。

我推荐的JDBC连接串是：

jdbc:mysql://localhost:3306/office?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai&allowPublicKeyRetrieval=true

这里的allowPublicKeyRetrieval=true主要解决RSA公钥获取问题，尤其在纯内网环境，手动配SSL证书反而更麻烦。还有一点：MySQL8.0默认认证插件是caching_sha2_password，如果项目里用的是5.x版本的驱动，无论如何都连不上。解决办法是把MySQL驱动版本升到8.0.33以上，或者在MySQL里把用户插件改回mysql_native_password。为了长远考虑，我更推荐升级驱动。

3.3 MyBatis-Plus自动填充字段的失效场景

我习惯用create_time和update_time做审计字段，MyBatis-Plus的MetaObjectHandler接口可以自动填充这两个字段。单独用没问题，但一旦使用MyBatis-Plus自带的批量插入方法insertBatchSomeColumn，自动填充就会失效。因为该方法内部走的是底层的批量Executor，MetaObjectHandler不会被调用。

解决办法是写一个拦截器处理批量插入的填充，或者干脆在调用批量插入前手动setCreateTime和setUpdateTime。还有一个类似坑：如果实体类上标注了fill属性，但你在Service层new对象后没有调用Mapper.insert，而是走了自定义XML的insert，自动填充同样不会生效。所以用自定义SQL时，所有字段都要自己显式赋值。

4. 审批流程的小型化实现：不引入Activiti的务实选择

4.1 轻量级状态机方案

办公系统里的审批流程，往复杂了说可以上Activiti、Flowable这类工作流引擎。但中小型项目里，大部分审批就是“提交-部门审批-分管审批-结束”这种固定链路。引入工作流引擎意味着要维护一套完全独立的数据模型，还要学习BPMN画图，部署流程定义，对团队来说学习成本太高。

我最后选择自己写一个轻量级状态机。申请单表里用一个step字段表示当前节点，用status字段表示整体状态：1-待审批，2-审批通过，3-审批驳回，4-作废。每个节点对应一个审批角色或具体人员。审批动作就是更新step和status，同时在审批记录表里插入一条记录。这个方案对于90%的办公管理场景足够用。

4.2 待办和已办的数据联动

待办事项的数据来源是审批节点表里所有status='pending'的记录，已办事项则来源于当前用户审批过的记录。这两块数据量不大，不需要单独建待办表，直接关联查询就能拿到。

真正需要用心设计的是审批记录表。至少要包含申请单号、审批节点、审批人、审批意见、审批时间、审批结果这几个字段。每次操作都往这张表里插一条记录，前端在详情页展示审批进度时，只需要按时间排序查询这张表就行。这样的设计还有个好处：后续要做批量审批时，可以通过这张记录表反向更新申请单状态，不必逐个查询。

4.3 定时扫描提醒的代价控制

审批通过后需要通知下一个节点的人，但如果每个动作都实时发送短信、邮件，成本会很高。我的做法是：在审批动作完成时生成一条站内消息记录，同时启动一个每分钟扫描一次的定时任务，把未读消息推送出去并标记已发送。

这里要特别注意定时任务的并发问题。用Spring的@Scheduled注解实现时，默认是单线程串行执行，但如果项目里配置了多个定时任务，最好在方法体里加上分布式锁或者记录上一次执行时间，避免重复推送。我在实际项目中还做了一层兜底：推送失败的消息自动进入重试队列，最多重试三次，确保用户不会漏掉重要待办。

5. Vue3前端封装与权限路由的实战经验

5.1 通用搜索表单组件

办公系统里的列表页几乎都是“筛选条件+表格+分页”的布局。我把搜索条件统一封装成一个SearchForm组件，通过字段配置数组来渲染，比如一个输入框对应{ key: 'username', label: '用户名', type: 'input' }。这样写的好处是新增一个查询条件只需要改配置数组，不用复制粘贴整段模板代码。

Vue3的defineModel可以很好地处理双向绑定，配合组件内部的getSearchParams方法，提交时统一输出查询参数。我还给组件加了折叠功能：超过五个条件的表单自动折叠，点击“展开”才能看到全部筛选条件，页面看起来清爽很多。这个组件写完之后，我后面几个项目的列表页开发效率明显提升。

5.2 路由守卫与按钮权限的配合

Vue Router的beforeEach不能直接判断按钮级权限，因为按钮权限是页面内部的功能点。我的做法是：路由守卫只负责判断是否登录，以及当前用户是否有该路由meta里定义的角色。页面内部按钮的显示隐藏，则通过一个自定义指令v-permission来控制。

比如按钮上写v-permission="['system:user:add']"，指令内部判断当前用户在store里的权限标识数组是否包含这个值，如果不包含就直接移除对应DOM元素。这样权限变更后前端不需要刷新整个页面，按钮自动消失。但要注意，前端按钮隐藏只是体验优化，真正安全的后端接口必须做权限校验，否则绕过前端直接调接口就守不住了。

5.3 文件上传组件的进度处理

办公系统里附件上传是高频场景，我用Element Plus的el-upload封装过一版组件，主要解决三个问题：大文件分片上传、进度条展示、失败重试。

分片上传的逻辑是先把文件按每片2MB切割，然后逐个上传，后端收到全部分片后做合并。进度条不能只看单片的进度，要计算所有已上传分片占总大小的比例。我实现时用一个队列保证同一时间最多上传三个分片，每个分片成功或失败都做记录，全部完成后调用一次合并接口。实际测试上传500MB的压缩包，前端界面不会卡死，进度条也能平滑推进。这里有个小技巧：合并接口在文件上传完成后再调用，但不要在前端循环里等待，用Promise.all把所有分片请求收集起来，再统一处理结果。

6. 性能优化、安全加固与部署交付的经验

6.1 列表查询分页数据重复的隐蔽原因

开发时遇到过一个问题：同一个用户查询待办列表，翻页后出现了第一页已经显示过的数据。排查下来发现是ORDER BY字段不唯一导致的。MyBatis-Plus分页插件生成的SQL默认不会自动补充唯一排序，如果业务排序字段存在重复值，比如按status排序，数据库返回的顺序就会不稳定，分页结果自然会出现错位。

解决办法是把排序字段改成id DESC，或者在排序列后面追加主键排序。这个坑很隐蔽，因为数据量小的时候不一定出现，等数据量大了才突然冒出来。所以我现在要求所有分页查询的OrderBy条件都必须包含一个唯一字段，任何列表只要有翻页，就用id兜底排序。

6.2 登录接口的防爆破与密码安全

办公系统登录接口是最容易被扫描的地方。我在登录接口上做了三重防护：第一是验证码，每五分钟过期，连续输错三次需要重新获取；第二是基于Redis的失败计数器，连续失败五次锁定账号十五分钟；第三是密码存储全部使用BCrypt加盐哈希。

密码加密这里我多说一句：不要用MD5或者裸SHA-256，一定要加随机盐，加密算法要尽量慢。我用的BCryptPasswordEncoder虽然慢，但这是必要的成本。系统还加了一层登录失败日志，记录IP、用户名和失败时间，方便后续排查暴力破解行为。

6.3 文档结构和部署检查清单

标题里特意写了“含文档”，这也是我接收别人项目时最看重的部分。文档目录我一般这样安排：环境要求、数据库初始化SQL、部署步骤、默认账号密码、接口说明、二次开发指南。很多源码项目只放一个readme，把“跑起来”这件事说得含糊不清，我见过太多人在数据库配置这一步卡住。

部署时建议先内网试运行，把日志级别调到DEBUG，完整看一遍启动过程，确认没有异常再切生产。文档里我会用一个表格列出所有配置项的含义，尤其是数据库地址、Redis地址、文件上传路径这三样最常见的修改点。交接给新人时，我会让他们先把权限表和审批状态机看明白，这两个地方是后续需求改动最频繁的部分。

7. 这套源码拿到手之后：启动、调试、扩展的三步走

7.1 第一步：把环境变量和数据库初始化做好

拿到源码后第一件事不是改代码，而是把项目跑起来摸清基本流程。先创建MySQL8.0的数据库，执行初始化SQL脚本，把表结构和基础数据导进去。接着修改application.yml里的数据库连接串、Redis连接串和文件上传路径。这里最容易出错的是MySQL8.0驱动和时区问题，用我前面给的连接串基本可以一步到位。启动成功后，先用默认账号登录，把部门和用户数据跑通一个完整流程，确认项目本身没问题，再进行二次开发。

7.2 第二步：调试时用日志定位问题

办公系统因为涉及审批、消息、定时任务这些模块，调试时很多问题不是静态看不出来的。我的习惯是把日志级别按模块拆开，业务包用DEBUG，框架用INFO。出现问题时，先看控制台有没有MyBatis-Plus打印的SQL日志，那条SQL就是最直接的线索。比如数据权限拼错条件，或者分页参数没生效，SQL里一眼就能看出来。

7.3 第三步：扩展时优先考虑这三点

如果这套系统要真正放到企业内部用，我的建议是优先做三件事。第一，把文件存储从本地磁盘换成对象存储或NAS，避免单机磁盘满了之后迁移困难。第二，增加操作日志的审计和导出功能，很多合规需求都要查历史记录。第三，把消息推送从站内信扩展到企业微信或钉钉群。做完这三件事，系统才具备基本的长期运营能力。

最后分享一个个人经验：拿到这类源码后，不要急着改第一个功能，先花半天时间把权限模型、审批状态机、部门数据权限这三个核心逻辑读明白。它们就像人身上的骨架，骨架对了，后面加肌肉才不别扭。我自己在接手类似项目时踩过不少坑，大部分都是因为基础流程没跑通就动手改代码，最后问题越改越乱。先把地基打好，后面才能走稳。