企业官网建设流程全解析

一套“企业级社区医院管理系统源码”，技术栈是 SpringBoot + Vue + MyBatis + MySQL，这个组合对国内做业务系统的开发者来说太眼熟了。我拿到这份完整版源码之后，花了两天半的时间把后端跑起来、前端编译通过、数据库初始化成功，又把挂号到发药的整条链路跟代码过了一遍。这篇文章就是基于这份源码的实战复盘，内容包括技术选型的真实动机、目录结构的解读、部署步骤、核心业务闭环的代码级走向，以及我踩过的那些坑。如果你正准备拿它做毕业设计、接项目做二次开发，或者只是想学习一个真实的医疗业务系统是怎么从表结构长成完整功能的，这篇文章应该能让你少走不少弯路。

先说一个结论：这套系统的价值不在界面多华丽，而在它把社区医院最关键的“挂号—就诊—收费—取药”业务链路完整串起来了，而且用到的都是国内Java生态里最普及的技术。这意味着你拿到手之后不会因为某个冷门框架而卡住，出了问题很容易搜到解决方案，改代码也相对好上手。接下来我从需求、架构、部署、业务、安全到二次开发，一层一层拆开讲。

1. 为什么社区医院需要一套“企业级”管理系统：从需求倒推技术选型

1.1 社区医院的信息化痛点，和大型三甲医院完全是两码事

很多人一听到“医院管理系统”，脑子里浮现的是三甲医院那种挂号机、叫号大屏、医保接口、LIS/PACS 影像系统。但社区医院的信息化需求跟大型医院完全是两个物种。

社区医院的典型特征是：科室不多但业务杂，常见病诊疗、慢病随访、疫苗接种、老年人体检、家庭医生签约，什么都要管。人员配置紧张，往往一个信息科就一两个人，甚至没有专职 IT。预算很有限，不可能像大医院那样定制一套几百万的 HIS 系统。更关键的是，社区医院的业务量并不小——患者排队可能不密集，但一天几百人的挂号、收费、取药记录是实打实的，靠 Excel 已经很容易出错。

所以社区医院真正需要的系统是四个字：轻、稳、省、改。轻指的是部署不要复杂，一台普通服务器甚至高性能 PC 就能跑；稳指的是业务不能丢数据，挂号收了钱必须能在系统里查得到；省指的是总拥有成本低，数据库和基础框架最好不涉及额外授权费；改指的是流程要能随着政策调整而修改，比如新增一个“慢病随访”模块、加一个疫苗批次管理，开发人员要能快速入手。这四点直接决定了技术选型的方向。

1.2 为什么 SpringBoot + Vue + MyBatis + MySQL 会成为这套源码的主力架构

我拆这套源码时，有一个很明确的感受：这套技术栈不是追新，是选了最适合“中小型业务系统”的保守组合。它的每一项都有清晰的存在逻辑。

SpringBoot 承担的是后端快速开发能力。它把繁琐的 Spring 配置变成了“约定优先”，内嵌 Tomcat、自动装配 Starter，一个 main 方法就能起服务。对社区医院这种业务场景，SpringBoot 的生态成熟度是无可挑剔的，你想加一个短信通知、做一个微信对接、接入支付宝收费，Maven 里找一个 starter 就能干活，而且网上案例一抓一大把。

Vue 承担的是前端多角色界面。社区医院系统里有这些角色：挂号收费员、医生、药房药师、管理员、院长。每个角色看到的界面和能操作的功能差异很大。Vue 的组件化开发加上 vue-router 的路由控制，可以很自然地把“一套后台，多种身份”这件事理清楚。社区医院的前端不需要多炫的交互，但要求逻辑清晰、表单顺手、响应快，Vue 在这方面属于标准答案。

MyBatis 的存在理由更直接——业务系统里永远有复杂 SQL。社区医院这种场景里，统计报表、条件查询、多表联查非常常见，比如“统计某个时间段内每个科室的挂号量”“查某位患者最近半年的处方明细”，这类需求用 MyBatis 的 XML 写原生 SQL 是最可控的，SQL 的调优空间也最大。对比 JPA 那种自动生成 SQL 的方式，MyBatis 在应对复杂查询时反而更透明、更不容易出“慢查询魔改”的尴尬。

MySQL 在数据库层面的选择就更好理解了。社区医院的数据量级，撑死也就每天几千条业务记录，MySQL 在单表千万级以内都表现稳定，而且是开源免费、部署简单、运维资料多。选 MySQL 不是因为它最强，而是因为它对这个体量的业务来说刚刚好，成本几乎为零。

有人可能会问：为什么不用微服务？为什么不用 NoSQL？答案很简单，社区医院一天的业务请求量连一台高配云主机都压不垮，微服务拆出来只会增加运维负担。Redis 缓存可以加，但加了也不是刚需；Elasticsearch 全文检索更没有必要，MySQL 的 LIKE 查询在几千条患者记录里完全够用。所以我判断这套源码选型逻辑是清醒的——用最主流的保守技术，去解决一个“不需要前沿技术”的真实问题。

1.3 标题里的“企业级”到底意味着什么

很多源码打着“企业级”旗号其实是营销包装，但这套系统里确实有几个配得上“企业级”的设计点，值得你在阅读源码时留意。

第一是角色权限模型。系统不是简单的登录就能看所有数据，而是按管理员、医生、收费员、药师等角色做了菜单级和操作级的权限控制，这是正规信息系统的底线。

第二是数据一致性设计。挂号、收费、发药这条链路不是各自为战的独立模块，而是通过状态字段和事务保证流程闭环。比如医生没写完处方，收费处就不能对它结算；处方还没收费，药房就不能发药。这些约束保证了金钱和药品不会对不上账。

第三是可维护性。代码的包结构清晰、命名规范、统一返回结构、全局异常处理，这些看似不起眼的工程习惯，恰恰是区分“个人项目”和“企业级系统”的分水岭。你接手源码时如果发现到处都是 System.out.println 和杂乱的 Controller，那这个系统的可持续维护性就非常堪忧。这套源码在这一点上做得比较规矩。

2. 核心架构解剖：前后端分离怎么落地、MyBatis 怎么和业务融合

2.1 前端 Vue：目录结构、路由守卫、请求封装怎么组织

我打开前端工程的第一件事是看目录结构。一个规范的 Vue 项目，目录结构本身就是文档。这套源码的前端部分基本长这样：

src ├── api/ # 接口定义，按模块拆文件 ├── assets/ # 静态资源 ├── components/ # 公共组件 ├── router/ # 路由表 ├── store/ # Vuex 状态管理 ├── styles/ # 全局样式 ├── utils/ # 工具函数，比如 request.js ├── views/ # 页面组件，按角色/模块分目录 ├── App.vue └── main.js

这个目录结构最大的好处是：你想找“挂号”相关的接口，去 api 目录下找 registration.js；想改挂号页面，去 views 目录下找对应模块，改动范围很清楚。对比一下那种所有请求都塞在一个文件里的写法，这种拆分在多人协作和后期维护时优势巨大。

前端的访问控制主要在路由层做。vue-router 里一般会定义一个beforeEach全局前置守卫，检查用户是否登录、是否有当前路由的权限，没有权限就重定向到登录页或 401 页面。逻辑大概是：

router.beforeEach((to, from, next) => { const token = localStorage.getItem('token') if (to.path !== '/login' && !token) { next('/login') } else { next() } })

这只是最基础的版本。在实际项目里，菜单权限往往是根据后端返回的角色动态生成了路由表，再结合侧边栏菜单渲染，做到“这个医生登录进来根本看不到药房管理菜单”。这套源码在权限这块做到了菜单级控制，这点对医疗系统的合规性很重要。

请求封装这块，常见的做法是在 utils 里封装一个 axios 实例，统一设置baseURL、timeout，在请求拦截器里往 header 注入 token，在响应拦截器里统一处理业务错误码和 401 登录失效。这样页面里调用接口只需要关心业务数据，不用重复处理异常和 loading 状态。我强烈建议你看这套源码时先看这个 request 封装，这是前端工程化的关键一环。

2.2 后端 SpringBoot：分层结构、统一返回、全局异常处理

后端代码的包结构是我判断一个项目是否“正经”的第一道关卡。这套源码的包结构走的是标准分层：

com.example.hospital ├── controller/ # 接口层，只做参数接收和结果返回 ├── service/ # 业务层，处理业务逻辑和事务 ├── mapper/ # MyBatis 的 Mapper 接口 ├── entity/ # 数据库实体类 ├── dto/ # 数据传输对象，常用来接收前端参数 ├── vo/ # 视图对象，常用来返回给前端 ├── config/ # 配置类，比如 WebMvcConfig、CorsConfig ├── common/ # 通用类，比如 Result、异常枚举 └── util/ # 工具类

Controller 层很薄，一般就是接收参数、调用 service、返回 Result。Service 层是业务逻辑的核心，事务注解@Transactional基本都加在这一层。Mapper 层只负责数据库操作，不写业务判断。如果你看到一个项目在 Controller 里直接写了大量 SQL 或者业务判断，那通常说明项目已经失去分层纪律了。

这套源码的接口返回统一封装成了一个Result对象，结构大概是：

public class Result { private Integer code; private String message; private Object data; // 省略 getter/setter }

这种统一返回结构的好处是前端可以写一套响应拦截逻辑，不需要为每个特别接口定制处理。成功时的 code 是 200，失败时是错误码，数据不直接返回裸对象，这样避免了很多前端类型判断的麻烦。

全局异常处理用的是@RestControllerAdvice，把业务异常、参数校验异常、未知异常统一拦截，并转换成统一的 Result 返回。这种做法虽然代码量不多，但价值很大——如果没有全局异常处理，数据库访问报错时前端可能直接收到一大堆堆栈信息，既丑又泄露敏感细节。

2.3 MyBatis 在业务中的实际用法：动态 SQL、缓存、联表查询

MyBatis 在医疗业务系统里最常用的是两个能力：动态 SQL 和多表联查。因为医疗业务流程存在大量“带条件的组合查询”。

比如患者列表查询，前端可能传上门诊号、姓名、手机号、挂号时间段等多个条件，而且这些条件是可选的。如果用 JDBC 拼 SQL 会拼到怀疑人生，但 MyBatis 的<where>+<if>标签解决得很优雅：

<select id="listPatientByCondition" resultType="com.example.hospital.vo.PatientVO"> SELECT * FROM patient <where> <if test="patientNo != null and patientNo != ''"> AND patient_no = #{patientNo} </if> <if test="name != null and name != ''"> AND name LIKE CONCAT('%', #{name}, '%') </if> <if test="startTime != null"> AND create_time &gt;= #{startTime} </if> </where> ORDER BY create_time DESC </select>

这套源码的核心业务查询基本都用了这种动态 SQL 方式，保证了 SQL 的灵活性和可读性。

MyBatis 的缓存机制也值得你留意。一级缓存基于 SqlSession，默认开启；二级缓存基于 namespace，需要手动开启。在社区医院这种业务里，二级缓存要慎开——因为患者数据、库存数据频繁变动，开了反而可能查不到最新数据，还容易造成缓存穿透和内存占用。实际上大多数业务系统只在字典表、科室表这类变化极少的基础数据上用二级缓存，主业务数据几乎不用。

联表查询是 MyBatis 的另一个主战场。比如挂号列表要显示患者姓名、科室名称、医生姓名，一条 SQL 多表 join 后映射到一个聚合 VO 对象。这里有个经验之谈：不要图省事在 Mapper 里用级联嵌套查询（N+1 问题），也不要一次性把所有关联表全 join 进来，而是按查询场景决定要查哪些字段，必要时拆成多个查询组合。这套源码在核心列表页的 SQL 写法总体还算克制，没有出现那种一个查询拖 8 张表的“怪物 SQL”。

2.4 数据库表设计：从患者到收费的完整模型

表结构是整条业务链路的根基，我建议你拿到源码后第一件事不是启动项目，而是把 SQL 脚本里的表结构先过一遍。这套系统的核心表基本围绕“人—就诊—药品—钱”四个维度设计。

核心表大致包括：

从设计上看，处方主表和处方明细表是典型的一对多结构，这保证了“一张处方多味药”的建模正确性。挂号表里通过 patient_id、doctor_id、dept_id 三个外键关联了患者和资源，缴费和发药则通过状态字段串联起来。这种表结构与真实医疗业务模型是吻合的——我在评估一套系统是否“真懂业务”时，最看重的就是处方主明细表和药品库存成本的关系模型，这里如果乱了，后面再花哨都白搭。

索引设计上，业务系统最常用的查询维度无非是：按挂号单号查、按患者身份证号/手机号查、按时间段统计。这些字段都应该建索引。但要注意，不要每个字段都建索引，因为写入频繁的表如果索引太多会导致插入变慢、索引膨胀。社区医院这个量级不需要过度设计，几个核心索引加上去，查询性能基本就不会有太大问题。

3. 从 0 到 1 部署这套源码：环境准备、初始化与启动步骤

3.1 环境版本怎么配：JDK、Maven、Node、MySQL 的推荐组合

部署这套源码的第一步是环境版本，这也是很多新手最容易翻车的地方。直接说结论，推荐组合：

我实际部署时用的是 JDK 1.8、Maven 3.8、Node 14.17、MySQL 5.7。这套组合属于“养老级”稳定性组合，几乎不会因为工具版本踩坑。

这里特意说一下 Node 版本的问题。现在很多新出的前端源码用的是 Vue 3 + Vite，而这套源码大概率是基于 Vue 2 + Vue CLI + sass 的经典方案，它对 Node 版本很敏感。Node 18 环境下执行npm install时，node-sass 经常因为编译环境问题报错gyp ERR!。如果你遇到这种问题，最快的解决方案不是手动npm rebuild node-sass，而是直接把 Node 切回 14.x，用 nvm 管理版本：

nvm install 14.17.0 nvm use 14.17.0 node -v

切完版本后删掉 node_modules 重新安装，基本就好了。

3.2 数据库初始化：导入 SQL、配置连接、处理时区问题

后端项目里一般都有一个sql目录，里面放着 init.sql 或者 hospital.sql。初始化数据库的操作很简单，但有几个细节值得注意。

先在 MySQL 里创建字符集为utf8mb4的数据库：

CREATE DATABASE hospital_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;

然后用命令行导入 SQL 脚本：

mysql -u root -p hospital_db < hospital.sql

导入成功后有配置信息进来看一下核心表是否都建出来了。注意，utf8mb4和utf8的区别在于前者能存 emoji 表情，医疗系统里患者姓名和备注偶尔会出现特殊字符，用utf8mb4更保险。

接下来打开后端的application.yml，主要针对数据库连接部分做修改：

spring: datasource: url: jdbc:mysql://localhost:3306/hospital_db?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai username: root password: your_password driver-class-name: com.mysql.cj.jdbc.Driver

这里有两个高频坑。第一个坑：如果你用的是 MySQL 5.7，driver-class-name写成com.mysql.jdbc.Driver和com.mysql.cj.jdbc.Driver都能运行；但如果用了 MySQL 8.0，驱动必须写com.mysql.cj.jdbc.Driver，否则启动直接报ClassNotFoundException。

第二个坑是serverTimezone=Asia/Shanghai。不写这个参数时，MySQL 8.0 会报服务器时区不明确的错误；如果写UTC，又会导致 Java 端查询到的时间比本地时间晚 8 小时，所有“今天挂号量”这种统计前一天晚上 8 点就提前结算了，数据对不上。所以无论如何都要写成Asia/Shanghai。

3.3 前端和后端的启动步骤

启动顺序一般是“先后端，再前端”，也可以并行，但后端先起来方便前端联调。

后端部分：用 IDEA 打开后端工程，等 Maven 把依赖下载完，确认application.yml里数据库连接没问题，直接运行主类HospitalApplication或类似名称的入口类。控制台出现Started ... in x.xxx seconds就说明启动成功。默认端口一般是8080，如果端口被占用，可以在application.yml里改：

server: port: 8080

前端部分：用 IDEA 或者 VS Code 打开前端目录，执行安装依赖。

npm install

依赖装完后启动开发服务器。

npm run dev

默认开发服务器端口一般是8080或8081。如果和后端端口冲突了，可以去vue.config.js里把 devServer 的端口改掉。我这里直接把前端端口固定为8080，后端改为9090，这样两个服务互不干扰。

前端访问地址一般是http://localhost:8080。第一次打开会跳转到登录页，这套源码一般准备了默认账号，比如 admin/admin123，具体以 SQL 脚本中的初始化数据为准。

3.4 踩坑实录：跨域、端口、依赖版本，这些坑我替你踩过了

部署过程中我踩了几个典型的坑，都列出来，你遇到时可以快速定位。

第一个是跨域问题。前端和后端都跑在 localhost 的不同端口时，浏览器会拦截非同源的 ajax 请求，控制台直接报Access-Control-Allow-Origin。解决方案有两个：如果你是用 Vue CLI 的 devServer，推荐用代理方式解决，在vue.config.js里加：

devServer: { proxy: { '/api': { target: 'http://localhost:9090', changeOrigin: true } } }

这样前端请求里所有/api开头的路径都会被转发到后端的 9090 端口，浏览器看到的还是同源请求，避免了跨域。

另一个方案是在后端统一处理跨域，在config包下加一个实现WebMvcConfigurer的配置类，重写addCorsMappings方法，允许指定来源和请求头。两条路都可以，但开发阶段更推荐代理方式，因为它离浏览器端更近，而且上线后你只需要让 Nginx 做类似转发，逻辑一致。

第二个坑是 JS 报错Cannot read property 'prototype' of undefined。这通常意味着 jquery 没引入成功或者 lodash 版本有冲突，检查一下 package.json 里的依赖版本，删掉 node_modules 和 package-lock.json 重新安装基本能解决。

第三个坑是后端启动后访问接口报 404。先看两个服务端口是否配对了，再看前端代理路径和后端接口前缀是否一致。这套源码里后端 Controller 的 RequestMapping 可能带/api前缀，也可能不带，你得去源码里确认一下，然后保证 vue.config.js 的代理路径和它匹配，否则所有请求都会打到错误地址返回 404。

第四个坑是数据库密码里有特殊字符，比如@、#，在 URL 里没转义会导致连接失败。解决方案是使用 YAML 的引号形式，或者直接在连接字符串里用 URL 编码。

第五个坑关乎 IDEA 的字符集。Windows 环境下如果控制台中文乱码，多半是 IDEA 默认用了 GBK，到 File -> Settings -> Editor -> File Encodings 里把 Project Encoding 改成 UTF-8，后端启动参数里加上-Dfile.encoding=UTF-8。数据库那边的连接串已经指定了characterEncoding=utf8，只要这里设置一致，中文就不会乱。

4. 读懂核心业务闭环：挂号-就诊-缴费-发药是怎么串起来的

4.1 挂号流程：号源、排班、患者信息的关联设计

挂号是这个系统的入口，也是流程的起点。社区医院的挂号相对简单，但它涉及三张基础资源的联动：患者信息、医生排班、号源状态。

在系统里，挂号员首先要根据患者的身份证号或手机号查档案。查到就直接选医生挂号，查不到就先建档再挂号。建档时采集姓名、性别、身份证号、联系电话、过敏史这些基础信息——过敏史是社区医院非常值得记录的字段，因为它直接影响后续医生开药的用药安全判断。

挂号记录的核心字段中有一个status，这就是整个业务链路的“状态机”开端。挂号成功后记录进入“已挂号”状态；医生开始接诊后变为“就诊中”；完成诊断和开方后变成“已就诊”；如果患者挂号后没来看病，最终会变成“已过期”或“已退号”。

这个状态设计看起来简单，但它决定了后续所有环节的可操作性。比如收费处只对“已就诊”状态并且处方金额已生成的患者做结算，这样就不会出现“还没看病先收钱”的流程漏洞。

4.2 医生工作站：接诊队列、诊断录入、处方开具的实现要点

医生登录系统后，屏幕上是当天的候诊队列。这个队列本质上是从挂号表按医生和时间维度查出来的，在源码中对应的大概是这样一类查询逻辑：

SELECT r.reg_no, p.name, p.age, p.gender FROM registration r LEFT JOIN patient p ON r.patient_id = p.id WHERE r.doctor_id = #{doctorId} AND r.reg_date = CURRENT_DATE AND r.status = 'WAIT' ORDER BY r.reg_time

点击“接诊”后，挂号记录的状态从候诊变成就诊中，医生开始录入诊断结果和处方。

处方开具是医生工作站最核心的功能。一张处方主表对应一个患者和一次就诊，明细表里则是多味药品，每一味药包含药品名称、规格、数量、用法用量、单价。这里最需要细心的是“用法用量”，比如“每日三次，每次一片”这种医嘱，最好是一个独立字段，方便药师审方，也为未来做用药合理性审核留了数据基础。

处方提交之后并不直接完成，而是进入“待收费”状态。医生开完方后患者去收费窗口，收费员看到的是待结算的处方，收费确认后才进入“待发药”状态。这个流程保证了药品和资金的两个闭环——钱没付，药不会发；药没发，处方不会结束。

4.3 收费结算：费用计算、支付方式、退费逻辑

收费模块在医疗系统里是最不容易出 bug 但最容易惹麻烦的部分，因为只要涉及钱，账目必须对得上。

收费处结算时，系统需要从处方明细里汇总药品金额，如果有诊疗费、挂号费，也要一并计算。收费方式一般是现金、微信、支付宝、医保个人账户等几种。这套源码的基础版本可能没有完整对接真正的支付网关，但它把支付记录和结算状态模型建好了，你可以在对应 Service 里改成调用真实的聚合支付接口。

收费完成后，记录进入 payment 表和处方表的 status 中，一处是“已收费”，一处是“待发药”。这两个状态在同一事务里更新，这样不会有“钱收了但药房没看到单”的问题。这里确实体现了@Transactional的应用价值。

退费逻辑比收费更考验设计。退费在实际业务里分为几种情况：患者因为药开错了要退一部分、患者缴费完不想看了要全额退、退费还分已发药和未发药两种情况。社区医院处理退费一般要严格一点——未发药时直接退费，已发药时先退药再退费，而且退费操作必须记录操作人，形成审计链路。这套源码里药房发药模块支持退药功能，退药后会回冲库存，再配合退费接口，就形成了一条可追踪的反向链路。

4.4 药房库存与发药：库存扣减、退药回冲、超量预警

药房这块属于业务系统里的“账实相符”核心。药房药师看到“待发药”的处方后，逐项核对处方明细和实物药品，确认无误后点击发药。

发药动作的第一个后果是扣减库存。这里有个需要注意的设计细节：发药时扣的不应该是药品主表里那个简单的stock字段，而是应该在库存流水表里生成一条扣减记录。为什么？因为一旦后续发生退药，或者月底盘库存发现账实不符，你必须有审计依据，能追溯“某天某张处方的发药导致库存减了 5 盒”。如果只改一个数字，账面上根本查不出历史变动。

库存预警也是社区医院很实用的功能。当某个药品的库存量低于设定阈值时，系统应该在药品管理列表里高亮提示，甚至生成采购建议。这套源码里如果有药品库存管理的模块，你可以看看是否存在stock_warning之类的字段设计，没有的话，二次开发时加上这个字段和判断逻辑并不难。

4.5 整个链路的“状态机”和数据一致性总结

把整套流程放在一起看，就会发现业务的本质其实是一张状态流转图：

挂号（WAIT） → 就诊中（DIAGNOSING） → 已就诊且处方待收费（WAIT_PAY） → 已收费待发药（WAIT_DISPENSE） → 已发药（COMPLETED）

任何一环没完成，下一环就不能操作。这套“状态驱动”的设计与真实的门诊流程是一致的。技术人员理解这一点后，改起代码来会顺很多——你要加一个新环节，比如“检验申请”，本质就是在状态机上插入一个节点，新增对应的表和状态字段，然后在界面层加一个操作入口。

数据一致性靠的是数据库事务。以“收费完成并生成发药任务”为例，你需要在一个事务里同时更新 payment 表和 prescription 表的 status，如果其中一个更新失败，整个事务回滚。SpringBoot 的@Transactional注解天然支持这个需求，源码里收费 Service 方法上如果没加这个注解，你二次开发时要留意补上，这是医疗系统里绝对不能省略的工程纪律。

5. 企业级的另一面：权限、日志、安全加固与性能排查

5.1 RBAC 权限模型：角色、菜单、接口三层控制

社区医院系统里有明确的分工界限，所以权限模型不是可选项，而是必需品。这套系统采用的模型是经典的 RBAC（基于角色的访问控制），核心表就是 sys_user、sys_role、sys_menu 三张表。

具体来说，用户表存账号和密码，角色表定义一个角色是什么身份，菜单表把系统功能做成树形结构挂在角色上。登录后系统根据当前用户的角色查出可见菜单，前端路由也被权限控制约束。

但只看前端是不够的，真正的权限控制必须在后端接口层面再做一次校验。因为前端的所有操作都是可被绕过的，如果用户手动调一个删除接口，后端不做鉴权就会出大事。常规做法是在接口上用注解标注权限标识。

这套源码如果在 WebMvcConfig 里配置了拦截器，并且拦截器里对访问的接口做了权限码校验，那么这个系统的权限体系是基本完整的。你二次开发新增接口时，要记得同步维护权限表，否则就会出现“新增了功能，但角色菜单里找不到入口”或者“接口没权限控制，谁都能调”这两种问题，前者还好，后者是真隐患。

5.2 登录认证与密码存储：不能再用明文密码了

早年很多源码项目登录认证都写得特别“年轻”，把密码明文放在数据库里，登录就是拿账密比对一次，连 Session 都不管。这套源码如果是近期整理的，大概率用了 BCrypt 加密。

BCrypt 是 Spring Security 生态里常用的密码散列算法，特点是每次加密的盐值不同，即使两个用户密码相同，生成的密文也不同，能防止彩虹表攻击。如果你发现系统的sys_user表里密码是$2a$10$开头的一长串，那就说明它已经用了 BCrypt 或类似算法，这是值得认可的设计。

登录认证方案上，基础版可能用 Session，进阶版可能用 JWT。如果源码里用的是 JWT，那你需要注意 token 的过期时间、刷新机制以及注销时的 token 失效问题——社区医院场景对安全要求高，一般不建议用无状态 JWT 代替完整的 Session 管理，因为 JWT 一旦签发，在过期之前很难主动让它失效。如果这套源码是用 JWT，你可能需要自行封装一个 Redis 黑名单机制来处理“用户被禁用但 token 仍有效”的问题。

5.3 操作日志与审计：谁在什么时间做了什么不能乱

医疗系统的操作审计有非常现实的业务需求：退费必须知道是谁退的，改库存必须知道是谁改的，删除药品信息必须知道是谁删的。

最规范的实现方式是 AOP 日志体系。定义一个日志注解，比如@OperLog(module = "药品管理", action = "删除药品")，然后通过切面拦截 Controller 方法，自动把操作人、操作 IP、请求参数、操作结果写入日志表。这样业务代码里不需要到处写日志逻辑，后期想查操作链路时，直接查操作日志表就行。

我在评估一套业务源码是否“企业级”时，操作日志是一个关键观察点。没有操作日志的系统，出问题无法追溯，是致命的缺陷。这套源码如果已经做了日志模块，你可以学它的设计思路；如果没做，我建议后续后补也优先补这个模块，工作量不大，但价值极高。

5.4 常见的 Web 安全防护：SQL 注入、XSS、弱口令

MyBatis 用#{}占位符就是天然防 SQL 注入的，推荐 SQL 中都用#{}而不是${}。但如果源码里出现${}拼接，要特别警惕，尤其是在 order by 排序、动态表名这类场景中。你二次开发时要确保所有用户输入都不能直接进入${}拼接。

XSS 防护方面，前端可以用 Vue 自带的转义防护，后端则要在接收参数时做安全过滤。Cookie 的配置也要注意，比如设置HttpOnly防止脚本读 cookie，设置SameSite限制跨站请求。

弱口令问题在业务系统中非常常见。我拿到任何一套源码后，第一件事是改默认密码。如果源码的初始化 SQL 里写着admin/admin123，正式使用前必须改掉，并且加上密码复杂度策略。这不是技术复杂度的问题，而是安全习惯的问题。

5.5 性能排查：SQL 打印、慢查询日志、索引优化三板斧

社区医院的并发量一般不高，但查询时间一长用户体验就会很差，典型的场景是患者列表或者报表页面每次加载要 3 秒以上。

性能排查的第一板斧是让 MyBatis 打印 SQL。在application.yml里加配置：

mybatis: configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl

启动后在控制台能看到每次执行的完整 SQL 和参数。你可以拿这条 SQL 去 MySQL 里执行一下，看耗时到底花在哪个环节。

第二板斧是开启 MySQL 的慢查询日志。临时开启可以用：

SET GLOBAL slow_query_log = 'ON'; SET GLOBAL long_query_time = 1;

执行时间超过 1 秒的查询会被记录下来，定位主要性能问题。

第三板斧是索引优化。在慢 SQL 的 WHERE 和 ORDER BY 字段上添加合适的索引。注意，联合索引的字段顺序有讲究，最常用的筛选条件要放最前面。社区医院系统最典型的高频查询是“按日期区间查挂号记录”，那么在 registration 表的 reg_date 上建索引，通常能解决大部分报表慢的问题。

6. 这套源码还能怎么改：功能扩展与二次开发思路

6.1 接入微信小程序预约挂号：前端加功能还是换入口

社区医院最实用、收益最大的扩展就是微信小程序预约挂号。它的核心需求是让患者不用到现场排队，在手机上选科室、选医生、选时间段，生成预约号，当天再取号。

这个扩展在架构上就是新增一套小程序端，复用后端已有的医生排班和挂号接口。你需要新增的是预约挂号的独立查询入口、预约记录表、取号机制。具体来说，可以在 registration 表上增加一个预约字段和来源字段，再把“预约”和“当日挂号”做成两种状态。

后端新增几个接口：按科室查医生排班、生成预约订单、取消预约、到院确认取号。这些都是常规的 CRUD 加状态流转，对会读这套源码的开发者来说难度不大。小程序端可以用 uni-app 开发，一套代码兼容微信和支付宝小程序，维护成本低。

6.2 电子病历与检验检查报告：从纯文本走向结构化

很多社区医院对电子病历的需求从“能记就行”开始升级为“能查、能统计、能打印”。源码基础版如果只有简单的诊断文本，二次开发时可以做成结构化病历模板。

比如全科门诊的病历模板可以包含主诉、现病史、既往史、体格检查、诊断意见等字段，存储在独立的 medical_record 表，而不是塞在诊断的一个长文本里。这样后续做慢病管理、按诊断检索患者都会方便很多。

检验报告的结构化也是热门方向。常见做法是引入检验项目和结果值的模型，把“血常规”“尿常规”做成一个检验模板，每一项有统一的编码和参考范围，结果录入后自动判断异常并标红。这块能做的东西很多，但建议从最小闭环起步——先支持血常规、尿常规几个高频模板，跑通后再扩展。

6.3 数据统计大屏：让院长一眼看清全院运营情况

社区医院的管理者非常需要可视化的运营数据，比如今日门诊人次、各科室挂号占比、药品消耗排行、收费金额趋势、慢病随访完成率。现成源码如果这些指标是分散在多个页面的，二次开发时可以接一个数据大屏。

前端用 ECharts 做图表并不难，难在后端要提供能算出这些指标的聚合查询接口。比如“按小时维度统计今日挂号人次”，SQL 长这样：

SELECT HOUR(reg_time) AS hour, COUNT(*) AS cnt FROM registration WHERE reg_date = CURDATE() GROUP BY HOUR(reg_time) ORDER BY hour

这类统计 SQL 在 MySQL 里写起来非常顺手，正好是 MyBatis 的强项。你只需把这些接口整理成一个 dashboard 模块，给大屏提供一个一揽子的聚合数据接口即可。

6.4 消息通知：短信、钉钉、企业微信的通知通道

社区医院系统里消息通知的应用场景很多：体检报告出来后通知居民取报告，预约挂号成功通知患者，药品库存不足提醒采购员，系统异常提醒管理员。

这块的扩展思路是统一封装一个消息服务接口。最容易落地的方案是接入钉钉/企业微信的 webhook——免费且有现成的开发文档。代码层面你只需要在 util 包下做一个 HttpUtils，然后封装一个sendDingTalkMessage(webhookUrl, content)方法，在业务关键节点触发即可。

等到流程稳定了，再考虑接入阿里云短信服务或者腾讯云短信，把验证类、通知类消息发到手机。短信渠道是有成本的，所以一定要做模板管理，比如“预约成功通知模板”“退费处理完成模板”，不要随便在业务代码里硬编码短信文案。

6.5 多机构支持：一套代码跑多个社区医院

如果你想拿这套源码做产品化，最值得考虑的是多机构扩展。社区医院通常是一个区县下面有若干家，每家的科室配置、药品目录、收费项目略有差异。如果每家用一套独立系统，升级维护成本是很高的。

多机构扩展的做法并不复杂：在核心业务表上增加dept_id或org_id字段，登录时根据用户归属机构限定数据范围；药品目录、科室表、收费项目表改成按机构存一份；基础数据表和流水表区分开。这样一来，一套系统部署在云端，就能服务多家社区医院。当然，数据库索引要加上机构维度，否则查询会串数据。

这种改造本质上是把单租户系统改成伪多租户模式。虽然比不上云原生那种真正的多租户隔离，但对小型医疗机构的场景已经足够实用，性价比很高。

7. 关于这套源码的实话实说：值得参考的点、需要补强的坑、学习路线建议

7.1 这套源码里真正值得认真学习的部分

我觉得这套源码最有学习价值的不是某个具体功能，而是它的完整业务闭环和状态设计。很多教学项目里，学生写的系统都是“有多少张表就做多少个 CRUD 页面”，业务之间没有状态联动。而这套源码严格实现了“挂号之后才能开药方向，缴费之后才能发药”，这种流程驱动的设计是真实业务系统与教学项目的最大差别。

第二值得学习的是分层架构的纪律性。Controller、Service、Mapper 各司其职，该加事务的地方用注解，该统一异常的地方有全局处理，这些工程规范在求职面试里是非常加分的谈资。很多简历上写“熟悉 SpringBoot”，但是对三层架构的落地细节和工程化处理说得模糊。如果你把这份源码彻底读透，面试时能把“为什么要在 Service 层加事务”“为什么接口返回要包一层 Result”讲清楚，说服力远比背八股文强。

第三是 MyBatis 动态 SQL 和联表查询的实际写法。文档里看 100 遍不如在一个真实系统的 Mapper XML 里读 10 遍。尤其是“条件可选查询”和“分组统计”这两类 SQL 写法，在业务开发中实在太常用了。

7.2 需要自行补强的部分和合规提醒

客观讲，这套源码在医疗业务合规方面只能算一个起点，不能直接当生产环境系统用，尤其是涉及“医疗”这个强监管领域时。

第一是电子签名问题。医生的处方和病历如果没有合法的电子签名，严格来说在医疗纠纷中是站不住脚的。源码基础版里大概率只是普通账号登录，没有对接 CA 数字证书或手写板签字。如果真要上线使用，这是优先要补的合规能力。

第二是网络安全等级保护。医院属于重点行业，通常要做等级保护测评和备案。等保要求涉及日志留存、备份恢复、访问控制、安全审计等多方面维度。源码本身的技术设计无法直接满足全套等保要求，必须结合网络环境、运维制度一并整改。

第三是数据备份。医疗数据的重要性非常高，系统必须每天自动备份数据库，并且至少保存 90 天以上。你可以在服务器上写 crontab 定时执行 mysqldump，然后传输到异地存储，这是成本最低、但最关键的一步防线。

第四是医保对接。如果社区医院要支持医保实时结算，那不能靠改这套业务代码实现，而是要对接医保平台提供的接口规范，按国家下发的接口文档做专门的集成开发。这部分工作量很大，而且完全不能凭想象实现，只能按官方规范来。

7.3 我给这门源码学习者的实践路线

如果你今天刚拿到这套源码，我建议你按照下面这条路线走，而不是拿到就急着启动：

第一步，先把数据库脚本过一遍，把核心表之间的关系画出来。这一步建立的是业务模型认知，也是后面读代码的基础。

第二步，把前后端项目分别启动，用一个测试账号操作一遍完整业务流：挂号、写诊断、开药、收费、发药。这个过程中不断思考“页面上的这个按钮，到底对应的是哪张表的哪个字段变化”。

第三步，用调试器在关键断点处停住，比如挂号接口和收费接口，亲眼看看一条数据在业务链路不同阶段的状态值变化。这一步是理解状态机最快的方式。

第四步，挑一个模块做一次二次开发，比如给药品管理加一个“库存预警”开关，或者给挂号列表加一个“出生日期”筛选。明确改动了哪一层、哪张表、哪个 SQL，把改动前后写成文档。

把这四步走完，你对这套源码的理解就不仅仅是“能跑”，而是真正内化了一整套业务系统开发的方法论。等到你需要自己从零设计一个相似规模的业务系统时，你会发现那套状态流转和分层设计已经成了你的默认思维方式。