企业官网建设流程全解析

做社区卫生服务中心的信息化改造，最头疼的不是没有需求，而是需求散、用户杂、预算少。我最近刚整理完一套社区医院管理系统，SpringBoot做后端、Vue做前端、MySQL存数据，源码可以直接跑通。对做毕业设计的同学、刚入行的Java开发、以及想给小诊所或社区卫生站快速搭一套信息化系统的朋友来说，这套源码是一个很省事的起点。你可以先跑起来看效果，再按自己的业务需求改成想要的样子，比从零开始写省下大量时间。

这套系统不是那种只有几个CRUD页面的拼凑货，而是把社区医院最核心的几条业务链路都串起来了：患者建档、医生排班、挂号分诊、门诊开方、药房库存、收费结算、系统权限，前后端分离，接口规范，数据库脚本齐全。我更想做的，是带你把它彻底吃透：每一层代码在做什么，数据库为什么要这么设计，部署时会遇到哪些坑，后续怎么扩展成真正能上线的产品。

1. 项目定位与整体架构

社区医院管理系统，圈内叫法很多：社区卫生服务中心HIS、基层门诊信息系统、一体化诊疗管理平台。不管叫什么，核心就是干三件事：挂号分诊、处置记录、收费统计。市面上的商用HIS动辄几十万，对社区卫生站、校医院、小型诊所完全不现实，于是就有了这种基于开源技术的轻量替代方案。我整理的这套源码，技术栈锁定在SpringBoot 2.x + Vue 2.x + MySQL 5.7/8.0，前后端分离，拿到IDEA里导入后端、VSCode里跑前端、本地起一个MySQL，按文档初始化数据，几分钟就能看到登录页，属于“可直接运行”的典型项目模板。

选择SpringBoot而不是SSH或SpringMVC，是因为SpringBoot把配置简化到了“约定大于配置”的极限。内嵌Tomcat，一个Application类就能启动，不需要外置容器；起步依赖管理了版本冲突，MyBatis-Plus和数据源也不需要像以前那样写一堆XML。Vue这边选2.x而不是3.x，不是3不好，而是社区医院系统的使用者要的是稳定，ElementUI生态成熟，组件文档齐全，做医疗表格、弹窗、表单这类密集交互场景效率极高。MySQL做关系型存储，事务和ACID特性在挂号、收费、药品库存扣减这些场景里依然不可替代，Redis缓存可以做性能增强但绝不是必须。

这套系统不是一个简单CRUD的堆砌，而是按社区医院的实际业务流划分模块。患者档案、医生排班、门诊挂号、收费结算、药房库存是主链路；系统管理、权限控制、公告配置、数据统计是支撑链路。数据上以患者ID为主线，把挂号记录、处方记录、收费记录、库存流水串起来，形成可追溯的业务闭环。架构上采用经典的前后端分离：前端通过HTTP调用后端RESTful接口，后端通过Spring Security + JWT做认证，接口响应统一封装为Result对象，这样方便前端统一处理业务异常。

为什么不推荐做成单体JSP项目？社区医院系统最烦的是需求频繁变化：今天要新增一个体检模块，明天要调整收费项目，后天报表格式要改。前后端分离后，前端和后端可以独立迭代、独立部署，涉及页面调整的改动完全不用重启Java服务。而且这套代码如果以后要接第三方平台，比如医保接口、公共卫生数据上报，后端接口就是天然的数据出口，这比改造传统JSP页面要轻松得多。

1.1 模块划分与业务边界

我先按业务模块拆一下，让你在跑通之前就有全局地图。系统管理模块管用户、角色、菜单、部门，采用RBAC模型，避免每个接口都写死权限逻辑；挂号管理模块负责号源维护、现场挂号、退号；门诊模块包括接诊开方、检查检验申请、处方管理；药房模块覆盖药品字典、入库、出库、库存盘点、效期预警；收费模块处理挂号费、药品费、检查费以及结算退费。

还有一个容易忽略但很关键的模块是统计报表。社区医院要应对上级考核、基本药物使用统计、门诊量月报，这些数据如果靠人工Excel汇总，月底能加三天班。源码里预置了简单的按日期聚合汇总接口，给前端图表组件提供数据，后续接ECharts或者大屏都很方便。每个模块都有独立的Controller、Service、Mapper层，包路径清晰，非常适合作为二次开发底座。

1.2 技术栈选型对比

如果你在纠结为什么不是SpringCloud微服务、为什么不用Vue3+TS，我的回答很简单：给社区医院用的系统，性能瓶颈从来不是高并发而是业务复杂度和维护成本。SpringCloud全家桶引入Nacos、Gateway、Feign，对一台普通PC就能跑起来的项目是负资产。Vue3+TS当然更现代，但对于大部分护理人员、收费员来说，界面的稳定性远比语言特性重要。技术选型的核心逻辑是：用最成熟的技术完成最稳定的业务，让接手的同事三天内能看懂，让系统五年内不用大改。

当然，如果你所在团队主要用PostgreSQL，或者你已经习惯了Vue3的组合式API，也可以在这个基础上迁移，但第一次做建议先用原技术栈跑通，再谈替换。

2. 后端核心模块与数据库设计

后端代码的阅读顺序我建议：先看启动类，确认启动路径；再看pom.xml，了解依赖范围；然后走一遍登录接口的Controller-Service-Mapper调用链；最后看数据库初始化脚本。这样的顺序最快建立代码地图。很多新手拿到代码直接翻业务代码，结果被各种配置绕晕，其实后端的启动过程和依赖关系是最先要摸清的。

2.1 数据库表结构设计

脚本通常在项目根目录的sql文件夹下，文件名类似community_hospital.sql。建议不要直接在Navicat里一键执行，先打开脚本确认字符集和存储引擎设置。我用到的核心表大致是这样的：

• sys_user（系统用户表）：主键id，account账号，password密码（BCrypt加密存储），name真实姓名，tel电话，dept_id部门，status状态。
• sys_role（角色表）、sys_menu（菜单表）、sys_user_role、sys_role_menu（关联表）：组成RBAC权限体系。
• patient（患者档案表）：id，card_no就诊卡号，name，sex，age，phone，medical_history既往史，allergy过敏史。
• doctor_schedule（排班表）：id，doctor_id，dept_id，schedule_date，period时段，max_count号源上限。
• registration（挂号记录表）：id，patient_id，doctor_id，schedule_id，reg_type挂号类型，fee挂号费，status状态。
• prescription（处方表）和prescription_item（处方明细表）：记录开药信息、药品数量、用法用量。
• drug（药品表）：drug_code药品编码，name名称，spec规格，unit单位，stock库存量，price单价，expiry_date效期。
• charge_record（收费记录表）：id，registration_id，charge_type收费类型，amount金额，pay_method支付方式，operator开单员。
• inventory_log（库存流水表）：记录药品入库、出库、盘点操作，方便追溯。

关系上，registration表同时关联patient和doctor_schedule，prescription表关联registration，prescription_item关联prescription和drug，charge_record关联registration。这样设计的好处是“以号找人、以方带药、以费结诊”，每一笔业务数据都有明确的指路人，查问题不需要翻纸质台账。

2.2 登录认证与权限控制

这套系统的登录接口走的已经不是简单的密码比对，而是Spring Security + JWT的标准流程。用户在登录页输入账号密码，后端用BCryptPasswordEncoder校验密码，成功后签发一个包含用户ID、角色编码、过期时间等信息的JWT字符串。前端后续请求在Authorization头带上这个Token，后端通过JwtAuthenticationTokenFilter过滤器解析并放行。

需要特别提醒：JWT虽然无状态、方便横向扩展，但注意签发有效期不能太长。社区医院收费员的电脑可能会放在公用位置，如果Token一个月不失效，安全风险非常大。建议把过期时间设为8到12小时，用户在下班后自动重新登录。源码里通常可以在application.yml中配置过期时间，我一般还会加上刷新逻辑，白名单机制等，但这些属于进阶改造，后面再展开。

RBAC权限模型的作用是让菜单和接口权限“按角色走”。管理员分配角色，角色绑定菜单，用户通过角色拿到菜单列表。后端接口层面，方法上打@PreAuthorize("hasAuthority('system:user:add')")这类注解，前端根据用户能访问的菜单动态渲染侧边栏。这样不会出现一个收费员误点进系统管理页面改了自己权限的尴尬。当前端路由通过addRoutes动态注册后，还需要配合路由守卫判断Token和权限，否则刷新页面容易直接跳回登录页。

2.3 核心业务接口设计

我用一个挂号的请求链路来演示接口设计。前端POST /api/registration，请求体带着patientId、doctorId、scheduleDate、regType、fee等字段。后端RegistrationController接收，校验号源是否已满，判断时间段是否已经被约走，若是现场号再查一次档案是否存在，然后调用RegistrationService生成挂号记录，更新doctor_schedule表的剩余号源数，最后异步记录一条操作日志。响应统一为Result.success(data)，data里包含挂号流水号。

收费接口ChargeController类似，但更强调事务性。一次收费可能包含药品费、检查费、诊查费，前端会把多笔费用打包提交，后端在@Transactional注解下，先查处方明细算总额，再生成charge_record主记录和明细流水，同时减少药品库存并写入inventory_log。任何一个环节抛异常，事务回滚，不会出现钱收了库存没减，或者库存减了收费记录没落库的问题。这一点是医院系统绝对不能出bug的地方。

接口路径的版本管理我也建议保留。源码中可能只有/api/v1前缀，如果你要长期维护，把路径改成/api/v1/registration或/api/v1/charge，这样后面升级接口时不会影响已经在用的客户端。RESTful命名上，GET用于查询、POST用于创建、PUT用于更新、DELETE用于删除，虽然老手都懂，但接手源码的人需要统一遵循，避免一个项目里出现四种风格。

2.4 MyBatis-Plus使用技巧

MyBatis-Plus在这套源码里的角色是简化单表CRUD。实体类上标@TableName注解，Mapper接口继承BaseMapper，Service继承IService，然后几乎不需要写XML就能完成基础增删改查。比较复杂的报表聚合、动态条件查询可以通过lambdaQueryWrapper或者自定义SQL完成。

实际开发中，多条件分页查询很容易写成无限拼接字符串的灾难代码。用MyBatis-Plus后可以这样：

Page<Registration> page = new Page<>(current, size); LambdaQueryWrapper<Registration> wrapper = Wrappers.lambdaQuery(); wrapper.eq(StringUtils.hasText(patientName), Registration::getPatientName, patientName) .eq(regDate != null, Registration::getRegDate, regDate) .eq(regStatus != null, Registration::getStatus, regStatus) .orderByDesc(Registration::getRegDate); registrationMapper.selectPage(page, wrapper);

这段代码的要点是：条件判断放在eq的第一个参数里，为空时自动忽略该条件，避免用户不输入任何条件时SQL变成一个全表扫描。selectPage会自动补limit和count，分页结果是IPage对象，能直接取出total、records。如果你需要联表查询且不想写复杂XML，可以先单表查出符合条件的registration，再用in查询关联表补数据，两种方式各有利弊，优先考虑性能。

3. 前端结构与关键实现

前端代码放在vue目录或frontend目录，启动方式通常是npm install然后npm run dev。拿到源码后，第一步不是点运行，而是看package.json里的scripts，搞清楚dev、build、serve这些命令分别对应什么。然后看src目录结构，确认api、router、store、views、components这几个标准目录是否存在。如果目录结构混乱，后期维护成本会成倍增加，所以切包前一定要检查。

3.1 页面结构与路由设计

典型页面结构是：登录页、系统管理下的用户管理/角色管理/菜单管理、患者档案管理、排班管理、挂号收费、处方管理、药房管理、统计报表。这些页面共用一套后台布局，左侧菜单树、顶部用户信息、中间内容区以router-view渲染。路由在router/index.js中定义，meta里会带上title、icon、roles等信息，用来区分菜单显示和权限控制。

对于社区医院的特殊使用场景，页面交互要尽量少点几次鼠标。挂号收费页面我会建议做成“一个界面三步走”：先搜索患者，再选医生时段，最后收费结算并打印小票。不要把挂号做成需要跳转三个页面的流程，收费员一忙起来会疯。前端的表单验证用ElementUI的rules即可，必填项、年龄范围、手机号格式、数量不能为负，这些规则放在forms里，既保证前端体验，也减轻后端压力。

3.2 Axios封装与请求拦截

前端请求就必须封装Axios，否则每个组件都要手动处理token、错误码、加载状态，代码会乱到无法维护。常见的封装方式是创建src/utils/request.js：

import axios from 'axios' import { Message } from 'element-ui' import router from '@/router' const service = axios.create({ baseURL: process.env.VUE_APP_BASE_API, timeout: 10000 }) service.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers['Authorization'] = 'Bearer ' + token } return config }) service.interceptors.response.use( response => { const res = response.data if (res.code !== 200) { Message.error(res.msg || '系统异常') return Promise.reject(new Error(res.msg)) } return res.data }, error => { if (error.response && error.response.status === 401) { localStorage.removeItem('token') router.push('/login') } Message.error(error.message || '请求失败') return Promise.reject(error) } ) export default service

这段代码就是前后端协作的“合同”：后端统一返回code、msg、data，前端在响应拦截器里判断code，非200直接弹错误提示。401表示Token失效或未登录，拦截器统一跳登录页，这样业务页面不用反复写“如果接口报错就跳登录”的判断。

3.3 动态菜单与权限控制

动态菜单的实现，本质是把后端返回的菜单列表转换成Vue Router的路由结构。用户登录成功后，调GET /api/sys/menu/current拿到当前用户可见的菜单树，然后在前端递归构造路由对象，用router.addRoute批量注册。注意，addRoute在Vue Router 4和Vue Router 3的用法略有差异，Vue2项目里通常是this.$router.addRoutes(routes)一次性添加。

踩过的坑是：刷新页面后动态路由丢失。因为Vue是单页应用，刷新后内存中的路由重置，如果只在登录页存了Token，刷新后在全局守卫里发现没加载菜单，就会误判为未登录。解决办法是在全局路由守卫里，通过判断store中是否有用户信息来决定是否重新拉取菜单并addRoutes，或者在main.js里启动时主动拉取一次。现在很多低代码后台已经把这套逻辑封装成公共模块，但理解原理仍然重要。

3.4 关键页面交互实现

处方录入页是全系统交互密度最高的地方，我的实现思路是左侧药品字典列表，右侧当前处方明细，点击某药品自动添加到明细并带上默认用法用量，医生可以在明细中修改数量、频次、备注，保存时一次性提交分页数据。这里前端要处理的一个细节是：用量用法的文本字段要支持模板规则，比如“每日3次，每次1片”，如果让医生自由输入，统计报表就没法按药品维度分析。

库存管理页的提醒逻辑也值得说。药品有效期预警主要靠后端提供接口，前端每个半天轮询一次或者打开页面时拉一次，然后展示在顶部公告栏。表格里对库存低于阈值的行标红，对七天之内过期的药品显示“过期预警”标签。ElementUI的表格列渲染用template插槽，在scoped-slot里根据字段值切换样式，这个不需要复杂组件，纯前端就能搞定。

4. 运行部署与踩坑实录

这部分是大家最容易卡住的地方。很多同学下载源码后第一反应是“直接启动试试”，结果报错千奇百怪。我按能跑通的顺序捋一遍，配合一些常见的坑。如果你按这个顺序操作，基本半小时内能把系统在本地跑起来。

4.1 本地环境准备

必须安装的软件按优先级排：JDK 1.8（推荐8u201以上）、MySQL 5.7或8.0、Node.js（推荐14.17或16.x，Vue2项目Node版本太高会有冲突）、Maven（3.6+）、IDEA（后端开发）、VSCode或IDEA自带前端插件。逐一确认版本，打开终端输入java -version、mysql --version、node -v、mvn -v，版本正常后再动手。

MySQL初始化是最关键的步骤。我建议先创建专用数据库而不是用root直连业务库，避免权限过大。命令如下：

mysql -uroot -p CREATE DATABASE community_hospital DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE community_hospital; SOURCE /path/to/community_hospital.sql;

编码不能用utf8，一定用utf8mb4，覆盖emoji和生僻字，避免药品名称或患者姓名中偶尔出现特殊字符导致乱码。SOURCE导入完成后，用show tables看看表数量，再select * from sys_user查一下users表，确认有初始账号。

4.2 后端启动步骤

先用IDEA打开后端目录，等待Maven下载依赖。pom.xml里的spring-boot-starter-parent版本如果是2.5.x或2.6.x，JDK1.8完全兼容；如果看到3.x版本，就要高版本JDK17+，这是新手最常踩的坑。然后在application.yml中确认数据库连接、账号密码、端口和JWT密钥。配置示例：

server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/community_hospital?useUnicode=true&characterEncoding=utf8mb4&serverTimezone=Asia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver mybatis-plus: mapper-locations: classpath*:mapper/**/*.xml configuration: map-underscore-to-camel-case: true

url里的serverTimezone=Asia/Shanghai一定要配，不然MySQL 8的时区警告会让你怀疑人生。启动后访问http://localhost:8080/doc.html或接口地址，看到Swagger或某个健康检查接口返回正常，后端就算跑通了。如果没有Swagger，直接访问登录接口用POST工具测试也可以。

4.3 前端启动步骤

进入前端目录后，依次执行npm install和npm run dev。npm install卡在node-sass上是老生常谈的问题，对于Vue2项目，如果package.json里写着node-sass，建议先卸载换成sass，或者直接升级到dart-sass。也可以直接设置淘宝镜像源，然后删除node_modules和package-lock.json重新安装，实测是解决依赖问题的最快路径。

随后确认vue.config.js里的devServer.proxy配置。因为前端开发服务器默认8080，后端也是8080，需要把前端端口改成8081，并通过代理转发/api请求：

devServer: { port: 8081, proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } }

这个配置的原理：浏览器访问8081，遇到/api前缀的请求，Node服务转发给后端8080。如果不用代理，你就要在axios里写全路径，然后被跨域问题折磨。代理配好后，本地开发完全不需要开启后端CORS。

4.4 常见问题速查表

我把碰到频率最高的几个问题汇总成表，建议直接收藏：

4.5 生产环境部署要点

本地跑通后如果要部署到服务器，思路是：前端执行npm run build，生成dist目录，放进Nginx的html目录；后端用mvn package打成jar，java -jar运行。Nginx配置里把location /api/ 反向代理到后端服务，同时配置gzip、静态缓存，这样一个普通2核4G的服务器就能支撑一个小型社区医院一天的挂号与收费压力。

启动脚本建议写成systemd服务，别用nohup裸跑。开发时nohup可以，生产环境进程崩溃没人管就麻烦。写一个community-hospital.service文件，把ExecStart指向jar包路径，Restart=always加上，配合日志输出路径，至少保证系统挂了能自动拉起，也能用journalctl查日志。

5. 二次开发与功能扩展

这套源码最大的价值不只是能跑，而是可以当底座继续长出业务。我建议从下面四个方向去延展。每个方向都不难，但都需要对业务有一定理解，做出来以后系统价值会明显提升。

5.1 电子病历模块

社区医院现在都要写电子病历，完全可以在现有架构上加一个emr_record表，字段包括patient_id、doctor_id、visit_date、complaint主诉、diagnosis诊断、doctor_advice医嘱、record_text病历正文。前端新增病历编辑页，后端提供保存、查询接口。如果想把数据做得更规范，可以引入结构化字段：既往史、家族史、检查结果等做成JSON存储，方便后续做统计分析和科研检索。

电子病历的编辑采用“富文本+结构化表单”混合模式最实用。医生主诉和诊断用输入框，既往史用多选框加补充文本框，体格检查按生理系统分组打勾，快节奏场景下比大段自由文本效率高。注意病历修改留痕，增加一个emr_record_log表记录每次修改时间和内容，这不管在合规方面还是医患纠纷溯源方面都很重要。

5.2 预约挂号与微信端

很多社区卫生服务中心有公众号预约的需求。扩展方案是在现有registration表里加appoint_source字段，标识是现场还是线上预约，然后在后端加一个预约接口，前端做一个H5页面。H5页面用Vue2也能做，只是注意移动端适配和微信JS-SDK的签名逻辑，如果只是展示预约成功状态，用微信网页授权就够了。

排班管理需要加号源池概念。线上号源和现场号源分开，医生排班时定义total_num线上号量、scene_num现场号量，挂号接口判断对应号源是否超出。这样才能避免线上约满后现场患者完全约不上的情况。这个改造不算重，改doc_schedule表和两个查询接口，加上事务锁，就能满足绝大多数社区的预约需求。

5.3 引入Redis提升性能

如果希望挂号高峰期扛得住，可以引入Redis。用户Token存在Redis，实现主动失效；药品字典和科室列表缓存到Redis，减少数据库压力；挂号号源使用Redis的incr原子操作，防止并发超卖。SpringBoot整合Redis非常简单，引入spring-boot-starter-data-redis，在application.yml里配置连接即可。

但要控制范围。Redis不是银弹，像收费记录这种强一致数据就不应该走缓存，必须老老实实写MySQL。项目里的缓存尽量放在“读多写少”的场景，比如科室列表、药品字典、排班查询。缓存更新策略用Cache Aside模式：先更新数据库，再删除相关缓存，下次查询重新加载。这个模式在99%的小型系统中够用，不需要引入分布式锁和消息队列。

5.4 数据统计可视化

报表模块可以从以下维度做：门诊量趋势、按科室分布、挂号费与药品费收入占比、医生工作量排行。后端写聚合SQL，按日期group by，前端用ECharts画折线、柱状、饼图。这个功能一旦上线，整个系统的价值立刻提升一个档次，因为领导们能看到“数据”而不是只看你在忙活。

SQL的思路不难，比如统计7天内每日挂号人数：

SELECT DATE(reg_date) AS day, COUNT(*) AS cnt FROM registration WHERE reg_date >= CURDATE() - INTERVAL 7 DAY GROUP BY DATE(reg_date) ORDER BY day;

接口返回数组给前端，前端用ECharts初始化图表，再定时刷新。更重要的一点是，统计口径要写清楚：是按挂号时间统计还是按就诊时间统计？是收费后算收入还是开单后算收入？这些业务规则一定要在接口文档里明确，否则不同科室看到的报表数字对不上，麻烦就大了。

6. 个人经验与后续建议

这段时间整理这套系统，我最深的感受是：医院类系统不是一个“功能越多越好”的系统，而是一个“稳定压倒一切”的系统。你用到的技术栈可以不是最新，但你得把异常处理、事务边界、权限控制、数据完整性这些基本功做扎实。一次收费事务漏了库存扣减，一次跨域配置错误导致医生看不了患者，这些都是比“用了微服务”严重得多的故障。

给拿到源码准备改造的朋友两个建议。第一，先把自动测试跑起来。即使没有完善的测试体系，至少把登录、挂号、收费、库存这四个核心接口的集成测试写好，改动代码后跑一遍，能挡住百分之八十的回归问题。第二，数据库变更不能随意改表名和字段名，尤其是已有业务数据时建议每张业务表都保留create_time和update_time，这对排查问题有巨大帮助。最后，医院系统的密码策略、操作日志、数据备份这几样东西，上线前就要配好，别等出事了再补。

这个项目后续还可以扩展的方向很多：对接检验科设备、接入医保电子凭证、做检查预约排队叫号、部署到云服务器上做成多租户SaaS。如果你只是需要一个能跑、能答辩、能改造的社区医院管理系统，这套SpringBoot+Vue+MySQL的源码已经是一个足够扎实的起点。