企业官网建设流程全解析

先聊点实在的：社区医院管理系统这类项目，在我接触过的医疗信息化项目里，需求复杂度和技术含金量算是非常扎实的实训级课题。它不像纯电商网站那样只有简单的CRUD，而是要同时处理患者档案、医生排班、挂号、门诊、处方、药房库存、费用结算这些强关联业务场景，状态一变牵一发而动全身。正因如此，很多团队和企业都愿意用“Spring Boot + Vue + MyBatis + MySQL”这套组合来打底，这套架构各层职责清晰，能扛住真实业务的复杂度，又不会像微服务那样引入太多维护负担。这篇文章就围绕这套系统，从架构拆解、表结构设计、核心代码实现到部署踩坑，把能直接抄作业的细节都摊开讲。

这套系统适合谁看？如果你是刚准备做毕业设计或求职项目的Java后端方向同学，或者是在公司要快速搭建一套内部管理系统的开发人员，这篇内容可以帮你少走很多弯路。我会把从零到一的关键决策理由讲清楚，也会把那些文档里不会写的“坑”如实交代，比如为什么状态字段要用int而不用varchar、开处方和扣库存为什么必须在一个事务里、MySQL 8和旧驱动的连接差异到底在哪里。看完这套东西，你会明白一个“企业级”系统真正的复杂度核心在哪，而不是忙着堆前端组件。

1. 项目整体设计与技术选型思路

1.1 社区医院管理系统的业务全貌与需求拆解

社区医院和大型三甲医院的系统差异很大。三甲医院讲究专科化、设备对接、医保接口和复杂的流程引擎，而社区医院更看重“全科门诊 + 基本公卫 + 药房管理”的高效流转。说白了，社区医院系统要解决的核心问题就是：患者从进门到拿药离开，整个链路能不能被准确记录、能否在几秒钟内查到历史记录、财务上能否核对清楚每一笔账。

模块拆分上，一套完整的社区医院管理系统至少要覆盖：系统管理（用户、角色、菜单权限）、患者管理（建档、历史病历查询）、门诊业务（挂号、分诊、医生接诊、电子处方）、药房库存（入库、出库、盘点、效期预警）、收费管理（挂号费、诊疗费、药品费、退费）和统计报表（日营收、科室工作量、药品消耗排名）。只看这个清单就明白了，它表面上是个“管理信息系统”，实际上是一个带着强流程约束的业务系统，每一个模块之间都存在状态联动。

“企业级”这三个字，落在这个系统里主要体现在：第一，权限模型要能做到不同角色看到不同菜单和按钮，医生不能碰收费，收费员不能改药房库存；第二，数据要做到可追溯，患者每一次就诊记录、药品每一次出入库都要有操作痕迹；第三，并发控制要有章法，比如挂号高并发时段不能出现号源超卖、药房发药和库存扣减要对应上账。这套需求推演下来，技术选型其实就被定义得很清晰了。

1.2 技术选型逻辑：Spring Boot、Vue、MyBatis、MySQL 各就各位

先讲后端。Spring Boot在这套系统里的地位像是一个“精装修的毛坯房”——它把Spring MVC、依赖注入、事务管理、自动配置全部帮你编排好了。你用它的Web Starter就能快速把REST API撑起来，用它的@Transactional就能实现处方开立与库存扣减的原子性，用它的application.yml就能管理多环境配置。Spring Boot版本本身也值得细说，2.x时代很多配置靠WebSecurityConfigurerAdapter这种继承式写法，3.x之后全面转向组件式安全配置，所以如果你手里这份源码是旧版本的写法，升级Spring Boot版本时接口差异会让人折腾一阵子。

再讲持久层。MyBatis在这个项目里的优势是“SQL在手，天下我有”。医院管理系统的查询报表逻辑特别复杂，比如“统计某科室某天开了哪几类药品”、“查出一季度里所有血糖异常的慢病随访患者”，这种多表关联加条件聚合的SQL，如果用JPA自动生成，你很难控制它的执行计划和索引利用。MyBatis的半自动映射让你稳稳握住SQL性能的命门，也方便DBA后续针对慢SQL做优化。它和MyBatis-Plus、JPA的取舍后面再展开，本质上是一个“可控性优先”的选择。

数据库选MySQL，原因很务实：社区医院的项目预算通常有限，运维团队也不大，MySQL社区版完全满足五六百人规模医疗机构的场景，查询性能和稳定性早就被大量实践证明过。配合InnoDB引擎支持行级锁和事务，正好匹配门诊高峰期账务一致性的需求。最后前端用Vue，它是一个渐进式框架，模板语法贴近HTML直觉，一个负责挂号收费的基层工作人员操作界面，不需要像大型后台那样上重前端工程，Vue全家桶（Vue Router + Pinia/Vuex + Element UI/Element Plus）足以做出专业、响应快的管理系统界面。

1.3 前后端分离架构的取舍

这套系统选择前后端分离，是从“并行开发”和“部署弹性”两个角度做的决定。团队里一个同学专门负责Spring Boot接口，另一个同学专注Vue页面，两边并行推进，只要提前把接口文档约定好，效率会比JSP时代高很多。前端打出的静态资源可以部署在Nginx上做负载，后端服务也可以独立扩缩容。社区医院如果以后要对接大屏展示、小程序预约挂号，前端分离的架构也能直接用同一套后端API，不用重复开发。

分离架构也有代价，最典型的是跨域和鉴权。浏览器里前端的origin是http://localhost:8081，后端跑在http://localhost:8080，直接发ajax请求会被拦截，必须由后端配置跨域策略或由Nginx做反向代理。另外登录状态不能再依赖Session共享，因为前后端不共享容器，所以要引入无状态Token机制，让每次请求带上身份凭证。这一个设计决策，决定了你要在拦截器、配置文件、请求封装里做的事情有一长串。

2. 核心细节解析与数据库设计

2.1 数据库核心表结构与设计思路透彻拆解

先给出这套社区医院系统最关键的几张核心表，它们共同撑起业务主干。

患者表patient

• id自增主键
• medical_record_no病历号，唯一索引，这是患者建档后贯穿所有业务的凭证
• name姓名
• gender性别
• id_card身份证号
• phone联系电话
• birth_date出生日期
• address家庭住址
• allergy_history过敏史（临床安全关键字段）
• create_time、update_time

用户表sys_user

• id、username、password（BCrypt加密后的哈希串）、real_name
• role_id关联角色表
• status状态（0禁用 1启用）

角色权限这块，建议拆成sys_role、sys_menu、sys_role_menu三张表。背后的逻辑是经典的RBAC模型：用户绑角色，角色绑菜单，菜单对应前端路由和按钮标识。前端登录后根据当前用户的权限集合，动态生成可访问的路由，按钮级权限则通过自定义指令或v-if判断。

挂号表registration

• id、patient_id、doctor_id、dept_id
• registration_type（普通号/专家号）
• status（0已挂号 1已就诊 2已退号 3已作废）
• fee挂号费金额
• registration_time

处方表prescription

• id、registration_id、patient_id、doctor_id
• diagnosis诊断结果，医生手写或勾选
• status（0待收费 1已收费 2已取药 3已退费）
• create_time

处方明细表prescription_item

• id、prescription_id、drug_id
• drug_name（冗余字段，保存开药时的药品名，防止药品信息后续修改导致历史记录变化）
• specification规格
• quantity数量
• price单价（冗余字段，保留交易快照）
• total_amount小计

药品表drug

• id、drug_code、drug_name、specification
• manufacturer生产厂家
• unit单位（盒/瓶/袋）
• purchase_price进价
• sale_price售价
• stock_quantity当前库存
• warning_quantity预警阈值
• expiry_date有效期

收费表settlement

• id、registration_id、prescription_id、patient_id
• total_amount、pay_type（现金/微信/支付宝/医保）
• status（0待支付 1已支付 2已退款）
• operator_id收费员
• create_time

这套表结构看着常规，真正要注意的是几个设计巧思。第一，价格和药品名称在处方明细里做了冗余快照。为什么？因为药房的药品调价、药品名称修正都不应该影响已经归档的历史处方，否则财务报表和患者历史病历会出现“按当前售价反算历史费用”的荒谬场景。第二，挂号、处方、收费、退号状态都用了int枚举，而非varchar存中文。好处是数据库查询快、存储空间小、状态流转更严谨，应用层用枚举类或常量做映射就足够。

2.2 业务核心流程的状态流转设计

状态设计是这套系统最容易被忽视、却最决定工程质量的环节。拿一次完整门诊流程举例：患者先建档，拿到medical_record_no后去挂号窗口或线上挂某位医生的号；此时registration表生成一条记录，状态为“已挂号”。医生接诊后录入诊断和处方，prescription生成，状态为“待收费”。患者去收费窗口结算，settlement插入一条支付记录，prescription状态变为“已收费”，同时药品库存锁定待发。药房药师看到已收费处方，核验发药，扣减drug.stock_quantity，prescription状态变为“已取药”。如果患者因故不来，缴费前可退号，缴费后走退费流程，状态同步回滚。

状态机的价值在于让整个操作链路有边界。对账员核对日结时，只需要settlement表里当天“已支付”的记录加总，再和registration表当天“已就诊”的数量交叉比对，就能发现有人挂了号没就诊、或者开了处方没收费的异常数据。开发时我给所有状态字段都定义了常量或枚举，禁止在业务代码里裸写数字1、2、3，因为代码里出现魔法数字，三个月之后你自己都看不懂那个“3”代表什么，更别提后来接手的同事。

2.3 数据库事务与并发控制经验

事务处理中最典型的场景是“收费并发接诊”。患者交费后，系统要同时完成：更新prescription状态、写入settlement表、扣减药品库存，这三个操作必须捆绑在一个事务里。任何一个失败，比如库存扣成负数、数据库连接闪断，都要整体回滚，否则就会出现“收了钱但库存没扣”、“发了药但账上没记录”这类医患纠纷隐患。

代码上，我在服务层加@Transactional(rollbackFor = Exception.class)，注意一定要指定rollbackFor，因为Spring默认只在运行时异常(RuntimeException)时回滚，而检查异常默认不回滚。我们的业务方法里如果抛出一个受检异常而没有指定回滚策略，数据库提交就落库了，这是非常隐蔽的坑。

超高并发扣库存，还要考虑锁粒度。简单场景下用UPDATE drug SET stock_quantity = stock_quantity - #{num} WHERE id = #{id} AND stock_quantity >= #{num}这种条件更新语句，MySQL的行锁天然就保证不会多扣，返回受影响行数为0时再抛出友好提示。不建议先用SELECT查出库存，在Java代码里比较大小后再UPDATE，这种“先检查后更新”在高并发下会出现超卖或者库存为负的问题，因为两个请求可能同时读到同一个旧库存值。

3. 实操过程与核心环节实现

3.1 工程初始化与项目结构搭建

后端工程我建议按模块分包，而不是按技术层分包。什么意思？不要搞controller包、service包、mapper包这种大杂烩，而是按业务域分包：patient、registration、prescription、drug、settlement、system。每个业务包里再放自己的controller、service、mapper、entity、dto。直观感受就是，改挂号功能时，你只需要打开registration这个包，所有相关文件一次找齐，精神负担小很多。

Maven依赖方面，核心依赖要锁定这几个：spring-boot-starter-web、spring-boot-starter-validation（参数校验）、mybatis-spring-boot-starter（版本需与Spring Boot大版本匹配）、mysql-connector-j（注意MySQL 8版本对应driver class是com.mysql.cj.jdbc.Driver，旧版是com.mysql.jdbc.Driver，这个差异在启动时最容易翻车）、jjwt或java-jwt（生成校验Token）、spring-boot-starter-security（做安全框架，或用拦截器简化）。

前端用Vite + Vue 3 + Element Plus的组合来初始化和维护最为顺手。npm create vite@latest frontend创建项目，安装vue-router、pinia、axios、element-plus。Vite的开发服务器端口默认5173，和后端8080端口不同，所以开发阶段需要配置代理转发。

3.2 JWT鉴权与权限控制的落地实现

前后端分离架构下，我采用JWT做无状态认证。用户提供用户名密码，后端验证通过后签发一个有效期2小时的Token，Token里只放userId和roleCode这类不敏感信息，前端拿到后存到localStorage，并在每次请求头里带Authorization: Bearer <token>。后端写一个拦截器，统一校验Token的合法性，顺便把当前用户信息塞到ThreadLocal里，业务代码随时能拿到操作人，写日志、记录操作员ID时非常方便。

登录和权限这几段代码是这个系统的关键，我直接给核心思路。后端拦截器核心逻辑是：

public class JwtInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 放行登录接口和静态资源 String uri = request.getRequestURI(); if (uri.startsWith("/api/auth/login")) { return true; } String token = request.getHeader("Authorization"); if (token != null && token.startsWith("Bearer ")) { token = token.substring(7); Claims claims = JwtUtil.parseToken(token); if (claims != null) { UserContext.setUserId(Long.parseLong(claims.get("userId").toString())); UserContext.setRoleCode(claims.get("roleCode").toString()); return true; } } response.setStatus(HttpStatus.UNAUTHORIZED.value()); response.setContentType("application/json;charset=UTF-8"); response.getWriter().write("{\"code\":401,\"msg\":\"登录已过期，请重新登录\"}"); return false; } }

密码存储方面，严禁明文。我用BCryptPasswordEncoder做加密，它的特点是每次生成的哈希串都带随机盐，同一个密码两次加密结果不同，但matches方法可以校验。这样即使数据库被拖库，攻击者也不能直接靠彩虹表反推出明文口令。每次登录时调用encoder.matches(rawPassword, encodedPassword)判断即可。

前端Vue侧路由守卫也很关键。在router/index.js里注册全局前置守卫，未登录访问任何业务页面都强制跳转登录页，并在路由元信息meta.roles里声明哪些角色可访问该页面：

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

更精细的动态路由做法是登录后根据后端返回的菜单权限，用router.addRoute动态注册有权限的路由，无权限的菜单直接不渲染。这样可以避免前端把所有页面都打包在路由表里，单纯靠隐藏菜单做“假权限”。

3.3 MyBatis配置与复杂SQL的编写心得

MyBatis的核心配置虽然写着简单，但有几处值得反复确认。map-underscore-to-camel-case要设置为true，这样数据库的create_time字段才能自动映射到Java实体属性的createTime。否则你得在结果映射里手写一长串column和property，繁琐且容易漏映射。

动态SQL是这个框架最值钱的功能。门诊报表页面“查询任意时间段、指定科室、药品消耗排名”这类需求，用一个动态SQL轻松搞定：

<select id="selectDrugConsumptionRank" resultType="map"> SELECT d.drug_name, SUM(pi.quantity) AS total_quantity, SUM(pi.total_amount) AS total_amount FROM prescription_item pi JOIN prescription p ON pi.prescription_id = p.id JOIN drug d ON pi.drug_id = d.id <where> <if test="deptId != null"> AND p.dept_id = #{deptId} </if> <if test="startDate != null"> AND p.create_time &gt;= #{startDate} </if> <if test="endDate != null"> AND p.create_time &lt;= #{endDate} </if> </where> GROUP BY d.drug_name ORDER BY total_amount DESC </select>

<where>标签的巧妙之处在于，当所有if条件都不成立时它不会生成多余的WHERE关键字，当第一个条件成立时它会自动去掉多余的AND，帮你避免手写SQL时最容易出现的语法位置错误。

3.4 环境配置与项目启动全流程

实操把系统跑起来，前端后端要分别启动。后端先创建数据库community_hospital，执行项目里的init.sql脚本建表并写入初始管理员账号。然后修改application.yml里的数据库连接：

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

数据库连接串里几个参数含义要清楚。serverTimezone=Asia/Shanghai解决MySQL和JVM时区不一致导致的时间错乱问题；useSSL=false因为本地开发没有配置SSL证书，不关掉会报SSL连接警告甚至直接报错；allowPublicKeyRetrieval=true专门针对MySQL 8的caching_sha2_password认证方式，一些老版本连接驱动或工具（如旧版Navicat）连接时少了这个参数会直接失败。

后端启动命令mvn spring-boot:run，看到“Started Application in xx seconds”即启动成功。前端先执行npm install，这一步在国内网络环境下可能比较慢，用npm config set registry https://registry.npmmirror.com切换到国内镜像源能快很多。然后执行npm run dev，Vite启动后在浏览器访问http://localhost:5173并配合Vite的代理配置：

server: { proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } }

这样前端请求/api/xxx会被代理转发到后端8080端口，开发阶段就不需要后端额外配置CORS，生产部署时则由Nginx统一处理同源代理。

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

4.1 启动阶段的经典故障

项目跑不起来的报错来来回回就是那几类，我挑三个最高频的给排障思路。

第一个是Access denied for user 'root'@'localhost'，数据库账号密码不对或者用户没有远程访问权限。先用命令行工具重新认证，确认密码无误后，检查application.yml里密码是否被误留了空格。还有一个很容易忽略的点，MySQL 8默认创建的用户可能指定了host为localhost，如果你通过公司服务器IP访问，需要在MySQL里执行CREATE USER 'root'@'%' IDENTIFIED BY 'password';并授权。

第二个是Unknown database 'community_hospital'，典型的忘了执行数据库初始化脚本。进入MySQL后用CREATE DATABASE community_hospital DEFAULT CHARACTER SET utf8mb4;先建库，再导入SQL文件。字符集一定要用utf8mb4而不是utf8，因为utf8mb4才能完整支持四字节的Unicode表情字符和生僻汉字，医疗系统里患者姓名偶尔会出现生僻字，这里栽过跟头就记住了。

第三个是端口被占用。Spring Boot默认8080端口，如果你机器上还有别的Java服务或Nginx占用，启动会报Port 8080 was already in use。排查方式：Windows用netstat -ano | findstr 8080，Linux用lsof -i:8080，找到PID后看进程是否可关，或者直接在application.yml里把server.port改成一个不冲突的端口。

4.2 联调阶段的前后端跨域与Token问题

前端控制台报Access-Control-Allow-Origin相关错误，这是跨域。我用Vite代理后一般不会出现，但如果直接从前端地址发请求，就需要后端配置跨域过滤器。我习惯写一个全局CORS配置类，允许本地开发地址通过：

@Configuration public class CorsConfig { @Bean public CorsFilter corsFilter() { CorsConfiguration config = new CorsConfiguration(); config.addAllowedOrigin("http://localhost:5173"); config.addAllowedOrigin("http://localhost:8080"); config.addAllowedHeader("*"); config.addAllowedMethod("*"); config.setAllowCredentials(true); UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource(); source.registerCorsConfiguration("/**", config); return new CorsFilter(source); } }

加载首页白屏、Network里每个接口都报401，先看是不是Token过期。前端axios拦截器里如果检测到401，要清除本地Token并跳转登录页。另外一个容易犯的错误，前端请求头单词写错：Authorization写成authorization，后端拦截器读取时会取不到值，拿到的始终是Null，然后被拦截器打成401。排查时在浏览器Network里看Request Headers到底带了什么。

还有一个登录后刷新页面就失去用户信息的坑。Vue的Pinia或Vuex状态默认存在内存里，一刷新就清零。我的做法是首次登录成功后把用户昵称、角色、权限码都存一份到localStorage，状态初始化时优先从本地存储读取，退出登录再清空。这样刷新页面后侧边栏菜单和用户头像还能正常渲染，不会闪一下空白。

4.3 数据库操作里的隐藏陷阱

时区问题很典型：插入一条挂号记录，结果数据库存的时间比实际时间慢了或快了8个小时。排查第一步确认MySQL服务端时区SHOW VARIABLES LIKE '%time_zone%';，第二步确认连接串里有serverTimezone=Asia/Shanghai。如果你的服务器是UTC时区，但业务发生地是北京时间，连接串不带这个参数，Spring Boot会按默认时区解析，日志时间的观感就是“永远不对”。

字符集乱码现象多发生在导入init.sql后看到中文问号或者錒鏽乱码。检查建库语句里是否指定了DEFAULT CHARACTER SET utf8mb4，如果建库时漏了，单独把表字段改成utf8mb4也来得及：ALTER TABLE patient CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci。这里还要注意数据库连接串里的characterEncoding=utf8，这个utf8在MySQL服务端语境里实际就是utf8mb3，只支持三字节编码，如果你的连接串没有显式characterEncoding，建议直接改成characterEncoding=utf8mb4。

有一个事务的问题非常隐蔽：调用方在Controller里用try-catch捕获了Service层抛出的RuntimeException，而没有在Controller方法上标注@Transactional，你以为事务回滚了，但实际上如果异常信息被吞掉、事务边界又不在Service层，这部分数据可能已经提交成功了。排查思路就是看日志里有没有输出“Rolling back”的字样。Spring事务代理默认只对通过代理对象调用的方法生效，同一个类内部方法之间调用不会触发事务代理，这一点也容易让人莫名其妙地发现“事务没生效”。我一般会在业务方法命名上带明显的事务语义线索，并在团队Code Review时专门盯这类场景。

4.4 常见问题速查表

把实际操作频率最高的故障整理成一个表，部署阶段随时对照：

这套表是我在多个项目里总结出来的高频清单，每次部署新环境我都会照着过一遍，能省掉大量无头苍蝇式的排查时间。

最后一个实用技巧：如果需要把前端打包后放进Spring Boot一起启动，执行npm run build后，把生成的dist目录里的文件复制到后端src/main/resources/static下，同时在后端拦截器里把/static/**等静态资源路径从Token校验的拦截范围中排除。启动后直接访问http://localhost:8080就能看到登录页。这种方式适合小型项目的单机部署，不需要额外配置Nginx。如果以后服务要上云、要挂域名和HTTPS证书，再回归前后端分离部署——静态文件给Nginx管，后端API单独跑在8080，Nginx里把/api前缀的请求反向代理过去就行。社区医院系统的下一步扩展方向，大概率是电子病历对接、LIS检验报告回传和医保接口联调，技术底座钉稳了，这些业务扩展都只是在上层加模块而已。