JavaWeb医院药品管理系统实战：从架构设计到并发库存管理-编程实验室

简介：本资源是一套完整可用的基于JavaWeb的医院药品管理系统，专为计算机专业本科生毕业设计、课程设计及Java初学者项目实战打造，解决药品入库、出库、库存查询、供应商管理等核心业务场景建模与系统实现问题。压缩包共195个文件，含53个Java后端逻辑类、21个HTML前端页面、22个JavaScript交互脚本、6个CSS样式文件、21个GIF图标资源及1个MySQL数据库SQL脚本，辅以项目说明文档与配置文件，覆盖MVC分层结构典型实践。资源包仅869KB，轻量易部署，所有代码经导师指导并高分通过验收，下载解压后导入IDE与数据库即可运行，无需额外修改。目前已有651人学习下载，适合需要快速上手Web开发全流程、理解Servlet+JSP+MySQL协同机制的学习者，尤其利于掌握药品管理类系统的权限控制、数据校验与前后端交互细节。

1. 项目背景与核心价值：为什么需要一个医院药品管理系统？

如果你在医疗信息化领域待过，或者正在学习JavaWeb开发，寻找一个能串联起前后端、数据库和业务逻辑的实战项目，那么“医院药品管理系统”绝对是一个绕不开的经典案例。它不像一个简单的博客或商城系统那样随处可见，其背后蕴含的业务复杂性和对数据准确性的严苛要求，使其成为检验开发者综合能力的绝佳试金石。

我最初接触这类系统，是在参与一个区级医院的数字化升级项目时。当时，药房还在使用纸质台账和Excel表格混合管理，库存不准、效期预警全靠人工记忆、医生开药与药房库存脱节等问题频发。一个看似简单的“药品管理”，在实际场景中却牵扯到采购、入库、库存、处方、发药、退药、盘点、效期、供应商、财务对账等十多个核心环节。这让我深刻意识到，一个设计良好的药品管理系统，其核心价值远不止于“增删改查”（CRUD），而在于通过流程化和数字化的手段，解决信息孤岛，保障用药安全，提升运营效率，并最终为医院的精细化管理提供数据支撑。

对于学习者而言，这个项目之所以宝贵，是因为它几乎覆盖了JavaWeb企业级应用的所有关键技术栈：使用Servlet/JSP或Spring MVC处理Web请求，通过JDBC、MyBatis或JPA操作数据库，利用Session、Cookie或Token管理用户状态，结合Ajax实现页面无刷新交互，再辅以事务控制保证数据一致性。同时，其业务逻辑的复杂性（如库存的并发扣减、药品的批次与效期管理、处方与库存的实时校验）又能让你跳出技术框架的束缚，真正去思考如何用代码建模现实世界的问题。

因此，当你拿到一份“基于JavaWeb的医院药品管理系统源码+数据库.zip”时，你得到的不仅仅是一堆可以运行的代码，更是一个完整的、贴近真实业务场景的微缩模型。接下来的内容，我将带你深入这套系统的肌理，从环境搭建、架构解析、核心模块实现到那些开发文档里不会写的“坑”，为你还原一个医院药品管理系统从零到一的构建全过程。

2. 环境准备与项目初始化：搭建你的第一个医疗级开发沙箱

在打开那个ZIP包之前，一个稳定、隔离的开发环境是首要任务。很多新手会直接在自己的日常电脑上配置环境，导致各种依赖冲突、端口占用问题。我的建议是，为这个项目单独创建一个“沙箱环境”。

2.1 基础环境选型与配置

对于JavaWeb项目，环境三板斧是：JDK、Web服务器（Tomcat）、数据库（MySQL）。版本选择上，我建议采用一个相对稳定且兼容性广的组合，而不是盲目追求最新。

JDK 8 或 JDK 11：这是目前企业中使用最广泛的两个LTS（长期支持）版本。JDK 8的生态最为成熟，而JDK 11在性能和模块化上有所提升。对于学习型项目，JDK 8是更稳妥的选择。安装后，务必确认JAVA_HOME环境变量已正确设置，并在命令行中通过java -version和javac -version验证。
Apache Tomcat 9.x：作为轻量级、应用广泛的Servlet容器，Tomcat 9对Servlet 4.0和Java EE 8提供了良好支持，足以应对绝大多数传统JavaWeb项目。下载解压版（ZIP），将其放在一个没有中文和空格的路径下。你需要熟悉它的目录结构：webapps（存放你的项目）、conf/server.xml（配置端口和连接器）、logs（查看运行日志）。
MySQL 5.7 或 8.0：同样，5.7版本因其极高的稳定性，至今仍在大量生产环境中服役。8.0版本则在性能、安全性和JSON支持上有显著增强。我推荐从5.7开始，减少可能因版本差异导致的语法兼容性问题。安装时，记住你设置的root密码。之后，你需要一个图形化管理工具，Navicat或开源的DBeaver都是极佳的选择，它们能让你更直观地操作数据库。

注意：永远不要在配置文件或代码中硬编码数据库密码。在本地开发时，可以使用配置文件（如jdbc.properties）来管理，并通过.gitignore文件确保这些包含敏感信息的配置文件不会被意外提交到代码仓库。

2.2 IDE的选择与项目导入

集成开发环境（IDE）能极大提升效率。IntelliJ IDEA Ultimate（社区版对JavaWeb支持稍弱）和Eclipse for Enterprise Java Developers是两大主流。IDEA在智能提示、代码重构和与构建工具（如Maven）的集成上体验更佳，已成为很多Java开发者的首选。

拿到“源码+数据库.zip”后，不要急于用IDE打开。先解压，观察目录结构。一个典型的JavaWeb项目可能有两种组织形式：

标准Maven项目：根目录下存在pom.xml文件。这种情况下，直接用IDEA的“Open”或“Import Project”功能，选择该pom.xml文件，IDEA会自动识别并下载所有依赖。
传统Web项目：目录结构可能直接是WebContent（或WebRoot）、src、lib等。对于这种项目，在IDEA中需要选择“New Project” -> “Java Enterprise”，然后手动配置“Web Application”，并将lib下的JAR包添加为项目的库（Libraries）。

导入后第一件事，是检查项目的依赖和构建路径。确保所有必要的JAR包（如数据库驱动mysql-connector-java、Servlet APIservlet-api、JSTL标签库jstl等）都已正确引入，没有出现红色的编译错误。

2.3 数据库的还原与连接测试

解压包中通常会包含一个SQL脚本文件（如hospital_drug.sql）或数据库备份文件。这是系统的“数据蓝图”。

创建数据库：首先在你的MySQL中，创建一个新的数据库，字符集建议使用utf8mb4，排序规则用utf8mb4_general_ci，以支持完整的UTF-8字符（包括Emoji）。
```
CREATE DATABASE `hospital_drug_db` CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
```
执行SQL脚本：使用Navicat或DBeaver连接到MySQL，选中新建的数据库，然后运行工具中的“执行SQL文件”功能，选择项目提供的.sql脚本。这个过程会将所有的表结构（DDL）和初始数据（DML）一次性导入。
验证与连接：脚本执行成功后，刷新数据库，你应该能看到一系列表，例如drug（药品信息）、stock（库存）、prescription（处方）、user（用户）等。浏览几张表，看看是否有初始的管理员账号、药品分类等数据。
修改项目配置：最后，在项目中找到数据库连接配置文件（可能是db.properties、jdbc.properties或直接写在DAO层的代码中），将其中的数据库URL、用户名和密码修改为你本地刚创建的环境信息。

完成以上三步，你的开发沙箱就准备好了。此时，尝试将项目部署到Tomcat并启动，如果能看到登录页面，恭喜你，环境搭建成功。但这仅仅是开始，真正的挑战在于理解这背后的业务逻辑和代码架构。

3. 系统核心架构解析：从用户请求到数据落地的完整链路

一个可用的系统背后，一定有一套清晰的架构在支撑。对于这个医院药品管理系统，我们可以将其抽象为经典的三层架构：表现层（Web Layer）、业务逻辑层（Service Layer）、数据访问层（DAO Layer）。每一层各司其职，通过明确的接口进行通信，这是保证代码可维护性和可扩展性的基石。

3.1 表现层：JSP与Servlet的协作模式

在传统的JavaWeb项目中，表现层通常由JSP（Java Server Pages）和Servlet共同承担。Servlet作为控制器（Controller），负责接收HTTP请求、调用业务逻辑、处理结果并决定跳转到哪个JSP页面；JSP则负责视图（View）的渲染，将数据以HTML的形式呈现给用户。

一个典型的药品查询流程如下：

用户在浏览器输入/drug/list或点击查询按钮（触发一个到/drug/list的GET或POST请求）。
Tomcat根据web.xml中配置的Servlet映射，将这个请求路由到名为DrugListServlet的Servlet。
DrugListServlet的doGet或doPost方法被调用。它首先从请求对象（HttpServletRequest）中获取查询参数，如药品名称、分类。
接着，Servlet会创建一个DrugService的业务逻辑对象，并调用其searchDrugs方法，传入查询条件。
业务逻辑层处理完毕后，将查询到的药品列表（一个List<Drug>对象）返回给Servlet。
Servlet将这个列表放入请求作用域（request.setAttribute("drugList", drugList)）。
最后，Servlet通过请求转发（request.getRequestDispatcher("/WEB-INF/jsp/drug/list.jsp").forward(request, response)）跳转到list.jsp页面。
JSP页面使用JSTL和EL表达式（如<c:forEach items="${drugList}" var="drug">）循环遍历药品列表，生成动态的HTML表格。

实操心得：很多初学者容易混淆转发（forward）和重定向（redirect）。记住一个原则：需要携带请求域中的数据到下一个资源时用转发（地址栏不变）；完成一个动作后（如新增、删除），需要防止表单重复提交并跳转到新页面时用重定向（地址栏变化，发起新的请求）。例如，删除药品成功后，应该重定向到列表页，而不是转发。

3.2 业务逻辑层：复杂规则的封装与事务控制

业务逻辑层（Service）是整个系统的大脑。它不关心数据从哪里来（DAO层负责），也不关心页面怎么展示（表现层负责），只专注于实现复杂的业务规则。在药品管理系统中，业务逻辑的复杂性主要体现在以下几个方面：

库存扣减的原子性：当医生开出处方，药房执行发药时，系统需要扣减对应药品的库存。这个过程必须是原子的，即“查询库存 -> 判断是否充足 -> 扣减”这三个步骤必须在一个数据库事务中完成，否则在高并发下会出现超卖（库存为负）。Service层的方法上通常会添加@Transactional注解（如果使用Spring）或手动进行事务管理，来保证这一点。
药品批次与效期管理（FIFO）：药品管理必须遵循“先进先出”原则。这意味着库存扣减时，不能简单地按总数扣，而要找到最早过期的批次优先扣除。Service层需要设计相应的算法，在stock表中可能每个批次（batch_number）都有独立的库存记录，发药时按效期排序进行扣减。
处方合规性校验：医生开具处方时，Service层需要校验：药品是否存在、库存是否充足、药品是否在有效期内、是否存在配伍禁忌（这需要维护一个药品相互作用知识库）、剂量是否在安全范围内等。这些校验逻辑集中写在Service中，确保了业务规则的统一和可维护性。

3.3 数据访问层：JDBC、MyBatis与实体映射

数据访问层（DAO, Data Access Object）的职责是封装所有对数据库的操作。早期项目可能直接使用原始的JDBC，代码中充斥着大量的Connection、PreparedStatement、ResultSet处理和try-catch-finally块，繁琐且容易出错。

更现代的做法是使用ORM框架，如MyBatis或JPA/Hibernate。以MyBatis为例，它的价值在于：

SQL与代码分离：将复杂的SQL语句写在XML映射文件（DrugMapper.xml）中，Java代码（DrugMapper.java接口）只声明方法，结构清晰。
自动参数映射与结果集映射：MyBatis可以自动将Java对象（如Drug）的属性映射到SQL语句的参数（#{}），并将查询结果集自动封装成Drug对象或List<Drug>，省去了手动拼装和解析的代码。
动态SQL：对于多条件的复杂查询，MyBatis提供了<if>,<choose>,<foreach>等标签，可以灵活地拼接SQL，避免了在Java代码中拼接字符串的丑陋和SQL注入风险。

例如，一个根据多条件查询药品的MyBatis映射文件片段可能如下：

<select id="selectDrugByCondition" parameterType="map" resultType="Drug"> SELECT * FROM drug <where> <if test="name != null and name != ''"> AND name LIKE CONCAT('%', #{name}, '%') </if> <if test="categoryId != null"> AND category_id = #{categoryId} </if> <if test="status != null"> AND status = #{status} </if> </where> ORDER BY id DESC </select>

对应的Java接口只需要声明：List<Drug> selectDrugByCondition(Map<String, Object> params);

通过这三层的协同工作，一个用户请求才能被正确处理，数据才能安全、准确地流转。理解了这个架构，你就掌握了阅读和修改这份源码的“地图”。

4. 核心业务模块深度实现：以药品库存管理为例

理解了宏观架构，我们深入到最核心、也最复杂的业务模块之一：药品库存管理。它绝不仅仅是数据库里一个stock表的数字增减，而是一套涉及并发控制、事务完整性、业务规则校验的精密系统。

4.1 数据库表结构设计：如何为业务建模

一个健壮的库存表设计，需要能支持批次管理和效期追踪。我们来看一个简化的设计：

CREATE TABLE `drug` ( `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '药品ID', `code` varchar(50) NOT NULL COMMENT '药品编码（唯一）', `name` varchar(100) NOT NULL COMMENT '药品通用名', `spec` varchar(100) DEFAULT NULL COMMENT '规格（如：0.5g*24片）', `unit` varchar(20) DEFAULT NULL COMMENT '单位（如：盒，瓶）', `manufacturer` varchar(200) DEFAULT NULL COMMENT '生产厂家', `category_id` int(11) DEFAULT NULL COMMENT '分类ID', PRIMARY KEY (`id`), UNIQUE KEY `uk_code` (`code`) ) ENGINE=InnoDB COMMENT='药品基础信息表'; CREATE TABLE `drug_stock` ( `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '库存记录ID', `drug_id` int(11) NOT NULL COMMENT '药品ID', `batch_number` varchar(100) NOT NULL COMMENT '批号', `production_date` date NOT NULL COMMENT '生产日期', `expiry_date` date NOT NULL COMMENT '有效期至', `quantity` int(11) NOT NULL DEFAULT '0' COMMENT '当前库存数量', `warehouse_location` varchar(50) DEFAULT NULL COMMENT '库位', `supplier_id` int(11) DEFAULT NULL COMMENT '供应商ID', `purchase_price` decimal(10,2) DEFAULT NULL COMMENT '采购单价', `retail_price` decimal(10,2) DEFAULT NULL COMMENT '零售单价', `status` tinyint(4) DEFAULT '1' COMMENT '状态（1-正常，0-锁定/停用）', PRIMARY KEY (`id`), KEY `idx_drug_id` (`drug_id`), KEY `idx_expiry` (`expiry_date`), CONSTRAINT `fk_stock_drug` FOREIGN KEY (`drug_id`) REFERENCES `drug` (`id`) ) ENGINE=InnoDB COMMENT='药品库存批次表';

设计解析：

分离设计：将静态的药品信息（drug）和动态的、多批次的库存信息（drug_stock）分开。这样，一种药品可以对应多条库存记录（不同批号）。
关键字段：batch_number（批号）和expiry_date（有效期至）是实现FIFO和效期预警的基础。quantity是当前批次的可售数量。
索引优化：在drug_id和expiry_date上建立索引，能大幅提升根据药品查询和按效期排序查询的性能。
外键约束：drug_stock.drug_id关联drug.id，保证了数据的参照完整性，防止出现“幽灵库存”。

4.2 库存扣减的并发控制与事务

这是库存管理的核心难点。假设场景：药房同时为两个病人发放同一种药品（同一批次），库存只剩1盒。如果没有并发控制，两个发药事务可能同时读到库存为1，都判断为充足，然后都执行扣减，最终导致库存变为-1。

解决方案一：悲观锁（Pessimistic Locking）在查询库存时，直接使用数据库的排他锁（如SELECT ... FOR UPDATE），锁定这条库存记录，直到当前事务提交。其他事务在此期间无法读取或修改这条记录。

// 在Service方法中，使用@Transactional注解 @Transactional public boolean dispenseDrug(int stockId, int quantity) { // 1. 悲观锁查询 DrugStock stock = drugStockDao.selectForUpdate(stockId); // 对应的SQL: SELECT * FROM drug_stock WHERE id = #{id} FOR UPDATE if (stock == null || stock.getQuantity() < quantity) { throw new RuntimeException("库存不足或不存在！"); } // 2. 扣减库存 stock.setQuantity(stock.getQuantity() - quantity); drugStockDao.update(stock); // 3. 记录发药流水... return true; }

优点：简单粗暴，能绝对保证一致性。缺点：并发性能差，容易造成大量事务等待，引发死锁风险。

解决方案二：乐观锁（Optimistic Locking）不直接加锁，而是为库存记录增加一个版本号字段（version）。更新时，检查当前版本号是否与读取时一致。

ALTER TABLE `drug_stock` ADD COLUMN `version` int(11) NOT NULL DEFAULT '0' COMMENT '版本号';

@Transactional public boolean dispenseDrugOptimistic(int stockId, int quantity) { DrugStock stock = drugStockDao.selectById(stockId); if (stock == null || stock.getQuantity() < quantity) { throw new RuntimeException("库存不足或不存在！"); } // 使用版本号进行更新 int affectedRows = drugStockDao.updateQuantityWithVersion(stockId, quantity, stock.getVersion()); // 对应的SQL: UPDATE drug_stock SET quantity = quantity - #{quantity}, version = version + 1 WHERE id = #{id} AND version = #{version} if (affectedRows == 0) { // 更新失败，说明版本号已变（数据被其他事务修改），通常需要重试或抛出异常让上层处理 throw new RuntimeException("并发更新冲突，请重试！"); } // 记录发药流水... return true; }

优点：并发性能好，无锁竞争。缺点：需要处理更新失败的情况（重试机制），业务逻辑稍复杂。

在实际的医院系统中，由于发药操作频率高，且对响应时间有一定要求，乐观锁配合重试机制是更常见的选择。对于库存初始化、盘点等低频操作，可以使用悲观锁。

4.3 效期预警与库存盘点流程

除了日常的出入库，库存管理还有两个重要的周期性任务。

效期预警：系统需要定期（如每天）扫描drug_stock表，找出距离过期日期（expiry_date）在一定天数内（如30天、7天）的药品。这可以通过一个定时任务（如使用Spring的@Scheduled注解或Quartz框架）来实现。预警信息可以生成报表，或在药房管理员的首页进行醒目提示。

库存盘点：这是保证账实相符的关键。流程通常是：

创建盘点任务：锁定当前库存快照（防止盘点期间库存变动影响结果），生成盘点单。
实地盘点：药房人员根据盘点单，逐一清点实物数量。
数据录入：将实盘数量录入系统。
生成盘盈盘亏单：系统自动计算账面数量与实盘数量的差异。
审核与过账：管理人员审核差异原因，确认后系统自动生成库存调整记录，更新账面库存。

这个流程在代码中体现为多个Service方法的组合调用，并且整个盘点过程可能涉及状态机（如盘点单状态：初始化->盘点中->已完成->已审核）的设计。

5. 处方与发药流程：串联医疗业务的核心链路

药品管理的最终目的是服务于临床诊疗。处方与发药流程，是连接医生、患者、药房和药品库存的核心业务链路。理解这个流程，就能理解系统中大部分模块是如何联动的。

5.1 电子处方的生成与流转

开立处方：医生在医生工作站，选择患者，通过系统搜索药品（调用DrugService），填写用法、用量、频次、疗程等。系统在后台实时校验库存（调用InventoryService）和药品状态。

处方保存：校验通过后，生成处方主记录（prescription表）和处方明细（prescription_item表）。此时处方状态为“待缴费”。

-- 处方主表 CREATE TABLE `prescription` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `prescription_no` varchar(50) NOT NULL COMMENT '处方号', `patient_id` int(11) NOT NULL COMMENT '患者ID', `doctor_id` int(11) NOT NULL COMMENT '医生ID', `create_time` datetime NOT NULL COMMENT '开方时间', `status` tinyint(4) NOT NULL DEFAULT '0' COMMENT '状态(0-待缴费，1-已缴费/待发药，2-已发药，3-已退药，4-已作废)', `total_amount` decimal(10,2) DEFAULT NULL COMMENT '处方总金额', PRIMARY KEY (`id`) ); -- 处方明细表 CREATE TABLE `prescription_item` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `prescription_id` bigint(20) NOT NULL COMMENT '处方ID', `drug_id` int(11) NOT NULL COMMENT '药品ID', `drug_name` varchar(100) NOT NULL COMMENT '药品名称（冗余，避免关联查询）', `quantity` int(11) NOT NULL COMMENT '数量', `dosage` varchar(100) DEFAULT NULL COMMENT '单次剂量', `frequency` varchar(50) DEFAULT NULL COMMENT '频次（如：一日三次）', `days` int(11) DEFAULT NULL COMMENT '用药天数', `unit_price` decimal(10,2) NOT NULL COMMENT '单价', `subtotal` decimal(10,2) NOT NULL COMMENT '小计', `stock_id` int(11) DEFAULT NULL COMMENT '计划发出的库存批次ID', PRIMARY KEY (`id`) );

注意：在prescription_item中冗余存储了drug_name和unit_price。这是因为处方具有法律效力，一旦开立，其内容不应随基础信息（如药品改名、调价）而改变。这是一种常见的“快照”设计模式。

处方缴费：患者缴费后，收费系统通过接口或更新状态，将处方状态改为“已缴费/待发药”。此时，系统可以预先为处方明细分配具体的库存批次（stock_id），为发药做准备。

5.2 药房发药与库存的实时联动

这是系统压力最大、逻辑最严谨的环节。

获取待发药处方：药房药师登录系统，查看状态为“待发药”的处方列表。

配药与核对：药师根据处方明细进行配药。在系统中，点击“发药”按钮时，后端会执行一个事务性操作：

@Transactional(rollbackFor = Exception.class) // 发生任何异常都回滚 public boolean dispensePrescription(Long prescriptionId) { // 1. 查询处方及明细（加锁或使用乐观锁版本号） Prescription prescription = prescriptionDao.selectForUpdate(prescriptionId); if (!"待发药".equals(prescription.getStatus())) { throw new BusinessException("处方状态不正确，无法发药"); } List<PrescriptionItem> items = prescriptionItemDao.selectByPrescriptionId(prescriptionId); // 2. 循环处理每个药品项 for (PrescriptionItem item : items) { Integer stockId = item.getStockId(); // 之前已分配好的批次 // 调用库存扣减服务，内部使用乐观锁控制并发 inventoryService.deductStock(stockId, item.getQuantity()); // 记录发药流水 dispenseRecordDao.insert(new DispenseRecord(item, prescription)); } // 3. 更新处方状态为“已发药” prescription.setStatus("已发药"); prescription.setDispenseTime(new Date()); prescriptionDao.update(prescription); return true; }

异常处理：如果在扣减某个药品库存时失败（如库存不足、版本冲突），整个事务回滚，处方状态不变，前端提示药师具体原因。药师可以检查实物库存或与医生沟通后，重新操作或作废处方。

5.3 退药与库存冲回流程

退药是发药的逆向操作，同样需要严格的事务控制。

退药申请：由医生或药房发起，需填写退药原因。
审核与冲回库存：审核通过后，系统执行退药操作。关键步骤是冲回库存，即增加对应批次的库存数量。这里必须冲回到原批次，以保持批次追踪的完整性。同时，需要生成负向的发药流水记录，以便财务对账。
更新处方状态：将处方状态改为“已退药”。部分系统还会关联原始的发药记录，形成完整的追溯链。

整个处方发药流程，体现了事务（Transaction）在业务系统中的核心价值：要么全部成功，要么全部回滚，确保处方状态、库存数量、财务流水三者始终保持一致，这是医疗系统数据准确性的生命线。

6. 系统安全、权限与数据完整性设计

对于一个管理敏感医疗数据的系统，安全性不是可选项，而是底线。这包括功能权限控制、数据安全以及保证数据本身逻辑的正确性。

6.1 基于角色的访问控制

医院内不同角色对系统的操作权限截然不同：

系统管理员：管理所有基础数据、用户和角色。
药库管理员：负责药品的采购、入库、供应商管理。
药房药师：负责处方审核、发药、退药、日常盘点。
医生：只能开立和查询本人相关的处方。
财务人员：只能查看与收费、报表相关的模块。

实现上，通常采用经典的RBAC（Role-Based Access Control）模型。数据库中会有user（用户）、role（角色）、permission（权限，通常对应菜单或操作按钮）、以及关联表user_role、role_permission。

在每次用户请求一个功能或访问一个页面时，过滤器（Filter）或拦截器（Interceptor）会检查当前用户是否拥有该请求路径对应的权限。一个简单的权限拦截器逻辑如下：

public class AuthInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { HttpSession session = request.getSession(); User user = (User) session.getAttribute("loginUser"); if (user == null) { response.sendRedirect(request.getContextPath() + "/login"); return false; } // 获取当前请求的URI String requestURI = request.getRequestURI(); // 根据user的角色，查询其拥有的所有权限URL列表（可缓存于Session或Redis） Set<String> permittedUrls = getUserPermittedUrls(user.getId()); if (!permittedUrls.contains(requestURI)) { // 无权限访问 response.sendError(HttpServletResponse.SC_FORBIDDEN, "无权访问"); return false; } return true; } }

6.2 关键数据的审计与日志记录

“谁在什么时候做了什么”，对于医疗系统至关重要。所有关键业务操作，尤其是涉及数据增删改的，都必须记录审计日志。

记录内容：操作时间、操作人、操作IP、操作模块、执行的动作（如“新增药品”、“发药”）、操作前后的数据快照（特别是修改和删除操作）。
实现方式：可以使用AOP（面向切面编程）或自定义注解，在Service方法上标记需要审计，然后统一记录。审计日志应存入独立的数据库表，与业务数据分离，并且通常不允许普通用户删除。

@Aspect @Component public class AuditLogAspect { @Autowired private AuditLogService auditLogService; @Around("@annotation(com.xxx.annotation.RequiresAudit)") public Object aroundAdvice(ProceedingJoinPoint joinPoint) throws Throwable { // 方法执行前：获取操作人、方法名、参数等信息 String operator = getCurrentUser(); String operation = joinPoint.getSignature().getName(); Object[] args = joinPoint.getArgs(); String beforeSnapshot = serializeData(args); // 序列化参数作为操作前快照 Object result = joinPoint.proceed(); // 执行原方法 // 方法执行后：获取结果，记录日志 String afterSnapshot = serializeData(result); AuditLog log = new AuditLog(operator, operation, beforeSnapshot, afterSnapshot, new Date()); auditLogService.save(log); return result; } }

6.3 数据库层面的完整性约束

Java代码的逻辑校验很重要，但数据库自身提供的约束是最后一道，也是最坚固的防线。

主键与外键：确保数据的唯一性和关联完整性。如prescription_item.prescription_id必须引用prescription.id中存在的值。
唯一约束：如drug.code（药品编码）必须唯一。
非空约束：关键字段如drug.name、drug_stock.expiry_date不能为NULL。
检查约束：虽然MySQL对标准CHECK约束支持较弱（在8.0.16以后才有效执行），但可以在代码层或使用触发器实现。例如，保证drug_stock.quantity不能为负数。
默认值：为状态字段设置合理的默认值，如status默认为1（有效）。

这些约束能在应用程序出现BUG时，防止产生脏数据，是保证数据质量的基石。在设计阶段，就必须和DBA一起仔细规划。

7. 项目部署、优化与常见问题排查

让系统在本地跑起来只是第一步，如何将它部署到一个稳定、高效的环境中，并处理运行中遇到的问题，是另一个维度的能力。

7.1 从开发环境到生产环境

环境配置分离：绝对不要将开发环境的配置（如本地数据库连接）打包到生产环境。使用profile机制（Spring Boot）或外部配置文件（如config.properties），在部署时根据环境变量加载不同的配置。
数据库脚本管理：生产环境的数据库升级必须通过SQL脚本进行。使用版本化工具（如Flyway或Liquibase）来管理数据库迁移脚本，确保每次部署时数据库结构变更的可追溯和可回滚。
应用服务器部署：将项目打包成WAR文件，部署到Tomcat的webapps目录下。对于Tomcat，一些生产环境优化包括：
- 修改conf/server.xml中的连接器配置，调整maxThreads（最大线程数）、acceptCount（等待队列长度）以适应并发量。
- 配置JVM参数，如堆内存大小（-Xms,-Xmx）、垃圾回收器等，在bin/catalina.sh（Linux）或bin/catalina.bat（Windows）中设置。
- 将日志目录（logs）指向一个具有足够空间的分区，并配置日志滚动策略，避免日志文件撑满磁盘。
前端资源优化：对CSS、JavaScript文件进行合并和压缩，对图片进行优化，以加快页面加载速度。

7.2 性能优化要点

当系统数据量增大或用户增多时，性能问题会凸显。

数据库优化：
- 索引：这是最有效的优化手段。分析慢查询日志（MySQL的slow_query_log），为WHERE、ORDER BY、GROUP BY、JOIN子句中的常用字段建立索引。但索引不是越多越好，它会降低写操作速度。
- 查询优化：避免SELECT *，只取需要的字段；合理使用JOIN，对于大表关联，考虑在应用层分步查询；警惕LIKE '%keyword%'这种前导通配符查询，它无法使用索引。
- 连接池：使用Druid、HikariCP等高性能数据库连接池，并合理配置最大连接数、最小空闲连接等参数。
应用层优化：
- 缓存：将不常变化但频繁访问的数据放入缓存，如药品分类、医院科室等。可以使用Guava Cache做本地缓存，或Redis做分布式缓存。例如，在查询药品列表时，可以先查缓存，没有再去数据库，并将结果放入缓存。
- 异步处理：对于一些非实时性的操作，如发送效期预警邮件、生成复杂的统计报表，可以放入消息队列（如RabbitMQ、RocketMQ）或使用线程池异步执行，避免阻塞主请求线程。
- 静态化：一些不常变化的报表页面，可以定时生成静态HTML文件，直接由Nginx等Web服务器返回，极大减轻应用服务器压力。

7.3 典型问题排查思路

在运行和维护过程中，你肯定会遇到各种问题。以下是几个典型场景的排查思路：

页面访问报404错误：
- 检查Tomcat日志catalina.out或localhost.log，看应用是否成功启动，是否有异常抛出。
- 检查请求的URL路径是否正确，是否与web.xml中配置的Servlet映射或Spring的@RequestMapping匹配。
- 检查项目是否成功部署到了Tomcat的webapps目录下，并生成了对应的目录。
页面显示乱码：
- 数据库乱码：确认MySQL数据库、表、字段的字符集是否为utf8mb4，连接字符串是否指定了characterEncoding=UTF-8。
- 请求/响应乱码：在Servlet或Filter中统一设置request.setCharacterEncoding("UTF-8")和response.setCharacterEncoding("UTF-8")。
- JSP页面乱码：在JSP页面头部添加<%@ page contentType="text/html;charset=UTF-8" language="java" %>。
数据库连接池耗尽：
- 现象：系统运行一段时间后，任何数据库操作都超时或失败。
- 排查：查看连接池监控（如Druid提供的监控页面），检查活跃连接数是否达到最大值。可能的原因有：数据库操作没有正确关闭Connection、Statement、ResultSet；存在慢SQL导致连接被长时间占用；连接池配置的最大连接数过小。
- 解决：检查代码，确保数据库资源在finally块中关闭；优化慢SQL；根据实际压力调整连接池参数。
并发操作导致数据不一致：
- 如前面库存扣减的例子，如果出现库存为负，首先检查扣减逻辑是否使用了锁（悲观锁或乐观锁）。
- 查看业务方法是否被正确地标记为@Transactional，确保在一个事务内执行。
- 检查数据库的隔离级别，默认的REPEATABLE READ（可重复读）在大多数场景下是足够的，但在极端并发下可能需要考虑使用SERIALIZABLE（序列化），但性能损耗最大。