简介：一份基于C# Windows窗体与SQL Server的信息管理系统项目，以图书信息管理为业务场景，采用经典三层架构完成数据层、业务层与界面层的分离，并实现增、删、改、查等核心操作。压缩包共135个文件、约901KB，包含44个C#源文件、13个DLL动态库、配置文件、资源文件及resx界面资源，同时保留PDB与cache等编译中间产物，便于直接打开调试。数据库部分随包提供表结构代码与说明文档，使用者只需在SQL Server中生成数据库即可运行，无需手工建表；另附演示视频链接，可快速对照界面布局与操作流程。资源面向初步接触WinForm和数据库操作的初学者，调试简单、易于上手，适合作为课程设计、实训作业或知识点拓展的参考，目前已有3087人学习下载。通过该案例可掌握C#连接SQL Server、三层架构布局、数据增删查改流程及常见调试思路，为后续开发更完整的信息管理系统打下基础，对初学者尤其实用。
1. 一个 C# Windows 窗体图书信息管理系统，比你想的更吃数据库设计
C# + Windows 窗体 + 数据库做图书信息管理系统，算得上计算机专业课程设计里的经典标配，也是不少小型单位内部图书台账的务实起步方案。项目本身看着不重，但真正能把这套系统做成能天天用的东西，难点往往不在窗体拖了多少个控件，而在数据库表结构怎么铺、增删改查怎么写、借还书事务怎么保证数据一致。我先后用 C# Windows 窗体和 SQL Server 搭过几套图书管理方案，基本盘都包含图书档案录入、组合搜索、借还书登记、读者管理和库存统计，适合课程设计也适合没专职研发团队的内部场景。别把精力全花在界面美化上，先把数据库和连接层想清楚，后面的步骤才能少翻车。
2. 数据库设计先行：三张表还是五张表，外键和索引怎么铺
2.1 为什么最终还是落到“图书表 + 读者表 + 借阅流水表”的三角结构
做图书信息管理系统最容易犯的错，是觉得表建得越多越显工作量，第一版就铺开出版社表、书架表、管理员表、日志表，七八张表建完才发现大量关联查询绕得自己都头晕。图书管理这个业务的核心闭环其实很简单：书在哪、书给谁借走了、书什么时候还回来。围绕这个闭环，最少需要三张表：图书表存书名、作者、ISBN、分类、入库总量和当前库存；读者表存借阅人姓名、学号工号、联系方式、最大可借数量、账号状态；借阅流水表每行记录一次借出或归还动作，包含图书ID、读者ID、借出时间、应还时间、实还时间和状态。
三张表的关系是典型的主外键结构，借阅流水表作为中间表分别指向图书表（BookID）和读者表（ReaderID）。这个结构的好处在于，任何一本被借走的书都可以通过流水表追溯到哪个读者借的，同一个读者借了哪些书也能一键查出来，逾期未还的清单写一条 SQL 就能统计。至于出版社、书架位次这些信息，本质上是图书的一个属性字段，不是业务实体。图书管理系统解决“谁借了什么、什么时候还”的问题，根本不需要为出版社单建表。强行拆表只会在新增图书时多维护一次关联，查询时多一次 JOIN，得不偿失。
业务数据量在几万条以内时，三张表就是最优解。如果后面真的要做多馆藏、多库房、预约排队之类的延伸功能，再按需把书架表或预约表加进去，基础的三表结构也不需要推翻。一开始管住手，后面改起来才不心疼。
2.2 建库脚本：NVARCHAR 字段类型、外键和索引一次配好
下面是 SQL Server 的建表脚本，这也是 Windows 窗体项目最常见的搭配之一。我用的是 SQL Server 2012 以上版本的语法，如果你的环境是 MySQL，字段类型和外键语法需要做少量调整，后面会提到差异。
-- 图书信息表 CREATE TABLE [dbo].[Books]( [BookID] INT IDENTITY(1,1) NOT NULL PRIMARY KEY, [Title] NVARCHAR(100) NOT NULL, [Author] NVARCHAR(50) NULL, [ISBN] NVARCHAR(20) NULL, [Category] NVARCHAR(50) NULL, [TotalQty] INT NOT NULL DEFAULT 0, [AvailableQty] INT NOT NULL DEFAULT 0, [Location] NVARCHAR(50) NULL, [CreateTime] DATETIME NOT NULL DEFAULT GETDATE() ); -- 读者表 CREATE TABLE [dbo].[Readers]( [ReaderID] INT IDENTITY(1,1) NOT NULL PRIMARY KEY, [ReaderNo] NVARCHAR(20) NOT NULL UNIQUE, [ReaderName] NVARCHAR(20) NOT NULL, [Phone] NVARCHAR(20) NULL, [MaxBorrow] INT NOT NULL DEFAULT 5, [Status] TINYINT NOT NULL DEFAULT 1 ); -- 借阅流水表 CREATE TABLE [dbo].[BorrowRecords]( [RecordID] INT IDENTITY(1,1) NOT NULL PRIMARY KEY, [BookID] INT NOT NULL FOREIGN KEY REFERENCES [dbo].[Books]([BookID]), [ReaderID] INT NOT NULL FOREIGN KEY REFERENCES [dbo].[Readers]([ReaderID]), [BorrowTime] DATETIME NOT NULL DEFAULT GETDATE(), [DueTime] DATETIME NOT NULL, [ReturnTime] DATETIME NULL, [Status] TINYINT NOT NULL DEFAULT 0 );字段设计上有三个细节值得说明。第一，所有字符串字段都用 NVARCHAR，不用 VARCHAR。原因是 C# 端录入的中文在 .NET 里默认是 Unicode，如果数据库列是 VARCHAR，写入时按代码页转换，遇到生僻字或特殊符号就容易变成问号；NVARCHAR 则直接把 Unicode 存进去，乱码概率大幅降低。第二，库存拆成 TotalQty 和 AvailableQty 两个字段，TotalQty 是馆藏总量不随借还变化，AvailableQty 是当前可借数量，借书减一、还书加一，这种设计让库存统计不需要每次 COUNT 流水表。第三，借阅流水表只存 ID 不存冗余姓名和书名，显示的时候用 JOIN 查出来，避免读者改名或图书信息修正后流水表里留存旧数据。
索引的创建也有讲究。Books 表的 ISBN 是高频精确查询字段，BorrowRecords 表的 ReaderID、BookID、Status 则会在借阅历史查询、库存核对、逾期统计中反复使用，第一版就建上：
CREATE INDEX IX_Books_ISBN ON [dbo].[Books]([ISBN]); CREATE INDEX IX_BorrowRecords_ReaderID ON [dbo].[BorrowRecords]([ReaderID]); CREATE INDEX IX_BorrowRecords_BookID ON [dbo].[BorrowRecords]([BookID]); CREATE INDEX IX_BorrowRecords_Status ON [dbo].[BorrowRecords]([Status]);索引不是建得越多越好。Title 字段如果经常做 LIKE '%关键字%' 模糊匹配，普通索引完全不生效，因为前导通配符会让索引扫描退化成全表扫描，这段查询在几千条数据量下也不慢，没必要为它建索引。真正需要留意的是 ISBN，它作为精确匹配字段，索引收益很高。_STATUS 索引则会加速“某个读者当前借了几本未还的书”这类高频校验，别忽视。
2.3 连接字符串与数据库部署：别用 LocalDB 应付现场环境
Windows 窗体项目连接数据库最直接的方式，是把连接字符串放在 App.config 里。注意 providerName 要写成 System.Data.SqlClient 或 Microsoft.Data.SqlClient，后续代码读取时才找得到配置。
<connectionStrings> <add name="LibraryDB" connectionString="Server=.;Database=LibraryDB;User Id=sa;Password=你的密码;Encrypt=True;TrustServerCertificate=True;MultipleActiveResultSets=True" providerName="System.Data.SqlClient" /> </connectionStrings>连接字符串里三个参数直接决定系统能不能长期稳定跑。MultipleActiveResultSets=True允许同一个 SqlConnection 上并行执行多个 SqlDataReader，避免在 DataGridView 绑定结果后，另一个查询报“存在已经打开的 DataReader 相关联的命令”；Encrypt=True是 SQL Server 新版本驱动默认开启的加密要求，如果数据库是内网环境且没有配置证书，必须配合TrustServerCertificate=True，否则每次连接都会报证书校验失败；Connection Timeout默认 15 秒，数据库不在本机时可以显式改成 30，避免网络抖动时界面卡住 15 秒才报错。
部署数据库有两种常见路径。一种是直接在 SQL Server 实例里建库建表，程序通过服务器地址和账号访问；另一种是把 .mdf 文件放进项目里，用AttachDbFilename附加。对于图书管理系统这种要交付给用户用的场景，我一般强烈建议选第一种。AttachDbFilename 在打包发布后经常因文件路径变化、SQL Express 用户权限不足导致连接失败，排查起来极耗时间。直接在 SQL Server 实例里建库，只需要保证服务器地址、账号、密码三个信息正确，客户端程序连不上时问题定位路径也短得多。
3. 数据访问层落地：DBHelper 封装、参数化查询和登录校验的写法
3.1 为什么不能在每个窗体按钮里裸写 SqlConnection
不少入门教材教“连接三步曲”：new SqlConnection、new SqlCommand、new SqlDataAdapter，每个按钮事件里写一遍。这种写法在单个窗体上成立，但图书信息管理系统里窗体多了之后就是灾难，连接字符串散落几十处、错误处理逻辑各写各的、修改数据库连接时全项目查找替换，这类教训是项目中踩过的。
第一步自然是做一个 DBHelper 静态类，把连接创建、参数注入、执行和资源释放收口。一个最小可用的版本大致是：
using System; using System.Configuration; using System.Data; using System.Data.SqlClient; public static class DBHelper { // 整个程序共享一个连接字符串，修改只动 App.config public static readonly string ConnStr = ConfigurationManager.ConnectionStrings["LibraryDB"].ConnectionString; // 查询：返回 DataTable，便于直接绑定 DataGridView public static DataTable Query(string sql, SqlParameter[] parameters = null) { using (SqlConnection conn = new SqlConnection(ConnStr)) using (SqlCommand cmd = new SqlCommand(sql, conn)) { if (parameters != null) cmd.Parameters.AddRange(parameters); SqlDataAdapter adapter = new SqlDataAdapter(cmd); DataTable dt = new DataTable(); adapter.Fill(dt); return dt; } } // 增删改：返回受影响行数 public static int ExecuteNonQuery(string sql, SqlParameter[] parameters = null) { using (SqlConnection conn = new SqlConnection(ConnStr)) using (SqlCommand cmd = new SqlCommand(sql, conn)) { if (parameters != null) cmd.Parameters.AddRange(parameters); conn.Open(); return cmd.ExecuteNonQuery(); } } // 聚合查询：返回单个值，如 COUNT、SUM public static object ExecuteScalar(string sql, SqlParameter[] parameters = null) { using (SqlConnection conn = new SqlConnection(ConnStr)) using (SqlCommand cmd = new SqlCommand(sql, conn)) { if (parameters != null) cmd.Parameters.AddRange(parameters); conn.Open(); return cmd.ExecuteScalar(); } } }这段代码的逻辑说明：using 块确保 SqlConnection 和 SqlCommand 在方法出口自动释放，这是防止连接泄漏的关键点，很多人写数据库代码时忘了 close 连接，程序跑几天后数据库报“已达最大连接数”；参数通过 SqlParameter 数组传入，而不是把字符串拼进 SQL，从源头挡住了最常见的注入入口；Query 方法使用 SqlDataAdapter.Fill，好处是结果一次性落入内存 DataTable，可以直接赋给 DataGridView 的 DataSource，图书管理的数据量在几千上万行时完全够用。
有人会问连接池去哪了？ADO.NET 默认开启了连接池，ConnStr 相同的连接会被复用，不需要自己去实现池化。需要注意的是连接池缓存的依据是连接字符串文本，一旦改动连接字符串，旧连接仍然留在池里直到超时被清理。
3.2 图书信息增删改查：参数化 SQL 的标准封装
基于 DBHelper，图书新增和删除的代码能控制得很收敛。新增图书时，AvailableQty 初始值直接等于 TotalQty，表示入库多少就能借多少：
public bool AddBook(string title, string author, string isbn, string category, int totalQty, string location) { string sql = @"INSERT INTO Books (Title, Author, ISBN, Category, TotalQty, AvailableQty, Location) VALUES (@Title, @Author, @ISBN, @Category, @TotalQty, @AvailableQty, @Location)"; SqlParameter[] parameters = { new SqlParameter("@Title", SqlDbType.NVarChar, 100) { Value = title }, new SqlParameter("@Author", SqlDbType.NVarChar, 50) { Value = author }, new SqlParameter("@ISBN", SqlDbType.NVarChar, 20) { Value = isbn }, new SqlParameter("@Category", SqlDbType.NVarChar, 50) { Value = category }, new SqlParameter("@TotalQty", SqlDbType.Int) { Value = totalQty }, new SqlParameter("@AvailableQty", SqlDbType.Int) { Value = totalQty }, new SqlParameter("@Location", SqlDbType.NVarChar, 50) { Value = location } }; return DBHelper.ExecuteNonQuery(sql, parameters) > 0; }参数名的类型和长度最好跟表结构对齐。比如 @Title 声明为 NVarChar 100，Value 赋的是 C# 端字符串，如果用户输入超长，SqlClient 会直接抛异常而不是截断，这样反而提示了输入校验。修改图书时有一个容易遗漏的细节：如果图书被借出一部分，修改 TotalQty 时不能直接把 AvailableQty 覆盖为新总量，正确做法是按差值调整，比如原来总库存 10、可借 4，现在改成 15，可借应该变成 9，而不是 15。
删除图书前必须检查借阅流水表中是否存在未归还记录。一个干净的检查方法是用 EXISTS 子查询：
public bool CanDeleteBook(int bookID) { string sql = @"SELECT COUNT(1) FROM BorrowRecords WHERE BookID = @BookID AND Status = 0"; SqlParameter[] parameters = { new SqlParameter("@BookID", SqlDbType.Int) { Value = bookID } }; int borrowingCount = Convert.ToInt32(DBHelper.ExecuteScalar(sql, parameters)); return borrowingCount == 0; }这里 status = 0 表示“借出未还”。如果返回数量大于 0，窗体端应该给出提示，并列出当前借阅人信息，而不是直接把书删掉。很多人做删除功能时只判断记录存在就允许删，结果流水表出现悬空引用，后续统计一查就出问题。
3.3 登录与权限的最小实现，别把密码做明文
登录是窗体程序的门面。最小实现是给管理员建一张独立的 Admin 表，登录窗口校验用户名和密码，同时判断账号状态字段是否被禁用：
public bool ValidateAdmin(string username, string password) { string sql = @"SELECT COUNT(1) FROM Admins WHERE Username = @Username AND Password = @Password AND Status = 1"; SqlParameter[] parameters = { new SqlParameter("@Username", SqlDbType.NVarChar, 20) { Value = username }, new SqlParameter("@Password", SqlDbType.NVarChar, 50) { Value = password } }; int count = Convert.ToInt32(DBHelper.ExecuteScalar(sql, parameters)); return count > 0; }登录窗体里记得把密码框的 UseSystemPasswordChar 设为 true，并处理 Enter 键直接触发登录按钮，这些都属于 Windows 窗体交互的基本盘。但实话实说，如果这套系统真的要给别人用，密码不能明文存储，至少也要加盐后做 SHA256 哈希。课程设计阶段为了演示方便可以明文，但写进自己简历或者交付给单位时，密码哈希是安全底线。哈希的做法是在录入管理员时，将密码通过 Convert.ToHexString(SHA256.HashData(...)) 转成十六进制字符串存库，登录时对输入做同样哈希后再比对。
4. 窗体交互层：DataGridView 绑定、组合查询和借还书事务
4.1 主窗体数据展示：DataGridView 直接吃 DataTable
主界面通常是上方放查询条件，中间一个 DataGridView 展示图书列表，右侧或底部分布新增、编辑、删除、借书、还书、读者管理按钮。DataGridView 最省力的用法是直接把 DataTable 丢给 DataSource，列自动生成，列头则通过 SQL 别名控制：
private void LoadBooks() { string sql = @"SELECT BookID 编号, Title 书名, Author 作者, ISBN, Category 分类, AvailableQty 可借数量, Location 馆藏位置 FROM Books ORDER BY BookID DESC"; DataTable dt = DBHelper.Query(sql); dataGridViewBooks.DataSource = dt; }这里 SQL 里用别名让列头直接显示“编号、书名、作者”，就省掉了 DataGridView 的列绑定配置。但也有一个要预防的点：自动生成的列里会包含 BookID，编号列显示出来没问题，但如果你不想让用户看到主键，可以这样处理：
dataGridViewBooks.DataSource = dt; dataGridViewBooks.Columns["编号"].Visible = false;DataGridView 的选中模式建议设为 FullRowSelect，这样用户单击任意单元格就选中整一行，配合 CurrentRow.Cells["编号"].Value 能方便取到当前图书记录。数据量方面，如果图书超过两三千行，每次全量加载会让窗体打开变慢，常见的折中做法是默认只加载最近入库的 500 条，用户通过查询条件不断缩小范围，这个策略在图书管理场景里完全够用。
4.2 组合查询：下拉框加文本框加动态参数化 SQL
图书查询的交互样式一般是：下拉框选择按“书名/作者/ISBN”查，旁边文本框输入关键词，点击查询后刷新 DataGridView。注意下拉框要配置好 SelectedIndex 和查询字段的映射，SQL 则用动态拼接但参数固定注入的方式写：
private void btnSearch_Click(object sender, EventArgs e) { string keyword = txtKeyword.Text.Trim(); if (keyword == "") { LoadBooks(); return; } string sql = "SELECT * FROM Books WHERE 1 = 1"; SqlParameter[] parameters; if (cboSearchField.SelectedIndex == 0) // 按书名 { sql += " AND Title LIKE @kw"; parameters = new SqlParameter[] { new SqlParameter("@kw", SqlDbType.NVarChar, 100) { Value = "%" + keyword + "%" } }; } else if (cboSearchField.SelectedIndex == 1) // 按作者 { sql += " AND Author LIKE @kw"; parameters = new SqlParameter[] { new SqlParameter("@kw", SqlDbType.NVarChar, 50) { Value = "%" + keyword + "%" } }; } else // 按 ISBN { sql += " AND ISBN LIKE @kw"; parameters = new SqlParameter[] { new SqlParameter("@kw", SqlDbType.NVarChar, 20) { Value = "%" + keyword + "%" } }; } sql += " ORDER BY BookID DESC"; DataTable dt = DBHelper.Query(sql, parameters); dataGridViewBooks.DataSource = dt; }这里有一个新手常踩的坑：很多人把 SQL 写成LIKE '%@kw%'，运行查不出结果。因为参数占位符 @kw 在 SQL 解析时会被替换成值，但单引号内的 %@kw% 被当成普通字符串，参数替换并不发生在字符串字面量内部。正确做法是在 C# 端把关键词两侧拼上 %，SQL 里只写LIKE @kw。
组合查询的边界情况也要处理。关键词为空时直接恢复默认列表，不要发一个带空 %% 的 LIKE 查询；下拉框默认选中“书名”，避免用户不清空长时间使用后定位到错误选项。这些都是小细节，但决定了窗体程序好不好用。
4.3 借书和还书：一个事务把扣库存和写流水绑在一起
借书功能包含两个数据库动作：往 BorrowRecords 插一条借出记录，同时把 Books 表的 AvailableQty 减一。这两个动作不在一个事务里完成，就会出现流水记了但库存没减、或者库存减了却查不到借阅记录的脏数据。事务的正确写法是这样的：
public bool BorrowBook(int bookID, int readerID, int days) { using (SqlConnection conn = new SqlConnection(DBHelper.ConnStr)) { conn.Open(); SqlTransaction tran = conn.BeginTransaction(); try { // 1. 检查库存并锁定该行，防止并发超卖 string checkSql = "SELECT AvailableQty FROM Books WITH (UPDLOCK, HOLDLOCK) WHERE BookID = @BookID"; using (SqlCommand cmd = new SqlCommand(checkSql, conn, tran)) { cmd.Parameters.AddWithValue("@BookID", bookID); int available = (int)cmd.ExecuteScalar(); if (available <= 0) throw new Exception("库存不足，无法借出"); } // 2. 扣减库存 string updateSql = "UPDATE Books SET AvailableQty = AvailableQty - 1 WHERE BookID = @BookID"; using (SqlCommand cmd = new SqlCommand(updateSql, conn, tran)) { cmd.Parameters.AddWithValue("@BookID", bookID); cmd.ExecuteNonQuery(); } // 3. 插入借阅记录 string insertSql = @"INSERT INTO BorrowRecords (BookID, ReaderID, BorrowTime, DueTime, Status) VALUES (@BookID, @ReaderID, GETDATE(), DATEADD(day, @Days, GETDATE()), 0)"; using (SqlCommand cmd = new SqlCommand(insertSql, conn, tran)) { cmd.Parameters.AddWithValue("@BookID", bookID); cmd.Parameters.AddWithValue("@ReaderID", readerID); cmd.Parameters.AddWithValue("@Days", days); cmd.ExecuteNonQuery(); } tran.Commit(); return true; } catch { tran.Rollback(); throw; } } }借书代码里有两点值得深说。第一，检查库存的 SELECT 加了WITH (UPDLOCK, HOLDLOCK)，锁定 Books 表中 BookID 对应行的排他锁直到事务结束，这是防并发超卖的关键。如果不加锁，两个读者同时借同一本库存只有 1 的书，两个事务都读到可借数量 1，然后各自 INSERT 一条流水并把库存减一，最终结果是库存变成 -1，账面上多了两笔借出记录。图书管理系统虽然并发量不高，但这个写法是标准的防超卖姿势。第二，DATEADD(day, @Days, GETDATE()) 在 SQL Server 端计算应还时间，C# 端只需要传入借阅天数。借阅天数一般由窗体上的 NumericUpDown 控件取值，然后用 int.Parse 转成参数。
还书是借书的逆操作，但状态处理上有个细节要留意。还书时不仅要把借阅记录的 Status 改成 1、ReturnTime 设为当前时间，如果当前时间晚于 DueTime，还应该把 Status 标成 2 表示逾期。同时，Books 表的 AvailableQty 要加一。这个过程同样要包在事务里，三个动作缺一不可。
5. 排错手册：连接串、中文乱码、超卖、卡死和特殊字符这五类高频故障
5.1 连接数据库失败：超时、服务未启用、加密选项相互纠缠
现象：程序启动后点击登录按钮，界面卡住十几秒，然后弹出 SqlException，提示“在建立到服务器的连接时出错”或“连接超时”。
原因：九成情况是连接字符串的 Server 地址写错了。Server=.表示本机默认实例，但目标机器装的是命名实例如 SQLEXPRESS，不写实例名就连不上。还有两成情况是 SQL Server 服务没启动，或者是 SQL Server 新版本驱动默认开启 Encrypt 加密但本地库没有配置证书，导致握手失败。
解决：先打开 SQL Server Management Studio，确认能用本机账号登录。再逐项排查连接字符串，本地开发先按Server=.;Database=LibraryDB;User Id=sa;Password=你的密码;Encrypt=False;MultipleActiveResultSets=True这个最小配置走，连上后再放开 Encrypt 和 TrustServerCertificate 的组合。命令行里也可以用sqlcmd -S . -U sa -P 密码 -d LibraryDB -Q "SELECT 1"快速验证数据库本身是否可连，这样能把问题定位到程序还是数据库服务。
5.2 中文写入后变成问号或乱码
现象：窗体录入“红楼梦”，保存后读出来变成“???”，或者写入时立刻报字符截断错误。
原因：建表时字符串字段用了 VARCHAR，SQL Server 按数据库默认代码页存储，客户端传入的 Unicode 字符被转换后丢失；另一种常见原因是 SqlParameter 没有指定 SqlDbType，默认按 VARCHAR 处理。还有一个场景是数据库排序规则为英文环境，比如 SQL_Latin1_General_CP1_CI_AS，中文存进去显示为问号。
解决：表字段统一改成 NVARCHAR，这是治本的方案。出了乱码的数据没有后悔药，只能重建表重录。代码层面，所有 SqlParameter 显式声明 SqlDbType.NVarChar 并带上长度。建库时最好把数据库默认排序规则设成 Chinese_PRC_CI_AS，这一步在候选库的“选项”页里可以提前配好。
5.3 借书并发导致库存变负数
现象：多台客户端同时借同一本书，操作不报错，但数据库里 Books 表的 AvailableQty 变成负数，流水记录比实际库存减少次数多。
原因：借书代码只做了“先 SELECT 检查库存，再 UPDATE 扣减”，没有加锁时，两个并发事务同时读到相同库存值，各自执行扣减，最终可用库存被减了两次。这就是传说中的超卖，图书管理场景里虽然少，但一旦遇到就是数据事故。
解决：在检查库存的 SELECT 语句上加WITH (UPDLOCK, HOLDLOCK)，锁定该行直到事务结束；或者在 UPDATE 的 WHERE 条件里带上AvailableQty > 0，如果受影响行数为 0 就抛出“库存不足”。两个方案二选一即可，两条同时用也无妨。注意锁粒度是行级锁，锁定范围刚好是 BookID 对应的那一行，不会影响其他书的借还。
5.4 打开窗口卡死，标题栏变成灰色“未响应”
现象：双击图书列表窗体的菜单，窗口半天弹不出来，系统提示什么都没有回应；偶尔弹出来后，滚动内容也是一顿一顿的。
原因：LoadBooks 方法里全表查询是同步执行的。数据量超过几千行，或者数据库服务器不在本机时，UI 线程被数据库响应时间阻塞。Windows Forms 的 UI 线程一旦长时间不处理消息循环，系统就把窗口标记为“未响应”。
解决：第一层是限制默认加载量，比如 SQL 查询里加OFFSET 0 ROWS FETCH NEXT 500 ROWS ONLY或用 TOP 500，配合查询条件缩小数据范围。第二层是把耗时查询从 UI 线程挪走，常见做法是用 async 事件方法：
private async void LoadBooksAsync() { DataTable dt = await Task.Run(() => DBHelper.Query( "SELECT TOP 500 * FROM Books ORDER BY BookID DESC")); dataGridViewBooks.DataSource = dt; }事件方法用 async void 是可以的，但普通业务方法里不要用 async void，异常处理不到就会直接崩溃。
5.5 搜索框输入特殊字符报错或返回异常结果
现象：搜索框输入单引号、百分号或' OR 1=1 --，点击查询后程序报语法错误，甚至返回了全表数据。
原因：老代码如果用了字符串拼接 SQL，单引号会破坏查询结构，1=1这类经典注入会让查询绕过原有过滤条件。即使没报错，WHERE 条件被篡改也是数据泄露。
解决：所有查询统一走 SqlParameter 参数化，禁止把用户文本直接拼进 SQL 字符串。LIKE 查询里如果用户输入的 % 和 _ 是有意的搜索字符，直接拼进参数即可；如果要按字面值匹配，可以在参数值里用 SQL Server 的 ESCAPE 语法转义。这里最基础的防线就是参数化，这条做到了，注入门就关上了大半。
6. 再往前走一步：从课程设计变成真能用的系统
系统跑通、功能演示完，如果再花一两个小时做三个改动，它就能从“课程作业”变成“部门里有人愿意天天用”的工具。
第一个改动是把借还书逻辑从按钮事件里拆出来。借书按钮的 Click 委托里只负责取界面值、调用业务方法、刷新表格和提示结果，把事务、SQL、库存检查都放到独立的 BorrowService 类里。这样借书功能还能被另一个入口复用，比如到期自动续借、批量借出，不用复制粘贴代码。
第二个改动是加日志。在 DBHelper 里留一个 Log 方法，把每一次增删改操作的操作人、操作时间、操作类型、受影响行数和可能的异常信息写进日志表。文件台账盘点对不上的时候，这张表是唯一能查询“谁在什么时候动了库存”的凭证。日志写入单独开一个方法，不要和业务 SQL 混在同一个事务里，否则日志失败会导致业务回滚。
第三个改动是做一次真实环境部署演练。在目标机器装好 SQL Server，把数据库备份成一个 .bak 文件，再从另一台机器用这个备份还原，然后跑通登录、查书、借书、还书四个主流程。这一步暴露的问题往往比写代码时多得多：账号权限不足、防火墙挡了 1433 端口、数据库还原后登录名没有映射到用户，都是常见翻车点。我的习惯是建库时把所有业务表和一个 Admin 账号一起写入初始化脚本，新环境执行一遍就到位，不给手工配置留机会。
窗体和数据库这套组合在技术圈不算时髦，但它的优势也实在：部署简单、启动快、易维护，对图书管理这类内部系统来说是一个务实的选择。希望帮到你。
本文还有配套的精品资源，点击获取
