1. 项目整体设计与技术选型1.1 社区医院信息平台到底在解决什么问题社区医院和大型三甲医院的信息化需求差异非常大。三甲医院追求高并发、高可用、多系统集成而社区医院的核心痛点往往更朴素一个社区服务中心可能只有十几名医生和护士服务周边两三千名居民日常业务包括门诊挂号、健康档案建档、慢病随访、药品出入库等。很多这样的机构还在用Excel表格加纸质病历运转数据分散在个人电脑里想查一个居民的历史就诊记录要翻半天。我当时接到这个需求的时候第一个想法是这套系统不需要追求功能大而全但必须把“让基层医护愿意用”这件事做好。所以项目的核心定位是轻量化、易操作、覆盖社区医院日常医疗服务的全流程。从业务流程上看社区医院的一天大概是这样的居民到院先挂号医生接诊时查看居民的既往档案和就诊历史开具诊断和处方患者到药房窗口取药收费处结算慢病患者需要定期随访提醒。围绕这条链路系统需要划分成七个核心模块系统管理用户、角色、菜单权限、患者档案管理、预约挂号与现场挂号、医生工作站接诊、病历、处方、药房管理库存、发药、收费管理、数据统计。这个设计思路的关键在于数据贯穿全流程。从患者建档的那一刻起每一次挂号、每一次就诊、每一张处方都会沉淀到数据库里后续的统计报表和随访提醒才能有据可依。这也是这套系统区别于简单增删改查演示项目的地方业务流程是有闭环的。1.2 为什么是SpringBoot Vue MySQL MyBatis这套组合技术选型的时候我认真对比过几套方案。重量级的SpringCloud微服务方案社区医院那点儿并发量根本用不上反而增加了部署和维护成本。SSHSpringStrutsHibernate那套老古董更不用考虑开发效率太低。最终确定的SpringBoot Vue MySQL MyBatis是综合考虑了开发效率、维护成本、人才储备和社区生态之后的结果。SpringBoot选得没有悬念。它把Spring家族里那些繁琐的XML配置全都收进了自动配置里一个注解就能把项目跑起来。对于社区医院这种单机部署就能满足需求的场景SpringBoot内置的Tomcat容器特别合适打成jar包直接扔到服务器上就能跑。Vue作为前端的理由也很直接。后台管理系统的核心交互是表格、表单、弹窗、选项卡这种密集型的组件化界面。Vue的组件化开发思路和Element UI这套现成的UI组件库配合起来开发效率是碾压级的。而且Vue的学习曲线相对平缓上手成本低社区里能参考的案例很多。MySQL和MyBatis这对组合我得重点说两句。很多新手会纠结用MyBatis还是JPA。社区医院系统里有一个特别典型的场景统计报表。按科室统计门诊量、按时间段统计药品消耗、按病种统计就诊人数这些查询离不开多表关联和复杂的聚合函数。MyBatis对这些场景的掌控力是最强的SQL就写在XML里调优的时候直接对着语句改就行数据库里怎么执行程序员一目了然。JPA那种自动生成的SQL在简单CRUD时确实省事一旦遇到动态查询条件多了生成的SQL可能和你想的完全不一样排查起来反而费劲。MySQL则是开源数据库里最成熟的方案社区医院预算有限许可证费用能省则省。1.3 系统架构的分层设计思路整个系统采用前后端完全分离的架构。后端只提供RESTful风格的JSON接口前端通过Axios异步调用。部署时用Nginx托管Vue编译后的静态文件同时反向代理到后端的8080端口从根上解决跨域问题。后端代码按经典的三层架构划分Controller层负责接收HTTP请求、参数校验、结果封装。Service层存放核心业务逻辑比如挂号时校验号源余量、开处方时扣减库存。Mapper层只负责和数据库打交道每个接口对应一个SQL操作。前端按Vue的标准工程组织方式划分views目录存放页面级组件比如挂号页面、医生工作台、药房管理页面。components目录存放可复用的业务组件比如患者信息卡片、日期选择器。router目录配置前端路由同时根据登录用户的角色动态生成可访问的菜单。store目录用Vuex管理全局状态比如当前登录用户信息、系统字典数据。api目录把所有后端接口按模块封装成独立的JS文件页面里只调函数不直接写URL。这套分层的好处是职责单一、便于协同。我写后端接口的时候不需要关心前端页面长什么样前端同事也只需要按照接口文档调用两边并行开发互不阻塞。2. 数据库设计的核心细节2.1 建表思路与核心表结构拆解数据库设计是这类管理系统的地基。地基没打好后面写业务代码时到处都是坑。我按照“一个患者为中心一条就诊流为主线”的思路设计了整个库表结构最终落地的核心表有十几张这里挑几张关联最密切的展开讲讲。患者信息表是这套系统的数据枢纽。社区医院的特点是服务半径内居民相对固定所以患者的健康档案必须完整。表里的核心字段包括姓名、性别、出生日期、身份证号、联系电话、既往病史、过敏史、家庭住址。身份证号这个字段我特意设计了唯一索引既能防止重复建档也为后续按身份证检索就诊历史提供了保障。预约挂号表是整个业务链路的起点设计的时候我花的心思最多。表结构大致是这样CREATE TABLE appointment ( id BIGINT PRIMARY KEY AUTO_INCREMENT, patient_id BIGINT NOT NULL COMMENT 关联患者ID, doctor_id BIGINT NOT NULL COMMENT 关联医生ID, appointment_date DATE NOT NULL COMMENT 预约日期, time_slot TINYINT NOT NULL COMMENT 时间段1上午 2下午, status TINYINT DEFAULT 0 COMMENT 状态0待就诊 1已就诊 2已取消 3爽约, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_patient_slot (patient_id, appointment_date, time_slot), KEY idx_doctor_date (doctor_id, appointment_date) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT预约挂号表;这个表设计上有几个细节值得说道。首先联合唯一索引uk_patient_slot保证了同一个患者在同一天同一个时间段只能挂一个号这个约束放在数据库层面远比在应用层判断可靠。其次时间段的取值用TINYINT枚举1代表上午、2代表下午查询统计时用CASE WHEN转成可读文案即可没必要在表里存字符串。最后是状态字段用了0到3四个数字代表不同状态将来想增加状态比如“已退号”不用改表结构。医生排班表的设计走了另一条路线。社区医院规模不大排班规则相对固定每个医生一周七天里哪几天出诊、上午还是下午提前维护好。代码里做号源初始化时根据排班表批量生成未来14天的可预约号记录每半天默认放20个号。这个号源数量的设定我是按社区医院的实际接待能力估算的一个全科医生半天看二十个病人已经接近饱和了挂满之后患者只能选其他日期或者现场排队。2.2 关系映射与查询优化的取舍数据库设计里有个经典矛盾表结构规范化和查询效率的平衡。MyBatis在处理一对多、多对多关系时很灵活但如果不加以控制很容易掉进N1查询的性能陷阱。以“查询一个患者的完整就诊记录”这个需求为例。如果严格遵循第三范式需要查就诊记录表再根据就诊记录逐条查对应的处方明细这样就会产生 1 N 次SQL查询。我的处理方式是在就诊记录表上做了适度的冗余设计CREATE TABLE medical_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, patient_id BIGINT NOT NULL, doctor_id BIGINT NOT NULL, diagnosis VARCHAR(500) COMMENT 诊断结果, complaint TEXT COMMENT 主诉, prescription_snapshot TEXT COMMENT 处方快照, total_amount DECIMAL(10,2) COMMENT 费用金额, visit_time DATETIME DEFAULT CURRENT_TIMESTAMP, KEY idx_patient_time (patient_id, visit_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT就诊记录表;处方快照字段把这一单的药品明细药品ID、名称、单价、数量、用法用量以JSON格式存进去。这样查询就诊历史时只查一次这张表就够了拿到JSON直接解析成前端要的结构完全不用连表查询。这种冗余在特定的业务场景下非常好用——历史记录本质上是不需要修改的一旦就诊结束处方内容就固定了快照存储既保证了数据一致性又把查询性能拉满。不过这里有个前提快照不能承担所有职责。药房发药、库存扣减仍然依赖独立的处方明细表因为那些场景需要对每条记录做修改。我的习惯是“数据链路的实时业务走规范化结构历史展示场景走快照冗余”按需取舍才能兼得。2.3 字段类型与字符集选择的经验MySQL建表时有两个经验值值得分享。第一字符集统一用utf8mb4而不是utf8。MySQL的 utf8 字符集是阉割版只有三个字节遇到特殊表情符号或者生僻字会直接报错。社区医院录入患者姓名碰到“王陶”这种生僻字用的是扩展区字符要用四个字节编码只有utf8mb4存得下。第二所有表都加一个create_time创建时间和update_time更新时间字段虽然会多写几行SQL但排查问题、做数据同步、写审计日志时都离不开它们。DECIMAL类型用来存金额这个不用多说。让我意外的是社区医院系统里工时排班这种看似简单的需求在字段设计上反而容易踩坑。比如排班表里的开始时间和结束时间我一开始用的是DATETIME类型后来发现在做跨天排班比如夜班门诊从22点到次日2点、统计医生月度工作量的时候非常别扭。后来干脆拆成work_date日期和time_slot时段两个字段统计查询瞬间简单了。这种属于典型的被需求捶打过之后才学乖的设计决策代码里写起来是绕路但报表统计时不绕路。3. 后端核心模块的实现与实操3.1 SpringBoot工程搭建与基础配置创建一个SpringBoot工程看起来很简单用Spring Initializr点几下就行但依赖版本的选择有讲究。社区医院系统考虑到后端部署环境大概率是Tomcat 8.5或者更新的版本我用了SpringBoot 2.7.x版本对应JDK版本8或11都没有兼容性问题。这里提醒一下SpringBoot 3.x必须配套JDK 17如果服务器上没装新环境打包后跑不起来会很被动。工程里pom.xml的关键依赖大致是这样dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.mybatis.spring.boot/groupId artifactIdmybatis-spring-boot-starter/artifactId version2.3.1/version /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId version8.0.33/version /dependency dependency groupIdio.jsonwebtoken/groupId artifactIdjjwt/artifactId version0.9.1/version /dependency /dependenciesMyBatis的整合配置里有两个参数我必须强调。第一个是map-underscore-to-camel-case: true开启后数据库的下划线字段名自动映射到Java类的驼峰属性比如数据库的patient_name映射到patientName省去大量手写resultMap的时间。第二个是configuration.log-impl开发阶段设成org.apache.ibatis.logging.stdout.StdOutImpl这样MyBatis会把每一条执行的SQL和参数原样打印到控制台排查SQL问题全靠它。上线前记得把这个日志切走避免刷屏影响性能。3.2 JWT登录鉴权和角色权限的落地实现社区医院系统里天然存在三种角色管理员、医生、药房收费员。权限控制的设计原则是医生能查看和管理患者的诊疗信息但看不到药品采购价格和财务流水药房收费员能操作库存和收费结算但看不到患者病历详情管理员拥有全部权限。我用JWT实现登录状态管理。用户登录成功后后端生成一个token把用户ID、角色和过期时间编码进去。前端每次请求都在Header里带上这个token后端通过拦截器验证token有效性顺便把当前用户的上下文信息解析出来。SpringBoot里实现这一套并不复杂Component public class JwtInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) { if (OPTIONS.equals(request.getMethod())) { return true; } String token request.getHeader(Authorization); // 解析token失败则返回401成功则把用户信息放入ThreadLocal JwtUtils.parseToken(token); return true; } }配合权限点的使用我的做法是在Controller方法上添加自定义的RequireRole(ADMIN)注解拦截器里检查当前用户的角色是否匹配。这种方式比在代码里到处写if (user.getRole() ! ADMIN)优雅得多新增接口时只需要在方法上标注一下即可。关于token过期时间我设置了8小时。考虑到医护人员的上班节奏门诊时间是早上八点到下午五点半8小时的过期时间刚好覆盖一个工作日中间不需要重新登录。这个值不是拍脑袋定的是基于使用场景推算的短了影响体验长了增加安全风险。3.3 MyBatis动态SQL在复杂业务中的应用社区医院系统的业务里动态SQL用得最频繁的场景是挂号记录的多条件组合查询医生可能按日期查管理员可能按科室和状态查患者档案可能需要按姓名和手机号模糊查。MyBatis的where和if标签在这种场景下简直是神器。举一个实际的例子查询挂号记录列表select idqueryAppointmentList resultTypeAppointmentVO SELECT a.*, p.name AS patientName, d.name AS doctorName FROM appointment a LEFT JOIN patient p ON a.patient_id p.id LEFT JOIN doctor d ON a.doctor_id d.id where if teststartDate ! null AND a.appointment_date gt; #{startDate} /if if testendDate ! null AND a.appointment_date lt; #{endDate} /if if testdoctorId ! null AND a.doctor_id #{doctorId} /if if teststatus ! null AND a.status #{status} /if if testpatientName ! null and patientName ! AND p.name LIKE CONCAT(%, #{patientName}, %) /if /where ORDER BY a.appointment_date DESC, a.time_slot ASC /select这里有几个细节要说明。日期比较用gt;和lt;这是XML文件里对大于号和小于号的转义直接写会被解析器报错。模糊查询用CONCAT(%, #{patientName}, %)而不是直接写成%${patientName}%前者用预编译占位符不会有SQL注入风险后者用的是字符串拼接如果是用户在输入框里乱写单引号直接就把SQL语句搞坏了。另一个常用场景是批量插入。药房入库时需要一次性录入几十甚至上百条药品记录如果在Java代码里循环调用单条插入会严重拉低性能。MyBatis的foreach标签支持一条SQL批量插入insert idbatchInsert INSERT INTO drug_stock (drug_id, batch_no, quantity, expire_date) VALUES foreach collectionlist itemitem separator, (#{item.drugId}, #{item.batchNo}, #{item.quantity}, #{item.expireDate}) /foreach /insert实测批量插入100条记录整体耗时大约是单条循环的十分之一左右这个差距在高频业务场景里是本质性的。不过批量插入有SQL长度限制MySQL默认的max_allowed_packet是4MB一批插入的控制在几百条内都没问题。3.4 挂号与开处方这两个核心业务的事务控制我特别叮嘱自己要把事务控制在业务逻辑的正确层面上。挂号这个操作表面上只影响挂号表一条记录实际上涉及两步往挂号表插入新记录同时把当天的剩余号源减一。如果先插入后扣减号源中间发生异常数据库里会留下一条挂了号但号源没减的数据医生排班查询就会显示有余号但号源实际已经售出。这就需要用Transactional把两步操作包进同一个数据库事务里。开处方是更复杂的事务场景。医生在界面上勾选药品、填写用法用量、提交后后端要做的事情包括写入处方主表、写入处方明细表、逐条扣减药品库存、更新就诊记录里的处方快照和费用金额。这四步必须是一个原子操作任何一个环节失败都要让全部数据回滚。我用一个完整的Service方法承载整个流程在方法上标注事务注解。Transactional(rollbackFor Exception.class) public PrescriptionResult createPrescription(PrescriptionDTO dto) { // 1. 校验处方中药品库存是否充足 checkStock(dto.getItems()); // 2. 写入处方主表 Prescription pres buildPrescriptionEntity(dto); prescriptionMapper.insert(pres); // 3. 写入处方明细并逐条扣减库存 for (PrescriptionItem item : dto.getItems()) { prescriptionItemMapper.insert(item); drugStockMapper.reduceStock(item.getDrugId(), item.getQuantity()); } // 4. 更新就诊记录快照和费用 medicalRecordMapper.updatePrescriptionSnapshot(...) return result; }事务的隔离级别用默认的即可社区医院系统的并发量还不至于触发脏读、幻读这类问题。但rollbackFor Exception.class这个设置很关键Spring的默认策略是只对运行时异常进行回滚如果业务代码里catch了异常又不向上抛事务就会失效。这种问题定位起来特别隐蔽我当时排查一个“库存扣了但处方没生成”的Bug最后发现是某个子方法内部吞掉了异常导致上游事务认为一切正常但数据已经写到一半了。解决办法就是上面的做法子方法不处理异常统一抛给事务管理器。4. 前端Vue工程的构建与页面实现4.1 Vue工程初始化与项目结构规划前端工程我选择Vue 2.7 Element UI 2.x这个版本组合。之所以不用Vue 3一方面当时这个系统的目标服务器配置不高Vue 2对低版本浏览器的兼容性更好另一方面Element UI在Vue 2下的生态已经非常成熟表格、表单这些组件开箱即用开发效率最高。如果今天重新做我会考虑Vue 3 Element Plus但对于社区医院这种中后台管理系统Vue 2.7的技术栈完全不过时。工程创建直接用Vue CLI选上Router、Vuex和SCSS预处理器。在src目录的规划上我坚持一个业务模块对应一个views目录api目录里的方法按模块拆分。整个项目结构长这样src ├── api │ ├── appointment.js # 挂号相关接口 │ ├── patient.js # 患者档案接口 │ ├── prescription.js # 处方接口 │ └── login.js # 登录认证接口 ├── router │ └── index.js # 路由配置 ├── store │ ├── modules │ │ ├── user.js # 用户状态 │ │ └── dict.js # 数据字典 ├── views │ ├── login/index.vue # 登录页 │ ├── dashboard/index.vue # 工作台首页 │ ├── patient/index.vue # 患者管理 │ ├── appointment/index.vue # 挂号管理 │ ├── doctor/index.vue # 医生工作站 │ ├── pharmacy/index.vue # 药房管理 │ └── report/index.vue # 统计报表 └── utils └── request.js # Axios封装路由分为静态路由和动态路由两类。登录页和首页属于静态路由根据登录用户的角色动态添加菜单是前端实现后端权限控制的常见方式。用户在路由跳转前先调用后端接口获取当前用户的可访问菜单列表然后动态注册对应的Vue Router路由。我在这部分踩过一次坑动态新增路由时直接往router.addRoutes里塞数组前端能正常访问但要刷新页面后菜单才显示。后来发现是因为路由是异步加载的菜单渲染先于路由注册完成。解决办法是使用时守卫在router.beforeEach等待菜单和动态路由都加载完成后再放行页面访问。4.2 Axios封装与接口联调的关键细节Axios请求工具类的封装直接决定了整个前端的代码规范性。我在utils/request.js里统一配置了请求的基础路径、超时时间、请求拦截器和响应拦截器。请求拦截器负责从localStorage里取出token拼到HTTP头里。响应拦截器统一处理状态码后端返回200直接放行返回401说明token过期清理本地登录态并跳转到登录页返回500则用Element UI的Message弹出错误提示给用户。这里面有一个细节特别容易被忽略文件下载请求和普通JSON请求的Content-Type不同需要在拦截器里对responseType做判断否则后端返回的文件流会被当成JSON解析表现为下载的文件全是一堆乱码字符串。接口联调阶段我习惯把一个模块的所有API集中在一个JS文件里管理这样改后端接口的时候在前端改一处即可。比如挂号模块import request from /utils/request export function getAppointmentPage(data) { return request({ url: /appointment/page, method: post, data: data }) } export function createAppointment(data) { return request({ url: /appointment/create, method: post, data: data }) } export function cancelAppointment(id) { return request({ url: /appointment/cancel/${id}, method: put }) }有了这一层统一封装页面组件里不需要关心URL和参数细节只需要调用对应的函数即可。还有一个经验是开发阶段不要把API地址写死在.env.development文件中配置代理module.exports { devServer: { proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } }开发环境的请求路径是/api/appointment/page这种相对路径通过代理转发到后端服务彻底绕开了前端本地端口和后端8080端口之间的跨域问题。生产环境则交给Nginx做同样的反向代理。4.3 挂号与医生工作站页面的核心交互实现挂号页面是使用频率最高的页面交互设计直接影响医护人员的工作效率。页面上左侧是患者信息检索区支持按姓名、身份证号、手机号模糊搜索右侧是排班日历展示未来14天各医生各时段的号源情况。这个页面在Vue里的实现要点是号源数据接口返回的结构必须和日历组件的数据结构匹配。比如后端返回每个时间段的剩余号数前端在渲染时判断剩余号数是否为零为零的格子置灰并禁用点击。患者挂号的整个流程是这样的患者信息确认后页面上选择医生、日期、时间段点击“确定挂号”后调用createAppointment接口。成功弹窗提示挂号成功同时前端本地对号源的剩余数量做乐观更新乐观地认为扣减成功并刷新界面但最终以后端返回的新号源余量数据为准。医生工作站页面是表单密集型页面的典型代表。页面顶部是待就诊队列中间是患者的既往病史和过敏史信息下方是诊断表单和处方明细表格。处方明细表支持动态增删药品行选择药品后自动带出单价填完数量自动计算金额用Vue的计算属性实现起来特别顺手。这里有个交互上的细节处方明细里的药品库存是否充足前端要先做一个预校验。我在药品下拉框的数据里带上了stockQuantity字段医生添加药品填写数量时如果数量超出库存直接在校验规则里拦截并提示减少后端事务回滚的概率。这个优化虽然只是用户体验细节但在日常使用中能帮药房减少很多退单操作。5. 常见问题与排查技巧实录5.1 启动阶段的报错和配置问题总有新手卡在第一关SpringBoot项目启动就报错。社区医院这套系统里最常见的三类启动异常我都遇到过处理思路比较有代表性。第一类是数据库连接错误。现象是启动时报Access denied for user rootlocalhost或者Unknown database。前者八成是密码写错了后者是数据库没创建或名字不一致。排查方法很简单先用Navicat或命令行确认能否用配置里的用户名密码连上MySQL再确认application.yml里的库名拼写。第二类是端口被占用。报错长这样Web server failed to start. Port 8080 was already in use.我在调试时经常出现上一个SpringBoot实例没完全关掉或者系统里有其他服务占了8080端口。Linux下用netstat -tlnp | grep 8080找出占用进程kill掉即可。生产环境更要提前确认最好在配置里把端口单独提出来方便适配服务器上已有的应用占用情况。第三类是MyBatis映射找不到接口和XML文件。报错千奇百怪但根源基本就两类接口和XML文件不在同一个包路径下或者mapper-locations配置有误。SpringBoot中MyBatis默认扫描classpath*:mapper/**/*.xml如果XML文件放在了resources之外的目录打包时根本不会带上。看报错日志时注意Invalid bound statement这个关键字遇到它九成是XML的位置或命名空间不对。5.2 联调阶段的跨域与数据格式问题前后端分离项目联调时跨域问题是最普遍的绊脚石。开发阶段我靠的是上一节提到的Vue代理生产环境则用Nginx统一接收前端请求再反向代理给后端。配置大概是这样的server { listen 80; server_name your-domain.com; location / { root /var/www/hospital-frontend; index index.html; 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_pass http://127.0.0.1:8080/;末尾的这个斜杠。带了斜杠转发时会把URL前缀/api去掉后端收到的请求路径是/appointment/page如果没带斜杠后端收到的就是/api/appointment/pageController上没加/api前缀的话会直接404。这是个让人抓狂的细节排查了一次之后就会牢牢记住。联调阶段另一个高频问题是日期格式。前端传2024-06-20 14:30:00字符串给后端SpringMVC默认解析不了这种格式直接400报错。解决方案是在后端加一个全局的日期转换配置或者在实体类的日期字段上添加JsonFormat(pattern yyyy-MM-dd HH:mm:ss)注解。我已经养成了习惯所有返回给前端的日期字段都明确标注格式后端接收的参数列表里也用DateTimeFormat做约定宁可多写两行也不要让前端猜。5.3 性能排查一个典型的SQL慢查询案例系统上线跑了一个月后药房同事反馈库存查询页面越来越慢操作一次要等五六秒。我拿到问题后第一件事是到MySQL里开启慢查询日志定位到具体SQL语句。慢就慢在药品库存查询上。当时的查询逻辑是把药品的库存表、供应商表、最近的入库记录表做多表关联。两张表的数据量都不过几千行理论上不该这么慢。用EXPLAIN查看执行计划后发现问题出在一张关联表的连接字段上——缺了索引。MySQL在非索引字段上做关联查询需要对那张表做全表扫描数据量小的时候不觉得一旦某张表涨到几万行性能就断崖式下跌。解决办法很简单在该表关联字段上补了一个普通索引ALTER TABLE drug_inbound_record ADD INDEX idx_drug_id (drug_id);加了索引后同样的查询从五点几秒降到了零点零几秒效果立竿见影。这个案例给团队留下的经验是一张表的查询变慢先看执行计划优先确认关联字段和WHERE条件字段有没有索引比绞尽脑汁优化SQL语句更有效。5.4 一套建议的排查工具体系排查运行期问题我建议界面上把三个工具用起来。第一个是MySQL的慢查询日志配置如下slow_query_log ON slow_query_log_file /var/log/mysql/mysql-slow.log long_query_time 1记录超过1秒的SQL语句定期查看这个日志就能发现性能隐患。第二个是SpringBoot的Actuator监控组件。引入spring-boot-starter-actuator之后通过/actuator/health查看服务健康状态通过/actuator/metrics查看JVM内存和线程信息。社区医院系统上线之初我靠它发现过内存缓慢增长的问题排查到最后是某个查询里创建的大对象没有及时释放。第三个是前端浏览器自带的Network面板。接口响应时间、状态码、请求参数一目了然。定位前后端问题的时候我首选就是先看Network面板它可以直接告诉我问题出在前端还是后端避免了两边互相推诿浪费时间的尴尬局面。6. 系统部署与上线后的运维要点6.1 打包流程与一键部署方案部署环节我踩过一些坑之后形成了固定的流程。后端在服务器上执行Maven打包mvn clean package -DskipTests打包后的jar文件用nohup java -jar启动nohup java -jar hospital-server.jar --spring.profiles.activeprod /var/log/hospital/app.log 21 这里有两个点需要特别提醒。第一是引入spring-boot-maven-plugin插件时一定要配置repackage的execution否则打出来的jar包是普通的可执行jar吗不用java -jar直接执行会报“没有主清单属性”。第二是SpringBoot多环境配置application.yml作为公共配置application-dev.yml和application-prod.yml分环境覆盖。启动时通过--spring.profiles.active指定用哪套配置生产环境数据源密码放在prod配置文件中不提交到代码库。前端部署是先把代码编译成静态文件npm run build编译产物在dist目录直接拷贝到Nginx配置的静态目录下即可。每次发版只需两步重新上传jar包和dist目录重启后端服务。整个发版流程控制在五分钟内对社区医院这种需要经常微调需求的小项目来说已经足够高效。6.2 数据库备份与安全的基线设置医疗数据的安全性优先级极高容不得半点马虎。我给这套系统设计的防线是三层第一层是MySQL账号权限分离。应用使用一个独立的账号比如hospital_app只授予SELECT、INSERT、UPDATE、DELETE权限不给DROP、TRUNCATE等高危权限。哪怕应用被攻击者注入也无法直接删库跑路。第二层是每天的自动备份任务。写一个简单的备份脚本放在crontab里每天凌晨2点执行mysqldump -u backup_user -ppassword hospital /backup/hospital_$(date %Y%m%d).sql find /backup -name *.sql -mtime 30 -delete第二条命令自动清理三十天前的备份文件防止备份文件占满磁盘。第三层是密码加密存储。系统里用户密码统一用BCrypt算法哈希后存储。BCrypt和MD5最大的区别是自带随机盐同样的密码每次加密结果都不同而且计算开销大想用彩虹表暴力还原成本极高。Spring Security框架自带BCrypt工具类直接用即可。6.3 上线后的迭代方向社区医院信息系统不用追求一步到位但有几个方向是上线后根据实际使用反馈值得迭代的。居民健康档案的电子化已经完成下一步可以接对接体检设备让血压、血糖这些数据自动同步到档案。慢病随访目前靠系统内的列表提醒未来可以对接微信服务号做主动通知把居民拉进来做自我健康管理。数据统计目前是后台表格后续做成可视化图表大屏在社区医院大厅展示当天的门诊量和药品库存概况既服务管理层也是对外展示的窗口。我在实际开发这套系统的过程中最大的感受是技术本身并不复杂真正的难度在于把自己带入用户角色去思考问题。医生在门诊高峰期没有时间琢磨复杂的界面药房发药要求每一步操作反馈必须明确。每次收到需求变更我都会先问一句这个修改能让医护人员少点一次鼠标吗能让患者少排一次队吗这个出发点对了系统的技术选型和架构设计都会跟着对。