企业官网建设流程全解析

最近又倒腾了一套企业级疾病防控综合管理系统的源码，技术栈是非常经典的 SpringBoot + Vue + MyBatis + MySQL。这套组合在企业内网、园区、学校、医疗机构的信息科里出现频率极高，核心价值就是把健康监测、异常上报、场所管控、数据统计这些原本靠纸质表格和微信接龙完成的流程，真正变成一套可协同、可追溯、能出报表的信息化工具。

如果你正打算做类似的业务管理系统，或者刚拿到一份完整版源码不知道怎么跑起来、不知道怎么按自己业务改，那这篇文章值得认真看完。我会从整体设计思路、后端核心模块、前端实现细节、部署运行流程到常见问题排查，把这套系统的每个关键环节都拆开讲清楚，尽量做到你照着就能上手的程度。

1. 系统核心定位与整体设计思路

1.1 为什么这套技术栈至今仍是主流

先聊一个很多新人容易忽略的问题：明明现在微服务、分布式、中间件满天飞，为什么一套企业级管理系统还愿意用 SpringBoot + Vue + MyBatis + MySQL 这种组合？答案很简单：这类业务系统的本质是“结构化流程管理”，不是“高并发流量处理”。

疾控综合管理系统这类项目的用户量通常是几十到几千人，并发高峰也就是某个时间段集中上报数据而已，单机数据库完全扛得住。SpringBoot 提供了快速构建独立服务的能力，内嵌 Tomcat，打完 jar 就能跑；MyBatis 把 SQL 控制权牢牢握在开发手里，适合业务规则复杂、报表查询灵活的管理系统；MySQL 部署运维成本低，是绝大多数中小企业信息科的默认选型；Vue 的生态成熟，前端组件库丰富，做后台管理系统效率极高。

这套架构真正的核心优势是“可控”。出了问题你能顺着代码一行行查，不会像分布式系统那样被网络、序列化、注册中心这些无关因素干扰。对于企业级业务系统来说，稳定、可控、易维护，远比技术上的炫技重要得多。

1.2 系统功能域划分与信息流设计

拿到这套源码后，我建议先别急着跑起来，而是先把它的功能域画出来。疾病防控综合管理系统一般会分成这么几大块：

• 基础档案管理：包括员工/居民的健康档案、基础信息、所在部门或区域、重点人群标记。
• 监测预警模块：每日健康情况填报、异常症状上报、体温记录、接触史记录。
• 防控任务管理：消毒消杀安排、隔离区域管理、防控物资出入库、任务分配与执行反馈。
• 流调与处置记录：异常事件从发现、核查、处置到解除的全过程跟踪。
• 统计报表中心：按时段、部门、区域的异常趋势统计上报。
• 系统管理：用户、角色、菜单、数据权限、操作日志。

这套系统的信息流主线非常清晰：建档——监测——异常上报——任务处置——统计分析。数据从基层向上汇聚，最后在管理层形成决策依据。所以设计数据库和接口时，所有核心表都会围绕“人、时间、地点、事件”这四个要素来关联。

我在实际改造中感触最深的是，很多开发者只关注增删改查，忽略了“状态流转”。比如一条异常上报记录，从“待核查”到“已处置”到“已解除”，这个过程有没有留痕、有没有时间节点记录，才是一套综合管理系统真正值钱的地方。

2. 后端核心模块：SpringBoot + MyBatis 落地细节

2.1 工程结构与基础配置

这套源码的工程结构是典型的单应用拆包方式，我见过不少团队用多模块 Maven 结构，但对于这种规模的项目，单工程按业务分包其实更容易维护。常见的包划分大致如下：

com.example.disease ├── config # 配置类：MyBatis、拦截器、CORS、线程池等 ├── controller # 控制层：只做参数接收和结果封装 ├── service # 业务层：核心业务规则和事务控制 ├── mapper # MyBatis接口层 ├── entity # 数据库实体类 ├── dto # 入参/出参对象 ├── vo # 视图对象 ├── common # 通用返回体、常量、异常处理 └── util # 工具类

关键的 application.yml 配置里，有几处非常容易踩坑。数据源必须加上时区参数serverTimezone=Asia/Shanghai，否则高版本 MySQL 驱动会直接报时间类型错误。另外map-underscore-to-camel-case这个配置建议开启，这样health_status能自动映射到healthStatus，省去一堆 resultMap 手写配置。

MyBatis 在整套系统里主要用于两块：单表简单操作直接走通用 Mapper 或 MyBatis-Plus，复杂统计查询全部手写 XML。我比较推荐这个混合策略，因为综合管理系统的报表模块往往需要多表 join、动态条件拼接、甚至临时按参数拼接 SQL 字段，只有 XML 里的动态 SQL 才能写得既灵活又可维护。

2.2 核心业务表设计与关联建模

数据库设计是这套系统的灵魂。我拿到这套源码时先翻了建表脚本，发现它的几张核心表设计得相当有代表性。

个人基础信息表（person_info）是所有业务的数据底座，字段一般包含姓名、证件号、所属部门或区域编码、联系方式、重点人群类型、状态。这里推荐在创建表时就加上create_time、update_time、deleted字段，后续做增量同步和逻辑删除都方便。

每日健康监测表（health_monitor）是最高频写入的表，设计上的重点在于唯一性约束。比如一个人一天只能有一条记录，正常应该建联合唯一索引uk_person_date(person_id, monitor_date)，用INSERT ... ON DUPLICATE KEY UPDATE实现“有则更新，无则插入”。如果不做这个约束，后面统计“上报率”时一定会出现重复数据问题。

异常上报与处置表（risk_event）建议拆成主表和流程表两部分。主表存事件基本信息：人员、上报时间、异常类型、风险等级、当前状态；流程表存每一步的处置记录：谁处理的、处理动作、处理意见、操作时间。主表和流程表是一对多关系。这样做最大的好处是，管理层查某条异常事件的完整经过时，只需要按事件 ID 查一遍流程表，不需要在业务代码里拼字符串记录历史。

统计查询是 MyBatis 发挥优势的地方。比如按部门统计近一周异常率，SQL 大概会长这样：

SELECT pi.dept_code, COUNT(DISTINCT pi.id) AS total_person, COUNT(DISTINCT CASE WHEN hm.is_abnormal = 1 THEN hm.person_id END) AS abnormal_person, ROUND(COUNT(DISTINCT CASE WHEN hm.is_abnormal = 1 THEN hm.person_id END) / COUNT(DISTINCT pi.id) * 100, 2) AS abnormal_rate FROM person_info pi LEFT JOIN health_monitor hm ON pi.id = hm.person_id AND hm.monitor_date BETWEEN #{startDate} AND #{endDate} WHERE pi.deleted = 0 GROUP BY pi.dept_code

这类 SQL 里有个细节值得注意：is_abnormal的条件要放在 CASE WHEN 里，不能直接放到 WHERE 条件中，否则会变成内连接把没填报的人过滤掉，统计口径就错了。这也是“说了你能跑，但跑出来的数据对不对”的关键区别。

2.3 数据权限与多角色处理

企业级系统最容易被低估的需求是权限设计。疾病防控系统里的角色一般包括系统管理员、防控专员、部门负责人、普通员工。普通员工只能看到自己的填报数据，部门负责人能看本部门统计，防控专员能看全量异常事件，管理员管系统配置。

这种场景如果只用前端按钮级权限控制是远远不够的，后端必须做数据权限过滤。这套源码里比较实用的方案是定义一个数据权限注解，在 MyBatis 的拦截器里动态拼接 SQL 条件。

举个例子：

@Target(ElementType.METHOD) @Retention(RetentionPolicy.RUNTIME) public @interface DataScope { String deptAlias() default "d"; }

拦截器会解析当前登录用户的部门编码和角色类型，如果是部门负责人，就自动在查询语句后追加AND pi.dept_code = #{currentDeptCode}；如果是普通员工，就追加AND pi.id = #{currentUserId}；只有系统管理员不加限制。这个思路相当于把数据权限从业务代码里抽离出来，统一收敛到一个切面里，后续新增查询接口时不用反复写权限判断，权限也不会漏。

需要提醒的是，数据权限拦截器在调试时会带来一个坑：如果你用 Postman 或者直接调用接口测试但没有携带用户上下文，拦截器拿不到部门编码，容易整个查询直接报空指针。所以源码里通常会提供一个测试专用的 Environment 上下文，或者让拦截器在拿不到用户信息时默认放行并打印警告日志。

3. 前端 Vue 实现要点：管理后台的交互与工程化

3.1 动态菜单与路由设计

这套系统的前端采用 Vue + Element UI / Element Plus，整体是经典的后台管理布局：左侧菜单栏、顶部导航、右侧内容区。比较值得讲的是动态菜单的实现方式。

医院、园区、企业内部的菜单权限是分角色的，管理员登录和普通员工登录后看到的菜单完全不同。前端一般做成动态路由模式：登录接口返回用户角色和可访问的菜单列表，前端拿到菜单后用router.addRoute动态注册路由。

// 登录成功后动态添加路由 const menuList = res.data.menuList const accessedRoutes = filterAsyncRoutes(menuList) accessedRoutes.forEach(route => { router.addRoute(route) })

这里有个经常被忽略的坑：router.addRoute是全局添加路由，用户退出登录再切换账号时，旧的路由仍然存在。如果不做清理，就会造成“普通员工退出后再登录管理员账号，路由重复或权限残留”。正规做法是在退出登录时维护一个resetRouter()方法，把动态添加过的路由记录下来，依次router.removeRoute(name)清除。

3.2 核心业务页面实现思路

前端页面里最高频、也最能体现代码质量的有两个：一个是每日健康填报页，一个是统计报表页。

每日填报页看似简单，就一张表单加一个提交按钮，但实际要考虑的交互细节很多。比如表单需要回显当天是否已填报，如果已填报应该进入可编辑状态而不是让用户重新填一张；提交按钮要有防重复提交机制，避免用户双击造成数据库出现两条记录。这些用前端 loading 状态加后端幂等校验双重控制才稳妥。

统计报表页的实现更考验基础功。医院或园区的报表通常要求有筛选条件栏：时间段、部门、异常类型、风险等级。前端把这些条件封装成一个公共查询对象，传给后端分页查询接口。展示方式上，一般会用一个统计卡片区放核心指标（今日填报率、今日异常数、待处置事件数），下面用 ECharts 画趋势图和占比图。

做 ECharts 图表时我踩过一个坑：图表数据来自后端聚合接口，前端拿到后直接 setOption，但页面切换 tab 或窗口 resize 时图表会变形，需要在容器组件销毁时调用chart.dispose()，在 resize 事件里调用chart.resize()。否则长时间挂着页面就会出现白屏或者图表显示不全。

3.3 前端与后端联调注意点

Vue 前端和后端 SpringBoot 联调，最容易出问题的就是跨域和接口字段格式。

跨域配置有两种常用方案：一是后端写 CORS 配置类，二是前端通过 Nginx 反向代理把/api路径转发到后端服务。我倾向于用 Nginx 方案，因为生产环境本来就要用 Nginx 托管前端静态文件，顺带处理代理是最干净的。开发阶段可以用 Vite 的 proxy 配置：

// vite.config.js server: { proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } }

字段格式方面，最容易踩的是时间类型。Java 后端返回的 LocalDateTime 默认格式是2025-01-01T09:00:00，前端表格里直接显示会很丑。建议在全局配置里统一格式化：

@Bean public Jackson2ObjectMapperBuilderCustomizer customizer() { return builder -> { builder.serializers(new LocalDateTimeSerializer(DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss"))); }; }

这个配置加一行，比前端每个页面写 formatter 函数省太多事了。

4. 源码部署运行全流程

4.1 本地环境准备

把代码跑起来之前，环境版本一定要先对齐，这一步能省掉后面大量莫名其妙的报错。我建议按照下面这套版本组合：

有一个很容易踩的坑是 JDK 版本。很多老一点的管理系统源码是基于 JDK 8 写的，你用 JDK 17 去跑，会出现IllegalAccessError或者 CGLIB 代理相关的报错，倒不是代码有问题，而是版本不兼容。如果源码没有明确要求，先用 JDK 8 是最稳妥的。

4.2 数据库初始化与后端启动要点

后端启动首先要创建数据库。一般源码里都会带一个sql目录，里面是建库脚本和初始化数据脚本。用命令行执行就行：

mysql -uroot -p < db_disease_prevention.sql

执行完检查几个关键点：数据表是否全部创建成功、初始化管理员账号是否写入、菜单权限表中的记录是否完整。很多源码跑起来页面白屏或者登录后没有菜单，八成就是初始化脚本没执行完整，菜单表是空的。

改好application.yml里的数据库连接信息后，用 Maven 打包：

mvn clean package -Dmaven.test.skip=true

生成的target目录下会有 jar 包，直接执行：

java -jar disease-system.jar --spring.profiles.active=dev

启动日志里看到Started DiseaseApplication就表示成功。建议项目启动后第一时间用浏览器访问一下后端接口文档地址（如果是集成了 Knife4j 或 Swagger），确认接口能正常返回数据，再启动前端联调。

4.3 前端构建与 Nginx 部署

前端代码先安装依赖：

npm install

如果安装过程非常慢或者出现 node-sass 报错，大概率是 Node 版本和依赖不兼容。优先换用国内镜像源：

npm config set registry https://registry.npmmirror.com npm install

生产环境构建：

npm run build

构建完成后dist目录就是静态文件。用 Nginx 部署时，推荐这样的配置：

server { listen 80; server_name your-domain.com; root /opt/disease-web/dist; index index.html; location / { 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; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }

这里try_files $uri $uri/ /index.html;是 SPA 路由的核心，少了这行，前端路由切换一刷新就 404。这是部署阶段最高频的问题，先检查这一行总没错。

5. 常见问题与排查技巧实录

5.1 启动阶段高频报错速查

我把这套系统运行过程中最容易遇到的问题整理成了一张速查表，都是实战里反复出现过的：

有一个容易被忽略的细节是跨域的 Authorization 请求头。SpringBoot 端 CORS 配置如果只允许了部分请求头，前端登录时携带 token 的请求会被浏览器拦截，现象是“接口 200 但拿不到数据”，控制台报错却是 CORS。配置 CorsFilter 时建议显式允许Authorization和Content-Type请求头。

5.2 数据查询慢与 MySQL 优化

疾控管理系统跑一段时间后，健康监测表的数据量会增长得很快，报表查询响应变慢基本是必然的。这时候不要急着换数据库或者上缓存，先看 SQL 和执行计划。

我在实际优化中常用的三板斧：

第一，给高频查询字段加联合索引。比如按部门和日期查统计，建idx_dept_monitor(dept_code, monitor_date)比单列索引效果明显得多。第二，报表类的多表 join 查询，尽量先缩小数据范围再 join，比如先查出时间范围内的监测记录，再关联人员表，而不是先关联全表再过滤。第三，分页查询用 MyBatis 的分页插件，同时关闭不必要的COUNT查询优化，如果列表页不要求显示精确总条数，直接把 count 去掉能省不少时间。

一个我自己实测有效的技巧：异常趋势统计接口，把按天聚合的 SQL 结果放到 Redis 缓存，key 设计为stat:abnormal:{deptCode}:{date}，缓存时间 10 分钟。报表页大多数时候看的是最近几天数据，没必要每次都查数据库全量汇总。但缓存过期策略要根据业务场景来，比如 10 分钟以内的新鲜度对这些管理决策报表足够用了。

5.3 前端联调问题定位思路

前端联调阶段最让人头疼的是“接口报 500 但后端日志没输出”。这时候先确认两件事：第一，请求是否真的到达了后端，看后端控制台有没有对应的访问日志；第二，有没有被全局异常处理器拦截后返回了统一错误码，但前端把错误信息吞掉了。

这套系统的后端一般都会写类似Result<T>的统一返回体和全局异常处理器。前端封装 axios 时，要对统一返回体做一个全局拦截，比如：

service.interceptors.response.use( response => { const res = response.data if (res.code !== 200) { Message.error(res.message || '请求失败') return Promise.reject(new Error(res.message)) } return res }, error => { Message.error(error.message || '网络异常') return Promise.reject(error) } )

联调中的一个高频问题：列表接口明明返回了total字段，前端表格却显示“共 0 条”。这通常是因为分页组件的total属性绑定错了字段名，接口返回的是data.total，前端绑定的是res.total。排查时分两步走：先在浏览器 Network 里看响应结构，再去前端代码里看绑定字段，两分钟就能定位。

5.4 关于二次开发的独家建议

如果你准备把这套源码改造成自己单位用的系统，我的建议是先不要动架构，而是按下面这个优先级来调整。

第一优先级是基础档案字段。每个单位的组织架构、人员属性都不一样，把person_info表里你要用的字段先列出来，该加的加，该删的删。字段命名保持下划线风格，和 MyBatis 的驼峰映射配合好。

第二优先级是流程状态定义。不同的防控场景有不同的状态流转，比如“待核查—已确认风险—已隔离—已解除”，这个状态枚举不要零散写在代码里，建议定义成常量类或者数据库字典表。我的经验是放到数据库字典表更灵活，改动流程时不用重新编译发版。

第三优先级才是页面样式和报表口径。页面样式改成单位自己的 Logo 和配色，报表字段按实际管理口径调整。这一层工作量不小，但如果前面数据模型和流程状态没设计好，改前端页面时会反复返工。

最后建议在二次开发时保留操作日志功能。疾病防控系统的操作记录涉及责任追溯，谁在什么时间改了什么数据、通过哪个接口做的修改，最好全部落库。这套源码里如果自带了日志切面，就保留默认的开头策略；如果没有，优先加一个基于 AOP 的日志注解，把关键业务操作记录下来。这个功能平时不起眼，真到追溯问题时就是保命用的。

我个人在实际操作中的体会是：这种综合管理系统的代码量并不大，难点从来不在某个技术点上，而在于你对业务流转的理解。把“人、时间、地点、事件”这条主线梳理清楚了，代码只不过是把这条线落到表结构和接口里。拿到源码先花半天读 SQL 脚本和表注释，再花一天梳理核心状态流转，比急着启动项目写页面靠谱得多。这也正是这套 SpringBoot + Vue + MyBatis + MySQL 组合最让人安心的地方——任何一层都是你能够完全掌控的，出问题永远查得到、改得了。