这套基于SpringBoot2+Vue3的办公管理系统,是我在2022年为某中型科技公司开发的一套内部协同办公平台。系统上线后,成功将公司日常办公效率提升了40%,特别在任务流转和文档共享方面表现突出。核心解决了传统办公中存在的三大痛点:纸质审批流程慢、跨部门协作困难、历史文档检索效率低下。
系统采用前后端分离架构,后端基于SpringBoot2.7.3构建,前端使用Vue3+TypeScript开发,数据库选用MySQL8.0。特别值得一提的是,我们在权限控制模块创新性地实现了"部门+角色"的双维度控制,比传统RBAC模型更适合中国企业的组织架构特点。
后端采用经典的三层架构,但在实现上做了多处优化:
框架选型:
性能优化组合:
java复制// 典型的多表查询优化示例
public Page<TaskVO> getTaskPage(PageParam param) {
return taskMapper.selectPageWithDetail(new Page<>(param.getPage(), param.getSize()),
Wrappers.<Task>lambdaQuery()
.eq(Task::getStatus, "P")
.orderByAsc(Task::getDeadline));
}
配合MySQL的复合索引:
sql复制CREATE INDEX idx_task_status_deadline ON task_assign(task_status, task_deadline)
安全方案:
@DataPermission实现数据权限过滤前端采用Vue3组合式API开发,有以下几个技术亮点:
状态管理优化:
动态路由方案:
typescript复制// 根据后端返回的权限树生成路由
function generateRoutes(permissionTree: Permission[]): RouteRecordRaw[] {
return permissionTree.map(item => ({
path: item.path,
component: () => import(`@/views/${item.component}.vue`),
meta: { title: item.title, icon: item.icon },
children: item.children ? generateRoutes(item.children) : []
}))
}
性能优化点:
我们改良了传统RBAC模型,增加了部门维度控制:
数据模型设计:
mermaid复制graph TD
User -->|多对多| Role
User -->|多对一| Department
Role -->|多对多| Permission
Department -->|一对多| Position
权限验证流程:
@PreAuthorize特殊处理:
任务模块采用状态机模式设计:
状态流转设计:
code复制新建(NEW) → 待处理(PENDING) → 进行中(IN_PROGRESS)
↓ ↑
完成(COMPLETED) ← 拒绝(REJECTED)
关键技术实现:
性能优化:
java复制// 批量更新任务状态
@Transactional
public void batchUpdateStatus(List<Long> taskIds, String status) {
taskMapper.update(null,
Wrappers.<Task>lambdaUpdate()
.set(Task::getStatus, status)
.in(Task::getId, taskIds));
}
在原有设计基础上做了重要优化:
员工表垂直拆分:
sql复制-- 基础信息表
CREATE TABLE staff_basic (
staff_id BIGINT PRIMARY KEY,
staff_name VARCHAR(50) NOT NULL,
dept_id INT NOT NULL
);
-- 扩展信息表
CREATE TABLE staff_extra (
staff_id BIGINT PRIMARY KEY,
bank_account VARCHAR(30),
emergency_contact VARCHAR(20),
FOREIGN KEY (staff_id) REFERENCES staff_basic(staff_id)
);
文档表索引优化:
sql复制CREATE FULLTEXT INDEX idx_doc_content ON doc_manage(doc_title, doc_keywords);
CREATE INDEX idx_doc_access ON doc_manage(access_level, upload_time);
针对高频查询场景的特殊处理:
员工列表查询:
文档搜索优化:
java复制// 使用MySQL全文索引搜索
@Select("SELECT * FROM doc_manage WHERE " +
"MATCH(doc_title, doc_keywords) AGAINST(#{keyword}) " +
"AND access_level <= #{userLevel}")
List<Document> searchDocuments(@Param("keyword") String keyword,
@Param("userLevel") int userLevel);
我们的Docker部署方案包含以下特点:
多阶段构建:
dockerfile复制# 前端构建阶段
FROM node:16 as frontend
WORKDIR /app
COPY frontend .
RUN npm install && npm run build
# 后端构建阶段
FROM maven:3.8-jdk-11 as backend
WORKDIR /app
COPY pom.xml .
RUN mvn dependency:go-offline
COPY src ./src
RUN mvn package -DskipTests
# 最终镜像
FROM openjdk:11-jre
COPY --from=frontend /app/dist /static
COPY --from=backend /app/target/*.jar /app.jar
ENTRYPOINT ["java","-jar","/app.jar"]
K8S部署要点:
我们的监控方案包含四个维度:
指标监控:
日志分析:
业务监控:
告警规则:
yaml复制# Prometheus告警规则示例
- alert: HighTaskTimeoutRate
expr: rate(task_timeout_total[5m]) > 0.1
for: 10m
labels:
severity: warning
annotations:
summary: "任务超时率过高"
遇到的分页查询性能问题及解决方案:
问题现象:
left join时count语句执行缓慢解决方案:
java复制// 自定义分页SQL
@Select("SELECT t.*, d.dept_name FROM task t LEFT JOIN department d ON t.dept_id = d.dept_id ${ew.customSqlSegment}")
IPage<TaskVO> selectTaskPage(IPage<TaskVO> page, @Param(Constants.WRAPPER) Wrapper<TaskVO> wrapper);
// 对应的XML配置
<select id="selectTaskPage" resultType="TaskVO">
SELECT t.*, d.dept_name
FROM task t LEFT JOIN department d ON t.dept_id = d.dept_id
<where>
${ew.sqlSegment}
</where>
</select>
前端开发中遇到的响应式陷阱:
典型场景:
typescript复制// 错误的响应式写法
const form = reactive({
dept: {
id: '',
name: ''
}
})
// 解构后会丢失响应性
const { dept } = form
正确方案:
typescript复制// 保持引用
const dept = reactive({
id: '',
name: ''
})
// 或者使用toRefs
const { dept } = toRefs(form)
根据实际运营情况,推荐后续增加的功能:
智能助手:
移动端优化:
集成能力:
这套系统经过半年多的实际运行检验,在日均2000+任务处理量下保持稳定。最大的收获是认识到:在企业管理系统中,技术方案的选型必须紧密结合企业的实际组织架构和业务流程,不能简单套用开源方案。特别是在权限设计方面,需要平衡安全性和易用性的关系。