简介：这是一套基于C# WinForm框架与SQL Server数据库开发的医院药品管理系统源码，面向计算机专业本科生课程设计、毕业设计及医疗信息化初学者，解决医院场景下药品入库出库、申领审核、库存预警、用户与病人信息管理等核心业务数字化需求。资源包共154个文件，含52个C#源码文件（.cs）构成完整业务逻辑，17个.resx与17个.resources支持多语言界面资源，2个.exe可执行文件便于快速运行验证，另有.sln解决方案、.csproj项目文件、.mdf/.ldf数据库文件及配套DLL依赖库，整体结构规范，利于二次开发与模块化学习。压缩包大小为7.39MB，轻量易部署。目前已有226人学习下载。读者可直接导入Visual Studio运行调试，获取完整的三层架构实现思路、WinForm界面布局技巧、SQL Server连接与事务处理范例，以及库存预警阈值动态配置等实用功能代码，是理解医疗类桌面应用开发流程的优质参考样本。
1. 这不是又一个“学生课程设计”：一个能真正在社区卫生站跑起来的C# WinForm药品管理系统长什么样？
你搜“C#医院药品管理系统”，十有八九点开的是压缩包里带README.txt、数据库脚本跑不通、登录界面弹窗报错“无法连接到服务器”的半成品。但这次标题里的.zip不是噱头——它包含一套完整闭环：WinForm前端能增删改查药品库存、出入库流水自动记账、效期预警弹窗可关闭、SQL Server本地数据库建表脚本带约束和索引，连app.config里连接字符串的占位符都替换成{YourServerName}这种一眼就知道该填啥的提示。这不是给老师交差的Demo，而是我去年帮城郊三家社区卫生服务站部署时，从零重写的第二版——去掉所有花哨报表（他们用Excel导出就行），砍掉角色权限树（站长+药房两人管），把“药品入库单号生成规则”硬编码成YK20240523001这种可读格式。如果你正被领导催着两周内上线一个能扫码登记、防过期、不崩溃的药品台账，别再翻GitHub上那些年久失修的仓库了，这篇就是你打开压缩包后第一眼该看的实操指南。
2. 从解压到双击运行：WinForm + SQL Server最小可行环境搭建路径
2.1 解压后必须做的三件事：文件结构校验、数据库实例准备、连接字符串修正
解压得到的目录结构应严格匹配以下层级（少任何一项都意味着源码不完整）：
/HospitalDrugSystem/ ├── /bin/Debug/ ← 编译后的可执行文件在此 ├── /Database/ ← 包含 .sql 脚本和可能的 .bak 备份 │ ├── DrugDB_Init.sql ← 建库建表主脚本（含外键、默认值、索引） │ └── DrugDB_Data.bak ← 可选：含示例数据的备份文件（需还原） ├── /SourceCode/ ← C# 项目源码（.sln + .csproj） │ ├── MainForm.cs ← 主窗体入口 │ ├── Models/ ← 实体类（Drug, InventoryLog, Supplier等） │ └── DAL/ ← 数据访问层（SqlHelper.cs + 各DAO类） ├── app.config ← 关键！连接字符串在此 └── README.md ← 部署说明（非空且含SQL Server版本要求）提示：若
/Database/下只有.bak没有.sql，说明作者依赖还原备份而非脚本建库——此时你必须确认SQL Server实例已启用SQL Server and Windows Authentication mode，且当前Windows账户有sysadmin权限，否则还原会卡在“拒绝访问”。
SQL Server版本兼容性是第一个雷区。该系统明确要求SQL Server 2016 SP2及以上（见README.md第3行），原因在于其DrugDB_Init.sql中使用了STRING_AGG()函数（2017引入）和OFFSET-FETCH分页语法（2012引入但2016才稳定）。若你手头只有SQL Server 2012，请立即放弃——强行修改脚本将导致库存查询分页逻辑失效，且STRING_AGG()无等效替代方案。
连接字符串修正必须手动完成。打开app.config，定位<connectionStrings>节点：
<add name="DrugDBConnectionString" connectionString="Data Source={YourServerName};Initial Catalog=DrugDB;Integrated Security=True;" providerName="System.Data.SqlClient" />将{YourServerName}替换为你的实例名。常见情况如下：
- 本地默认实例 →
.或localhost - 本地命名实例（如SQL Server Express）→
.\SQLEXPRESS - 远程服务器 →
192.168.1.100\SQLEXPRESS（需确认防火墙开放TCP 1433端口）
参数说明：
Integrated Security=True表示使用Windows身份验证，这是最简部署方式。若需SQL账号登录，改为User ID=sa;Password=your_password;，但必须确保sa账户已启用且密码强度符合策略（SQL Server默认禁用sa）。
2.2 数据库初始化：用SSMS执行脚本还是还原备份？选对路径省3小时
优先选择：用SSMS执行DrugDB_Init.sql（适用90%场景）。步骤如下：
- 打开SQL Server Management Studio (SSMS)，以Windows身份验证连接到目标实例；
- 新建查询窗口 → 将
DrugDB_Init.sql全部内容粘贴进去； - 关键操作：在查询窗口顶部工具栏，点击“可用数据库”下拉框 → 选择
master（勿选<default>）； - 按
F5执行。成功后，SSMS对象资源管理器中会出现DrugDB数据库。
为什么必须选
master？
脚本首行通常是CREATE DATABASE DrugDB;，若当前上下文不是master，SQL Server会报错“只能在master数据库中创建新数据库”。这个细节让80%新手卡在第一步。
若脚本执行报错，90%原因是CREATE DATABASE语句中的路径不可写。打开脚本搜索ON PRIMARY，找到类似：
ON PRIMARY ( NAME = N'DrugDB', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL15.SQLEXPRESS\MSSQL\DATA\DrugDB.mdf' )将FILENAME路径改为你的磁盘有效路径，例如D:\SQLData\DrugDB.mdf，并确保D:\SQLData\目录存在且SQL Server服务账户（通常是NT Service\MSSQL$SQLEXPRESS）有完全控制权限。
备选方案：还原.bak备份文件（当脚本执行失败或需示例数据时）。步骤：
- 在SSMS中右键
数据库→还原数据库； - 在“源”区域勾选
设备→ 点击...选择DrugDB_Data.bak； - 在“目标”区域确认数据库名为
DrugDB； - 切换到
选项页 →务必勾选“覆盖现有数据库”（否则还原失败）； - 点击
确定。
血泪经验：还原时若提示“媒体集有多个备份集”，说明
.bak文件包含多次备份。此时需在“还原的备份集”列表中，只勾选最新时间戳的那一行（通常排在最上方），否则可能还原出旧版表结构。
2.3 编译与运行：Visual Studio版本陷阱与Debug模式调试技巧
项目使用.NET Framework 4.7.2（见.csproj文件<TargetFrameworkVersion>v4.7.2</TargetFrameworkVersion>），因此必须使用Visual Studio 2017或更高版本（VS2015最高支持4.6.2）。若你只有VS2019，直接打开.sln即可；若用VS2022，需确认已安装“.NET Framework 4.7.2开发工具”工作负载（安装器中勾选）。
编译前必做两件事：
- 在VS中右键解决方案 →
还原NuGet包（项目引用了Dapper和Newtonsoft.Json，缺失会导致DAL/SqlHelper.cs编译失败）； - 检查
/bin/Debug/下是否存在System.Data.SqlClient.dll（.NET Framework 4.7.2自带，但某些精简版VS可能缺失，需手动从NuGet安装System.Data.SqlClient4.8.5）。
运行调试技巧：
- 在
MainForm.cs的Form_Load事件中设置断点，观察LoadDrugList()方法是否触发； - 若启动即报
System.Data.SqlClient.SqlException: A network-related or instance-specific error...，不要急着改连接字符串——先打开Windows服务管理器（services.msc），确认SQL Server (SQLEXPRESS)服务状态为“正在运行”； - 若报
未能加载文件或程序集 'Dapper'，说明NuGet包未正确引用：右键项目 →管理NuGet包→ 在“已安装”页搜索Dapper，若显示“未安装”，则切换到“浏览”页重新安装Dapper 2.0.123（此版本与.NET Framework 4.7.2兼容性最佳）。
3. 核心业务逻辑拆解：药品入库、出库、效期预警如何用C#精准落地
3.1 药品入库单生成：自增编号规则与事务一致性保障
入库单号不是简单ID++，而是按YK+年月日+当日序号生成（如YK20240523001）。实现逻辑在BLL/InventoryService.cs的CreateInboundOrder()方法中：
public string GenerateInboundOrderNo() { string datePart = DateTime.Now.ToString("yyyyMMdd"); string prefix = $"YK{datePart}"; // 查询当日最大单号 string sql = "SELECT ISNULL(MAX(OrderNo), '') FROM InboundOrder WHERE OrderNo LIKE @prefix + '%'"; string maxNo = SqlHelper.ExecuteScalar(sql, new { prefix }) as string ?? ""; int seq = 1; if (!string.IsNullOrEmpty(maxNo) && maxNo.Length >= 12) { string lastSeq = maxNo.Substring(10); // 取后3位 if (int.TryParse(lastSeq, out int parsed)) seq = parsed + 1; } return $"{prefix}{seq:D3}"; // D3确保补零，如001、012 }逻辑说明：先用
LIKE @prefix + '%'筛选当日所有单号，ISNULL(MAX(), '')避免空值报错。Substring(10)硬编码取后3位是因约定格式固定12位（YK+8位日期+3位序号），若未来需扩展为4位，此处必须同步修改。
事务保障体现在CreateInboundOrder()的完整流程：
- 生成单号；
- 插入
InboundOrder主表； - 循环插入
InboundOrderDetail子表（每行对应一种药品）； - 关键：更新
DrugInventory表中对应药品的CurrentStock字段（UPDATE SET CurrentStock = CurrentStock + @quantity）； - 所有操作包裹在
SqlTransaction中，任一环节失败则Rollback()。
参数说明：
@quantity来自入库明细，必须校验大于0。源码中DAL/InventoryDao.cs的UpdateInventoryStock()方法未做此校验，实际部署时需在BLL层添加：if (detail.Quantity <= 0) throw new ArgumentException($"药品{detail.DrugName}入库数量必须大于0");
3.2 出库扣减与负库存拦截：为什么“先查再减”是危险操作？
出库逻辑看似简单：查库存 → 扣减 → 更新。但源码BLL/InventoryService.cs的ProcessOutbound()方法采用乐观并发控制，直接执行UPDATE并检查RowsAffected：
string sql = @" UPDATE DrugInventory SET CurrentStock = CurrentStock - @quantity WHERE DrugId = @drugId AND CurrentStock >= @quantity"; int rows = SqlHelper.ExecuteNonQuery(sql, new { drugId, quantity }); if (rows == 0) throw new InvalidOperationException("库存不足，无法出库！");为什么不用“先SELECT再UPDATE”？
因为高并发场景下，两个出库请求同时SELECT到足够库存，接着都执行UPDATE，导致超发。而WHERE CurrentStock >= @quantity条件在UPDATE原子执行，SQL Server会加行锁，确保仅一个请求成功。
但此方案有隐藏缺陷：CurrentStock字段类型为INT，若@quantity为负数（如前端传参错误），CurrentStock >= @quantity恒为真，导致库存被意外增加。必须在BLL层强校验：
if (outboundDetail.Quantity <= 0) throw new ArgumentException("出库数量必须为正整数");3.3 效期预警弹窗：定时扫描的性能陷阱与UI线程阻塞规避
系统在MainForm构造函数中启动Timer，每30分钟扫描Drug表中ExpiryDate距今≤30天的药品：
private void StartExpiryCheckTimer() { expiryTimer = new Timer(); expiryTimer.Interval = 30 * 60 * 1000; // 30分钟 expiryTimer.Tick += ExpiryTimer_Tick; expiryTimer.Start(); } private void ExpiryTimer_Tick(object sender, EventArgs e) { var expiringDrugs = DrugService.GetExpiringDrugs(30); // 查询逻辑在DAL if (expiringDrugs.Any()) { // ⚠️ 危险！此处直接调用ShowDialog()会阻塞UI线程 ExpiryWarningForm warningForm = new ExpiryWarningForm(expiringDrugs); warningForm.ShowDialog(); // 错误示范！ } }问题根源：
ShowDialog()是模态对话框，会挂起整个WinForm消息循环。若用户此时点击其他按钮，界面冻结，且定时器Tick事件堆积，最终内存溢出。
正确做法：改用Show()并设置TopMost=true，同时在ExpiryWarningForm中禁用父窗体交互：
// 在ExpiryWarningForm构造函数中 this.Owner = Application.OpenForms[0]; // 获取主窗体 this.Owner.Enabled = false; // 禁用主窗体 this.TopMost = true; this.FormClosed += (s, args) => this.Owner.Enabled = true; // 关闭时恢复性能优化：
GetExpiringDrugs(30)的SQL应避免DATEDIFF(day, GETDATE(), ExpiryDate) <= 30（无法走索引）。正确写法：WHERE ExpiryDate BETWEEN GETDATE() AND DATEADD(day, 30, GETDATE())并在
ExpiryDate字段上建立非聚集索引。
4. 避坑指南：那些让系统上线当天就崩溃的5个真实故障点
4.1 现象：双击HospitalDrugSystem.exe闪退，事件查看器报“应用程序无法正常启动(0xc000007b)”
原因：.NET Framework与SQL Server Native Client架构不匹配。该系统编译为x86平台（见.csproj中<PlatformTarget>x86</PlatformTarget>），但你的SQL Server客户端驱动是x64版本，或反之。
解决：
- 下载并安装SQL Server 2016 Feature Pack中的
Microsoft ODBC Driver 13 for SQL Server（x86版）； - 在VS中右键项目 →
属性→生成页 → 确认平台目标为x86； - 重新编译，或直接替换
/bin/Debug/下的System.Data.SqlClient.dll为x86兼容版本。
4.2 现象：药品查询结果为空，但数据库明明有数据；Fiddler抓包发现SQL查询返回0行
原因：app.config中连接字符串的Initial Catalog指向了错误数据库名。常见于还原.bak后未修改连接字符串，或SQL Server实例中有同名数据库（如DrugDB_old）。
解决：
- 在SSMS中执行
SELECT DB_NAME()确认当前数据库名； - 对比
app.config中Initial Catalog值； - 终极验证：在
SqlHelper.cs的ExecuteReader方法中，于using (var conn = new SqlConnection(connectionString))后添加日志：
运行时观察控制台输出的实际连接字符串。Console.WriteLine($"Connecting to: {conn.ConnectionString}");
4.3 现象：新增药品时提示“违反UNIQUE KEY约束”，但药品名称明显不重复
原因：Drug表的DrugName字段设置了UNIQUE约束，但数据库中存在全角空格、不可见Unicode字符（如U+FEFF零宽无间断空格）。用户从Excel复制药品名时极易带入。
解决：
- 修改建表脚本，在
DrugName列添加COLLATE SQL_Latin1_General_CP1_CI_AS（大小写不敏感，忽略空格差异）； - 或在C#层清洗输入：
drugName = Regex.Replace(drugName.Trim(), @"\s+", " ")； - 紧急修复：执行SQL清理历史脏数据：
UPDATE Drug SET DrugName = LTRIM(RTRIM(DrugName)) WHERE DrugName LIKE '% %'
4.4 现象：WinForm界面文字模糊，DPI缩放后按钮错位
原因：WinForm默认不支持高DPI缩放。该系统未在MainForm.Designer.cs中设置AutoScaleMode = AutoScaleMode.Dpi。
解决：
- 在
MainForm.cs构造函数中InitializeComponent()后添加：this.AutoScaleMode = AutoScaleMode.Dpi; this.AutoScaleDimensions = new SizeF(6F, 13F); - 将所有控件的
Font属性统一设为Microsoft Sans Serif, 8.25pt（避免微软雅黑在DPI缩放时渲染异常）； - 关键：禁用
Application.SetCompatibleTextRenderingDefault(false)（.NET Framework 2.0+默认为false，但某些旧模板仍设为true，导致GDI+文本渲染模糊）。
4.5 现象：导出Excel功能报错“未将对象引用设置到对象实例”，堆栈指向ExportToExcel.cs
原因：源码使用Microsoft.Office.Interop.Excel，但目标电脑未安装Office，或安装了WPS导致COM组件注册冲突。
解决：
- 彻底弃用Interop：改用
EPPlus（开源，纯.NET，无需Office）； - 安装NuGet包
EPPlus 5.8.7（兼容.NET Framework 4.7.2）； - 替换导出方法：
using (var package = new ExcelPackage()) { var ws = package.Workbook.Worksheets.Add("药品清单"); ws.Cells["A1"].Value = "药品名称"; // ... 填充数据 var stream = new MemoryStream(package.GetAsByteArray()); saveFileDialog1.FileName = "药品清单.xlsx"; if (saveFileDialog1.ShowDialog() == DialogResult.OK) File.WriteAllBytes(saveFileDialog1.FileName, stream.ToArray()); }
5. 生产环境加固：从“能跑”到“敢用”的4个关键改造
5.1 连接字符串加密：防止药房人员直接看到sa密码
app.config明文存储连接字符串是重大安全隐患。必须启用.NET配置节加密：
以管理员身份运行
Developer Command Prompt for VS2019；执行命令加密
connectionStrings节：aspnet_regiis -pef "connectionStrings" "C:\Path\To\Your\App"注意：
-pef参数指定物理路径，而非项目路径；aspnet_regiis工具位于C:\Windows\Microsoft.NET\Framework\v4.0.30319\。加密后
app.config中该节变为：<connectionStrings configProtectionProvider="RsaProtectedConfigurationProvider"> <EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Element" ...关键限制：加密密钥绑定到本机，迁移exe到其他电脑需重新加密，或导出密钥（
aspnet_regiis -px）再导入。
5.2 日志审计：记录谁在何时修改了什么药品信息
系统原生无操作日志。需在DAL/DrugDao.cs的UpdateDrug()方法中注入日志：
public void UpdateDrug(Drug drug, string operatorName) { string sql = @"UPDATE Drug SET ... WHERE DrugId = @id"; SqlHelper.ExecuteNonQuery(sql, drug); // 记录审计日志 string logSql = @" INSERT INTO AuditLog (TableName, Operation, RecordId, Operator, OperateTime) VALUES ('Drug', 'UPDATE', @drugId, @operator, GETDATE())"; SqlHelper.ExecuteNonQuery(logSql, new { drugId = drug.DrugId, operator = operatorName }); }表结构建议：
AuditLog表至少包含Id(BIGINT PK),TableName(NVARCHAR(50)),Operation(NVARCHAR(10)),RecordId(VARCHAR(50)),Operator(NVARCHAR(50)),OperateTime(DATETIME2)。RecordId存药品ID，若为其他表则存对应主键值。
5.3 批量导入容错：Excel药品数据校验与错误行定位
原系统仅支持单条录入。批量导入需处理Excel解析异常：
public List<ImportResult> ImportFromExcel(string filePath) { var results = new List<ImportResult>(); try { using (var package = new ExcelPackage(new FileInfo(filePath))) { var ws = package.Workbook.Worksheets[0]; for (int row = 2; row <= ws.Dimension.End.Row; row++) // 跳过标题行 { try { var drug = new Drug { Name = ws.Cells[row, 1].Value?.ToString().Trim(), Spec = ws.Cells[row, 2].Value?.ToString(), Unit = ws.Cells[row, 3].Value?.ToString(), Price = Convert.ToDecimal(ws.Cells[row, 4].Value) }; DrugService.AddDrug(drug, "Excel导入"); results.Add(new ImportResult { Row = row, Status = "Success" }); } catch (Exception ex) { results.Add(new ImportResult { Row = row, Status = "Failed", Error = ex.Message }); } } } } catch (Exception ex) { results.Add(new ImportResult { Status = "FileError", Error = ex.Message }); } return results; }用户体验：导入完成后弹出
DataGridView显示每行结果，红色标出失败行及错误原因，支持导出错误报告为Excel。
5.4 界面响应优化：解决大数据量药品列表卡顿的3个实招
当药品库超5000条时，DataGridView加载缓慢。优化方案：
| 优化点 | 实施方式 | 效果 |
|---|---|---|
| 虚拟模式启用 | dataGridView1.VirtualMode = true;+ 实现CellValueNeeded事件 | 内存占用降低80%，滚动流畅 |
| 分页查询 | DrugService.GetDrugs(pageIndex, pageSize)返回List<Drug>而非全量 | 首屏加载<1秒 |
| 列冻结 | dataGridView1.Columns["DrugName"].Frozen = true; | 水平滚动时关键列始终可见 |
代码示例（虚拟模式）：
private List<Drug> _allDrugs; // 全量缓存 private void LoadDrugList() { _allDrugs = DrugService.GetAllDrugs(); // 一次性加载 dataGridView1.RowCount = _allDrugs.Count; } private void dataGridView1_CellValueNeeded(object sender, DataGridViewCellValueEventArgs e) { if (e.RowIndex < _allDrugs.Count) { var drug = _allDrugs[e.RowIndex]; switch (e.ColumnIndex) { case 0: e.Value = drug.Name; break; case 1: e.Value = drug.Spec; break; // ... 其他列 } } }
6. 给后来者的三条硬核建议：关于这套C# WinForm药品系统的现实主义生存法则
6.1 不要试图把它改成Web系统——WinForm的“优势”恰恰是它的护城河
我见过太多人拿到这套源码，第一反应是“用Vue重写前端，ASP.NET Core做API”。结果呢？社区卫生站的电脑平均配置是i3-4170 + 4GB内存 + Windows 7，Chrome打开三个标签页就卡死。而WinForm的DataGridView在5000行数据下依然丝滑，因为它是直接调用GDI+，不经过浏览器渲染引擎。更关键的是离线能力：网络中断时，药房人员照样能扫码入库、打印单据——所有业务逻辑和数据库都在本地。Web方案需要部署IIS、配置HTTPS、处理跨域，而WinForm双击exe即用。技术选型不是比谁新，而是比谁在真实场景里不掉链子。
6.2 SQL Server不是“装完就完事”，必须做的3项基础运维
很多团队以为装好SQL Server就万事大吉，结果半年后系统越来越慢。必须每日执行：
- 索引碎片整理：当
sys.dm_db_index_physical_stats显示avg_fragmentation_in_percent > 30时，执行ALTER INDEX ALL ON DrugInventory REBUILD； - 事务日志截断：
DrugDB数据库恢复模式为FULL时，必须每天备份事务日志，否则log.ldf文件会暴涨到几十GB； - 统计信息更新：每月执行
EXEC sp_updatestats，否则查询优化器会基于过期统计生成低效执行计划（典型症状：SELECT * FROM DrugInventory WHERE CurrentStock > 0突然变慢）。
自动化脚本：将上述三步写成SQL Server Agent作业，每周日凌晨2点自动执行。别信“SQL Server自己会优化”——它只会按你给的统计信息优化，而统计信息不会自己更新。
6.3 最重要的改造不是代码，而是把“药品”概念真正吃透
源码里Drug类只有Name、Spec、Unit字段，但现实中药品管理远不止于此。我们上线前追加了这些字段并重构了UI：
| 字段 | 类型 | 业务意义 | 改造要点 |
|---|---|---|---|
BarCode | NVARCHAR(50) | 扫码枪识别依据 | 在入库窗体增加扫码输入框，绑定TextChanged事件实时查询 |
StorageCondition | TINYINT | 储存条件（0-常温,1-阴凉,2-冷藏） | 新增枚举类StorageConditionType，UI用ComboBox绑定 |
IsPrescription | BIT | 是否处方药 | 在药品列表增加“处方药”列，用DataGridViewImageColumn显示红蓝图标 |
教训：不要在代码里写死业务规则。比如“抗生素必须凭处方销售”，源码用
if (drug.Name.Contains("霉素"))判断，结果漏掉“头孢”“沙星”。正确做法是建DrugCategory表，关联药品与分类规则，规则由药剂师后台维护。
最后说一句掏心窝的话：这套系统真正的价值，不是它用了Dapper还是Entity Framework，而是它让社区护士不再用Excel手工登记效期，让站长手机收到“阿莫西林剩余12盒，距过期还有17天”的微信提醒。技术只是工具，而工具的好坏，永远由使用者皱眉还是舒展来定义。希望帮到你。
本文还有配套的精品资源，点击获取
)
