简介：一份面向C#课程设计场景的宿舍管理系统完整源码包，以Visual Studio项目为主体，配套文档、流程图与SQL数据库脚本，适用于需要完成同类课程设计或进行WinForm开发练习的初学者。系统按学生与宿管双角色设计，覆盖公告发布、宿舍信息增删改查、物品报修审批、请假销假、用户登录管理等基础业务；界面借助CSkin组件美化，并通过WebService获取地理位置和天气信息，整体结构清晰。压缩包共188个文件，约4.7MB，以cs源码、resx界面资源、dll依赖库、配置文件及mdf/ldf数据库文件为主，同时含docx说明书与sql脚本，便于直接还原项目环境。已有1377人下载学习，可作为课程设计参考、答辩演示或二次开发基础，帮助理解分层调用、XML用户记录与WinForm交互等关键实现。
1. 这套 C# 宿舍管理系统到底能做什么、适合谁接手
宿舍管理系统是 C# 入门到进阶最经典的落地项目之一，甚至可以说，很多人的第一个「能给别人演示的完整系统」就是它。它的本质是一个典型的管理信息系统（MIS）：前台是 WinForms 窗体，后台是一张 SQL Server 或 SQLite 数据库表，中间是增删改查。你拿到一个名为「C#宿舍管理系统.rar」的压缩包，说明交付形态已经是打包好的源码工程，里面大概率包含 .sln 解决方案、若干窗体文件（.cs / .Designer.cs）、数据库脚本和说明文档。这类系统的目标用户是宿管员和辅导员，要解决的是入住登记、退宿调宿、床位统计、报修跟踪这些真实场景，而不是教你写算法。
这个方向对三类人最有用：正在做课程设计或毕业设计的学生，需要一个能跑通、能讲清楚的设计思路；小团队里被要求「一周内给后勤做个宿舍管理小工具」的开发者；以及想系统练一遍 C# + SQL Server 数据访问、委托事件、界面绑定的自学者。下面我按自己做过类似项目的顺序拆开讲：先定数据表，再搭工程，最后落功能、填坑、打包交付。
2. 拆开 .rar 后先建这 5 张表：宿舍管理系统的数据库设计
2.1 核心表结构与字段设计
打开 .rar 后，先不要急着点 .sln 跑起来，第一件事是看数据库脚本。很多翻车现场都出在表结构不合理：学生和宿舍直接绑死、没有入住记录表、报修信息只存一个备注字段。我一般会建议至少建下面这 5 张表：学生表、宿舍表、入住记录表、报修表、用户表。宿舍和学生不直接外键关联，而是通过「入住记录」这张关系表把入住、退宿、调宿的历史串起来，这是整个系统的核心设计。
表结构大致是这样：
- 学生表（Student）：学号、姓名、性别、班级、电话、状态（在住/离校）、当前宿舍 ID、当前床位号。状态字段很重要，退宿后不能删记录，只能改状态。
- 宿舍表（Dormitory）：楼号、房间号、床位总数、已住人数、宿管员、备注。已住人数是冗余字段，但查询统计时非常快，维护靠事务保证一致。
- 入住记录表（CheckRecord）：学生学号、宿舍 ID、床位号、入住时间、退宿时间、状态。一次调宿就是一条退宿记录加一条新入住记录。
- 报修表（Repair）：宿舍 ID、报修人、联系电话、故障描述、状态、提交时间、处理时间。这是最容易被人忽略但实际使用频率最高的表。
- 用户表（SysUser）：用户名、密码哈希、盐值、角色。系统要区分宿管员和普通管理员，权限不同。
从业务角度看，宿舍和床位是「资源」，学生是「人」，入住记录是「资源和人的关系」。你设计的表一旦能把这三个层次分开，后面的入住、退宿、调宿代码都会非常顺。
2.2 用 SQL 脚本一次建好库和测试数据
常见的做法是在 SQL Server Management Studio 里先建一个空库，然后执行下面的脚本。我习惯把脚本分成三部分：建库、建表、插测试数据，这样重跑时不会因为顺序问题报错。
-- 创建数据库（如果存在则跳过） IF DB_ID(N'dormitory_db') IS NULL CREATE DATABASE dormitory_db; GO USE dormitory_db; GO -- 宿舍表 CREATE TABLE Dormitory ( DormitoryId INT IDENTITY(1,1) PRIMARY KEY, BuildingNo NVARCHAR(10) NOT NULL, -- 楼号，例如 "A" RoomNo NVARCHAR(10) NOT NULL, -- 房间号，例如 "301" BedCount INT NOT NULL CHECK (BedCount > 0), -- 总床位数 UsedCount INT NOT NULL DEFAULT 0, -- 已住人数 Manager NVARCHAR(20) NULL, -- 宿管员 Remark NVARCHAR(200) NULL ); GO -- 学生表 CREATE TABLE Student ( StudentNo NVARCHAR(20) PRIMARY KEY, -- 学号 Name NVARCHAR(20) NOT NULL, Gender CHAR(1) NOT NULL DEFAULT '男', ClassName NVARCHAR(50) NULL, -- 班级 Phone NVARCHAR(11) NULL, Status INT NOT NULL DEFAULT 1, -- 1=在住 0=离校 DormitoryId INT NULL, -- 当前宿舍 BedNo INT NULL, -- 当前床位 FOREIGN KEY (DormitoryId) REFERENCES Dormitory(DormitoryId) ); GO -- 入住记录表 CREATE TABLE CheckRecord ( RecordId INT IDENTITY(1,1) PRIMARY KEY, StudentNo NVARCHAR(20) NOT NULL, DormitoryId INT NOT NULL, BedNo INT NOT NULL, CheckInDate DATETIME NOT NULL DEFAULT GETDATE(), CheckOutDate DATETIME NULL, Status INT NOT NULL DEFAULT 1, -- 1=在住 0=已退宿 FOREIGN KEY (StudentNo) REFERENCES Student(StudentNo), FOREIGN KEY (DormitoryId) REFERENCES Dormitory(DormitoryId) ); GO -- 报修表 CREATE TABLE Repair ( RepairId INT IDENTITY(1,1) PRIMARY KEY, DormitoryId INT NOT NULL, Reporter NVARCHAR(20) NOT NULL, Phone NVARCHAR(11) NULL, Description NVARCHAR(500) NOT NULL, Status INT NOT NULL DEFAULT 0, -- 0=待处理 1=处理中 2=已完成 CreateTime DATETIME NOT NULL DEFAULT GETDATE(), HandleTime DATETIME NULL, FOREIGN KEY (DormitoryId) REFERENCES Dormitory(DormitoryId) ); GO -- 用户表 CREATE TABLE SysUser ( UserId INT IDENTITY(1,1) PRIMARY KEY, UserName NVARCHAR(20) NOT NULL UNIQUE, PasswordHash NVARCHAR(64) NOT NULL, Salt NVARCHAR(16) NOT NULL, Role NVARCHAR(10) NOT NULL DEFAULT 'user' -- admin / user ); GO建表时重点看两处：Student 表里 DormitoryId 和 BedNo 是「当前状态」字段，CheckRecord 才是「历史事实」。查询「某学生现在住哪」直接看 Student 表，查询「某房间住过哪些人」必须看 CheckRecord。这两套数据并存是刻意的，不是冗余冗余到失控，而是用空间换查询复杂度。
测试数据不要插太多，够演示三种状态就行：一个房间住满、一个房间有空床、一个学生已经离校但历史记录还在。
INSERT INTO Dormitory (BuildingNo, RoomNo, BedCount, UsedCount, Manager) VALUES ('A', '301', 4, 2, N'张阿姨'), ('B', '502', 6, 0, N'李大爷'); GO INSERT INTO Student (StudentNo, Name, Gender, ClassName, Phone, Status, DormitoryId, BedNo) VALUES ('2021001', N'王小明', N'男', N'计算机2101', '13800000001', 1, 1, 1), ('2021002', N'刘洋', N'男', N'计算机2101', '13800000002', 1, 1, 2), ('2021003', N'陈静', N'女', N'软件2102', '13800000003', 0, NULL, NULL); GO INSERT INTO CheckRecord (StudentNo, DormitoryId, BedNo, CheckInDate, Status) VALUES ('2021001', 1, 1, '2024-09-01', 1), ('2021002', 1, 2, '2024-09-01', 1), ('2021003', 2, 1, '2024-09-01', 0); GO一个容易忽略的参数是字符串前的 N。SQL Server 里如果往 NVARCHAR 列插入中文字符串而不带 N 前缀，某些排序规则下会出现乱码或问号。这是老生常谈，但几乎每届做宿舍管理系统的同学都会踩一次，所以脚本里我全部写成 N'中文'。
2.3 外键与索引：查询慢和删不掉的坑从这里来
宿舍管理系统的数据量基本不会超过几万条，索引不是性能瓶颈，真正坑人的是外键导致的删除失败和统计错误。最常见的报错是「已住的宿舍无法删除」——你明明写了 DELETE FROM Dormitory WHERE DormitoryId=1，但 SQL Server 报外键冲突。原因就是 Student 表和 CheckRecord 表都引用了 DormitoryId。
这里的处理原则是：宿舍和学生属于基础数据，只允许「逻辑删除」（加一个 IsDeleted 字段或修改状态），不允许物理删除；入住记录一旦生成，永远不删，只做退宿标记。这样设计之后，删除操作几乎从业务代码里消失，你也就不用跟外键约束死磕了。
索引方面，我给这三个查询建了索引：CheckRecord 上的 StudentNo（查某人的住宿历史）、CheckRecord 上的 DormitoryId（查某房间的入住记录）、Repair 上的 Status（统计待处理工单）。建索引的 SQL 很短，但注意不要在 StudentNo 这种已经是主键的列上重复建，主键本身自带索引。
CREATE INDEX IX_CheckRecord_StudentNo ON CheckRecord(StudentNo); CREATE INDEX IX_CheckRecord_DormitoryId ON CheckRecord(DormitoryId); CREATE INDEX IX_Repair_Status ON Repair(Status); GO索引不是越多越好。宿舍管理这种量级，三五个索引足够，多了反而拖慢插入速度。如果后期发现按班级统计住校人数很频繁，可以在 Student.ClassName 上加一个非聚集索引，这就是全部了。
3. 从零搭起 C# WinForms 项目：登录、主界面与数据访问层
3.1 项目结构与 NuGet 包选择
数据库定了之后，C# 这边的工程结构我推荐拆成三层：UI 层（WinForms 窗体）、数据访问层（一个 DbHelper 类 + 实体类）、业务层（可选）。对于宿舍管理系统，业务逻辑不算复杂，很多人直接把 SQL 写在按钮事件里，也能跑，但后期改起来非常痛苦，尤其是换数据库或加校验时，你会想骂自己。
如果你拿到手的 .rar 里只有一个 Form1.cs 加一堆按钮，我建议你花半小时重构成下面这个结构：
DormitorySystem.sln ├── DormitorySystem.UI # WinForms 项目 │ ├── Forms │ │ ├── LoginForm.cs │ │ ├── MainForm.cs │ │ ├── StudentForm.cs │ │ └── RepairForm.cs │ └── Program.cs ├── DormitorySystem.Data # 类库项目 │ ├── DbHelper.cs │ ├── Models │ │ ├── Student.cs │ │ ├── Dormitory.cs │ │ └── Repair.cs │ └── Repositories │ ├── StudentRepository.cs │ └── DormitoryRepository.cs └── DormitorySystem.slnNuGet 包只装两个：System.Data.SqlClient（连 SQL Server 用）和 Dapper（可选，用来把查询结果映射成对象）。我实际做的时候更喜欢用 Dapper，因为它能把 DataTable 那一堆样板代码压缩掉 60%，而且性能在小型系统里完全不敏感。如果你们学校要求必须手写 ADO.NET，那你就只看下面手写版本，逻辑是一样的。
3.2 用 DbHelper 封装数据库访问：连接字符串与参数化查询
DbHelper 是这个小系统的地基。所有数据库操作都走它，统一管连接字符串、打开关闭连接、参数化查询。下面的代码是基于 ADO.NET 原生写的，不依赖第三方库：
using System; using System.Data; using System.Data.SqlClient; namespace DormitorySystem.Data { public class DbHelper { // 连接字符串统一放 App.config，不要硬编码在代码里 private static readonly string _connStr = System.Configuration.ConfigurationManager.ConnectionStrings["DormitoryDb"].ConnectionString; // 执行增删改，返回受影响行数 public static int ExecuteNonQuery(string sql, SqlParameter[] parameters = null) { using (var conn = new SqlConnection(_connStr)) { conn.Open(); using (var cmd = new SqlCommand(sql, conn)) { if (parameters != null) cmd.Parameters.AddRange(parameters); return cmd.ExecuteNonQuery(); } } } // 执行查询，返回首行首列（用于统计数量） public static object ExecuteScalar(string sql, SqlParameter[] parameters = null) { using (var conn = new SqlConnection(_connStr)) { conn.Open(); using (var cmd = new SqlCommand(sql, conn)) { if (parameters != null) cmd.Parameters.AddRange(parameters); return cmd.ExecuteScalar(); } } } // 执行查询，返回 DataTable（配合 DataGridView 绑定） public static DataTable ExecuteDataTable(string sql, SqlParameter[] parameters = null) { using (var conn = new SqlConnection(_connStr)) { var dt = new DataTable(); using (var cmd = new SqlCommand(sql, conn)) { if (parameters != null) cmd.Parameters.AddRange(parameters); using (var adapter = new SqlDataAdapter(cmd)) { adapter.Fill(dt); } } return dt; } } } }这段代码里最关键的是 using 关键字。SqlConnection 和 SqlCommand 都实现了 IDisposable，用 using 包住可以保证连接用完即关，避免连接池耗尽。很多 C# 初学者的程序跑半天就报「连接池已满」，多半是 new SqlConnection 之后没有 Dispose。
连接字符串放在 App.config 里，这是你拿到 .rar 后第一个要改的位置：
<connectionStrings> <add name="DormitoryDb" connectionString="Server=.\SQLEXPRESS;Database=dormitory_db;User Id=sa;Password=123456;Encrypt=False;TrustServerCertificate=True;" providerName="System.Data.SqlClient" /> </connectionStrings>注意 Encrypt=False 和 TrustServerCertificate=True 这两项。新版 Microsoft.Data.SqlClient 驱动默认开启加密连接，如果你本机 SQL Server 没配证书，不加这两项会直接报证书链错误。这个坑在 2020 年之后出现的频率非常高。
3.3 登录窗体与权限控制：哈希加盐与用户状态
登录功能看起来简单，但我不建议直接用明文密码比对。常见的做法是：注册时把密码用 SHA256 加盐后存进 SysUser 表，登录时取出该用户的 Salt，把输入密码重新哈希后与 PasswordHash 比对。
using System; using System.Security.Cryptography; using System.Text; using System.Data.SqlClient; public static class PasswordHelper { // 生成随机盐 public static string GenerateSalt() { using (var rng = RandomNumberGenerator.Create()) { byte[] bytes = new byte[8]; rng.GetBytes(bytes); return Convert.ToHexString(bytes); } } // 加盐哈希 public static string HashPassword(string password, string salt) { using (var sha = SHA256.Create()) { byte[] data = sha.ComputeHash(Encoding.UTF8.GetBytes(password + salt)); return Convert.ToHexString(data); } } } public static class LoginService { public static bool ValidateLogin(string userName, string password, out string role) { role = null; string sql = "SELECT PasswordHash, Salt, Role FROM SysUser WHERE UserName = @UserName"; using (var conn = new SqlConnection(System.Configuration.ConfigurationManager.ConnectionStrings["DormitoryDb"].ConnectionString)) { conn.Open(); using (var cmd = new SqlCommand(sql, conn)) { cmd.Parameters.AddWithValue("@UserName", userName); using (var reader = cmd.ExecuteReader()) { if (!reader.Read()) return false; string hash = reader["PasswordHash"].ToString(); string salt = reader["Salt"].ToString(); role = reader["Role"].ToString(); return PasswordHelper.HashPassword(password, salt) == hash; } } } } }登录成功后，我一般会在一个静态类 UserSession 里保存当前用户信息，后续窗体通过它判断权限。
public static class UserSession { public static string UserName { get; set; } public static string Role { get; set; } public static bool IsAdmin => Role == "admin"; }主窗体根据 IsAdmin 决定是否显示「用户管理」按钮。权限控制做到菜单级就够了，宿舍管理系统不需要按钮级权限，否则代码复杂度会上升一个量级。
4. 入住、退宿与报修：DataGridView 绑定与增删改查落地
4.1 学生入住登记：事务里同时写入住记录和更新床位状态
入住登记是整个系统里最容易出 bug 的地方，因为一次操作涉及三处数据：Student 表要写当前宿舍和床位、CheckRecord 表要插入一条入住记录、Dormitory 表的 UsedCount 要加一。任何一个步骤失败，数据就对不上了。所以必须放在一个事务里。
用 C# 的 SqlTransaction 实现，核心是同一个连接上先 BeginTransaction，再把事务对象赋给每一个 SqlCommand：
public bool CheckIn(string studentNo, int dormitoryId, int bedNo) { string sqlCheckBed = "SELECT UsedCount, BedCount FROM Dormitory WHERE DormitoryId = @DormitoryId"; string sqlUpdateDorm = "UPDATE Dormitory SET UsedCount = UsedCount + 1 WHERE DormitoryId = @DormitoryId AND UsedCount < BedCount"; string sqlUpdateStudent = "UPDATE Student SET DormitoryId = @DormitoryId, BedNo = @BedNo, Status = 1 WHERE StudentNo = @StudentNo"; string sqlInsertRecord = "INSERT INTO CheckRecord (StudentNo, DormitoryId, BedNo, CheckInDate, Status) VALUES (@StudentNo, @DormitoryId, @BedNo, GETDATE(), 1)"; using (var conn = new SqlConnection(_connStr)) { conn.Open(); using (var tx = conn.BeginTransaction()) { try { // 第一步：检查床位是否可用 using (var cmdCheck = new SqlCommand(sqlCheckBed, conn, tx)) { cmdCheck.Parameters.AddWithValue("@DormitoryId", dormitoryId); using (var reader = cmdCheck.ExecuteReader()) { if (!reader.Read()) throw new Exception("宿舍不存在"); int used = Convert.ToInt32(reader["UsedCount"]); int total = Convert.ToInt32(reader["BedCount"]); if (used >= total) throw new Exception("该宿舍已住满"); } } // 第二步：更新宿舍已住人数，注意更新的 WHERE 条件里带 UsedCount < BedCount 做双重校验 using (var cmdDorm = new SqlCommand(sqlUpdateDorm, conn, tx)) { cmdDorm.Parameters.AddWithValue("@DormitoryId", dormitoryId); if (cmdDorm.ExecuteNonQuery() == 0) throw new Exception("床位已被占用"); } // 第三步：更新学生状态 using (var cmdStudent = new SqlCommand(sqlUpdateStudent, conn, tx)) { cmdStudent.Parameters.AddWithValue("@StudentNo", studentNo); cmdStudent.Parameters.AddWithValue("@DormitoryId", dormitoryId); cmdStudent.Parameters.AddWithValue("@BedNo", bedNo); if (cmdStudent.ExecuteNonQuery() == 0) throw new Exception("学生不存在或已离校"); } // 第四步：插入入住记录 using (var cmdRecord = new SqlCommand(sqlInsertRecord, conn, tx)) { cmdRecord.Parameters.AddWithValue("@StudentNo", studentNo); cmdRecord.Parameters.AddWithValue("@DormitoryId", dormitoryId); cmdRecord.Parameters.AddWithValue("@BedNo", bedNo); cmdRecord.ExecuteNonQuery(); } tx.Commit(); return true; } catch { tx.Rollback(); throw; } } } }这段代码要注意一个逻辑：先 SELECT 检查再 UPDATE 更新。但 SELECT 和 UPDATE 之间如果有另一个用户同时操作，就会出并发问题。所以 UPDATE 语句里带了 UsedCount < BedCount 条件，如果影响行数是 0，说明这个宿舍在你检查之后已经被别人住满了，事务回滚。这是用乐观锁的方式处理床位竞争，比单纯靠 SELECT 的结果判断可靠得多。
4.2 退宿与调宿：先查再改，避免床位数据错乱
退宿和入住是对称操作。退宿时要做的事：CheckRecord 里把当前在住记录的 CheckOutDate 设为当前时间、Status 改为 0；Student 表把 DormitoryId 和 BedNo 置空、Status 改为 0；Dormitory 表 UsedCount 减一。
调宿更特殊，它是「一次退宿 + 一次入住」的组合。常见错误是分开两个事务做，中间如果程序崩溃，学生可能处于「旧宿舍退了、新宿舍没住进」的中间状态。我的做法是把调宿也放进一个事务，先退旧宿舍再进新宿舍：
public bool TransferDorm(string studentNo, int newDormitoryId, int newBedNo) { // 先查出学生当前住的宿舍 string sqlQueryCurrent = "SELECT DormitoryId FROM Student WHERE StudentNo = @StudentNo AND Status = 1"; string sqlCheckOut = "UPDATE CheckRecord SET CheckOutDate = GETDATE(), Status = 0 WHERE StudentNo = @StudentNo AND Status = 1"; string sqlDecDorm = "UPDATE Dormitory SET UsedCount = UsedCount - 1 WHERE DormitoryId = @DormitoryId"; string sqlIncDorm = "UPDATE Dormitory SET UsedCount = UsedCount + 1 WHERE DormitoryId = @DormitoryId AND UsedCount < BedCount"; string sqlUpdateStudent = "UPDATE Student SET DormitoryId = @NewDormitoryId, BedNo = @NewBedNo WHERE StudentNo = @StudentNo"; string sqlInsertRecord = "INSERT INTO CheckRecord (StudentNo, DormitoryId, BedNo, CheckInDate, Status) VALUES (@StudentNo, @NewDormitoryId, @NewBedNo, GETDATE(), 1)"; // 事务写法与 CheckIn 相同，不完整贴出，关键点是所有 SqlCommand 都传入同一个 SqlTransaction 对象 ... }调宿的事务里要特别关注执行顺序：先退旧（Dormitory 减一）再进新（Dormitory 加一）。如果把加一放在减一前面，在极端情况下旧宿舍和新宿舍是同一个时，会把 UsedCount 算错。虽然正常业务不会把学生调到原宿舍，但代码写健壮一点没坏处。
4.3 报修工单列表：DataGridView 数据绑定与刷新
报修功能是宿舍管理系统里最「面向真实使用」的模块，因为宿管员几乎每天都要看「还有几个待处理工单」。界面很简单：一个 DataGridView 显示工单列表，一个按钮把选中的工单标记为已完成。
用 DataGridView 绑定数据最常见的姿势是 DataTable：
private void LoadRepairList() { string sql = @" SELECT r.RepairId, d.BuildingNo + '-' + d.RoomNo AS Room, r.Reporter, r.Phone, r.Description, r.CreateTime, CASE r.Status WHEN 0 THEN N'待处理' WHEN 1 THEN N'处理中' ELSE N'已完成' END AS StatusText FROM Repair r JOIN Dormitory d ON r.DormitoryId = d.DormitoryId ORDER BY r.CreateTime DESC"; DataTable dt = DbHelper.ExecuteDataTable(sql); dgvRepair.DataSource = dt; // 隐藏不友好的列，只保留展示列 dgvRepair.Columns["RepairId"].Visible = false; dgvRepair.Columns["Description"].Width = 250; }这里有个参数设置坑：如果 SELECT 语句里用了别名 StatusText，DataGridView 会自动生成对应列。但如果你原先绑定过其它 DataSource，再次绑定时一定要先置空再赋值，否则界面会残留旧列：
dgvRepair.DataSource = null; dgvRepair.Columns.Clear(); dgvRepair.DataSource = dt;报修工单的列表刷新，我建议用一个 BackgroundWorker 或 async Task 包起来，因为宿管员的机器通常配置不高，如果工单多了，直接在 UI 线程查数据库会让窗体卡死。C# 里最简单的是用 async/await 配合 Task.Run：
private async void btnRefresh_Click(object sender, EventArgs e) { btnRefresh.Enabled = false; try { DataTable dt = await Task.Run(() => DbHelper.ExecuteDataTable(repairSql)); dgvRepair.DataSource = null; dgvRepair.Columns.Clear(); dgvRepair.DataSource = dt; } catch (Exception ex) { MessageBox.Show("加载失败：" + ex.Message); } finally { btnRefresh.Enabled = true; } }如果你拿到手的源码里用的是 C# 老式委托 BackgroundWorker，也别急着重构，它一样能跑。但新项目用 async/await 更简洁，还不会踩 BackgroundWorker 的 RunWorkerCompleted 事件里反复判断 e.Cancelled 的麻烦。报修状态更新本身是单条 UPDATE，不需要事务，直接调用 DbHelper.ExecuteNonQuery 就行。
5. 宿舍管理的避坑清单：连接串、中文乱码、并发改床位
5.1 连接字符串报错：LocalDB 和 SQLExpress 的区分
现象：程序一启动，登录窗体还没弹出来就报「建立到服务器的连接时发生错误」或「找不到指定的 SqlServer 实例」。
原因：连接字符串里写的是 Server=.\SQLEXPRESS，但你的电脑装的是 SQL Server LocalDB，实例名是 (localdb)\MSSQLLocalDB，也可能是开发者版默认实例，直接写 Server=localhost 就能连。这个错误几乎每个人都会遇到一次，因为 .rar 里带的连接串是作者机器上的配置。
解决：先用 SQL Server Management Studio 连一次本机数据库，看实例名到底是什么。或者干脆用代码里最不容易错的写法：Server=localhost;Database=dormitory_db;Integrated Security=True。如果你是 Windows 登录模式，根本不用写用户名密码。如果是混合模式，确认 sa 密码正确且 SQL Server 服务开启了 TCP/IP 协议。
5.2 DataGridView 刷新后看不到新数据：BindingSource 与列缓存
现象：新增一条学生记录后，重新查询并绑定 DataGridView，但界面里看不到新数据，或者出现两套重叠的列。
原因：直接给 DataSource 赋了新的 DataTable，但 DataGridView 的列集合还保留着旧结构，而且如果之前绑过带外键的实体列表，新 DataTable 的列和旧列顺序不一致，数据会错位显示。
解决：绑定前先完全清理旧数据，标准三步是：dgv.DataSource = null; dgv.Columns.Clear(); dgv.DataSource = newDataTable。如果你要在界面上做筛选，用 BindingSource 包一层，这样 TextBox 里输入关键字时只需要设 bSource.Filter = "Name LIKE '%" + keyword + "%'"，不用每次重新查数据库。
5.3 床位并发超卖：只靠代码里 if 判断必翻车
现象：两个宿管员同时在系统里给同一个宿舍安排入住，系统显示已住人数是 2，但实际上安排了 3 个人，宿舍表 UsedCount 变成了 3，但只有 2 个床位。
原因：代码里是先 SELECT UsedCount < BedCount，满足条件再 UPDATE。两个客户端同时完成了 SELECT，都认为有空床，然后都执行 UPDATE，结果就超卖。单独靠 C# 代码里的 if 判断挡不住并发，因为检查与更新之间有时间窗口。
解决：用 UPDATE 语句的条件判断替代代码里的 if，也就是我前面写入住登记时的做法：UPDATE Dormitory SET UsedCount = UsedCount + 1 WHERE DormitoryId = @DormitoryId AND UsedCount < BedCount。如果 ExecuteNonQuery 返回值是 0，说明床位已被抢走，直接回滚并提示。不要把 UPDATE 和 SELECT 的顺序反过来，先 UPDATE 后 SELECT 无法回滚已修改的数据。这个方案不需要 SQL Server 的锁提示，UPDLOCK 太复杂，小型系统用乐观锁足够。
5.4 导出 Excel 报错：不要用 Office COM，用 NPOI
现象：想给宿管员导出「住宿名单.xls」，网上找的代码用了 Microsoft.Office.Interop.Excel，结果用户机器上没装 Office，或者装了 WPS，运行时报「检索 COM 类工厂中 CLSID 为 {00024500-0000-0000-C000-000000000046} 的组件时失败」。
原因：Office COM 方式需要本机安装 Office 且版本兼容，部署时这个问题无解，你不能要求所有宿管员的电脑都装正版 Office。
解决：NuGet 装 NPOI，它是纯托管代码的 Excel 读写库，不依赖 Office。核心代码是把 DataTable 逐行写入 HSSFWorkbook，然后 SaveAs 到文件。注意文件后缀用 .xls 对应 HSSF 格式，用 .xlsx 要换成 XSSFWorkbook，两者 API 略有不同。导出时如果数据量大，放到 BackgroundWorker 里做，避免界面假死。
5.5 中文乱码：排序规则和文件编码双重背锅
现象：SQL Server 里查出来的中文正常，但程序界面上显示问号；或者反过来，程序里正常，写进数据库变成乱码。
原因：两个层面。第一，连接字符串里没加 CharacterSet 相关配置（其实 SQL Server 的 NVARCHAR 不依赖这个），真正常见的是建表时列类型用了 VARCHAR 而不是 NVARCHAR，导致中文按 ASCII 截断。第二，C# 源文件本身编码不是 UTF-8，导致字符串字面量里的中文在编译后变成乱码。
解决：所有存储用户输入的列统一用 NVARCHAR，这是第一原则。第二，在 Visual Studio 里把源码文件另存为 UTF-8 带 BOM 格式，避免中文注释乱码。第三，如果已经乱码，先查数据库里实际存的值：SELECT StudentNo, Name FROM Student。数据库里正常就说明是界面显示问题，检查窗体的 Font 是否支持中文；数据库里就是问号，说明写入时已经错了，只能重新录入。
5.6 部署到别的电脑：SQL Server 版本兼容
现象：在自己电脑上跑得好好的，把发布后的 exe 拷到宿管员电脑上，一启动就报「程序集版本冲突」或「此版本的 SQL Server 不支持」。
原因：目标机器上没有安装对应版本的 SQL Server，或者你用了高级特性（如 STRING_AGG、窗口函数）但目标数据库版本太老。宿舍管理系统基本都是 SQL Server 2012 以上，但宿管办公室的机器可能是很多年前的 SQL Server 2008 R2。
解决：交付前把数据库脚本用低版本兼容语法重写一遍，避免用 STRING_AGG、FORMAT、TRIM 这类新函数。连接字符串里不要写死实例名，部署文档里写清楚数据库服务器地址怎么改。最保险的做法是把数据库文件（.mdf）连同发布 exe 一起打包，附上一键附加数据库的 SQL 脚本：CREATE DATABASE ... FOR ATTACH。
6. 打包 .rar 之前要改好的配置与验证清单
6.1 启动时自动检测数据库并初始化
宿舍管理系统交付后，对方大概率不会用 SSMS 手动执行建库脚本。常见做法是程序启动时先连接一次，如果失败就弹窗提示并自动执行建库 SQL。实现方式是在 Program.cs 的 Main 方法里加一个初始化步骤：
[STAThread] static void Main() { bool dbReady = DatabaseInitializer.CheckOrCreateDatabase(); if (!dbReady) { MessageBox.Show("数据库初始化失败，请检查连接字符串配置或 SQL Server 服务状态。", "系统提示"); return; } Application.EnableVisualStyles(); Application.SetCompatibleTextRenderingDefault(false); Application.Run(new LoginForm()); }DatabaseInitializer 里先尝试打开连接，捕获 SqlException 后执行嵌入的建库脚本。这种做法对宿管员非常友好，他只需要改 App.config 里的服务器地址，其他全自动。但注意，自动建库脚本必须用事务包住，避免执行到一半失败留下残缺表。
6.2 交付前验证清单
我每次交付这类系统都会按固定清单过一遍，避免在客户现场翻车：
- 换一台干净机器，只装 .NET Framework 和 SQL Server Express，跑通登录、入住、退宿、报修全流程。
- 验证日期格式：中文系统下 SQL Server 默认语言可能不同，所有日期字段统一用 DateTime 类型，不要拼字符串。
- 检查 App.config 里有没有写死绝对路径，比如日志文件路径、Excel 导出路径，全部改成相对路径或用户目录。
- 用 NPOI 导出一次住宿名单，确认文件能正常打开。
- 连按两次入住按钮，确认床位不会重复分配。
最后一条特别重要，有些用户会手欠双击按钮，如果你的按钮事件没做防重入处理，就会插入两条重复的入住记录。处理方式很简单：入住成功后刷新列表，把入住按钮的 Enabled 置为 false，直到用户重新选择学生。
6.3 .rar 压缩包里的目录组织
交付给别人的 .rar 压缩包，我建议按这个结构整理：一个「使用说明.docx」放最前面，里面写清数据库实例名、连接串怎么改、默认管理员账号密码；然后是「数据库脚本」文件夹，放建库 SQL 和测试数据 SQL；最后是源码文件夹和发布文件夹分开，不要把 obj/bin 目录里的中间文件也打包进去，那会白白让压缩包膨胀几十兆。
如果给的是源代码交付，记得删掉 .vs 隐藏文件夹和每个项目里的 bin/Debug、obj 目录，只保留 .sln、.csproj、.cs、App.config、SQL 脚本。对方拿到手后直接用 Visual Studio 打开 .sln 就能编译，而不是被一堆编译中间文件干扰。
打包之前，最后用记事本打开一遍 App.config，看连接字符串里的密码是不是测试密码，如果是 sa 弱口令，至少提醒对方上线前改掉。宿舍管理系统虽然不涉及核心资产，但宿管员的电脑通常连着学校内网，能省的事故还是提前省掉。这些细节我踩过太多，现在习惯把验证清单做成一个 md 文件放压缩包根目录，对方照着打勾就行。希望帮到你。
本文还有配套的精品资源，点击获取
