简介：基于C#+MySQL的房屋租赁管理系统是一份面向计算机、软件工程、通信工程等专业学生的课程设计与毕业设计参考项目，核心代码围绕Windows窗体界面、业务逻辑与MySQL数据库交互展开，适合具备一定编程基础、正在完成综合实践任务的大三及以上学习者。压缩包共69个文件，约12.81MB，包含25个C#源文件、11个resources/resx资源文件、SQL建表脚本、ER图与数据流图、Visual Studio解决方案（.sln）以及课程设计报告（docx）等，覆盖数据库表设计、租赁合同管理、租户与房源信息维护等典型模块，并演示了ADO.NET数据操作、数据绑定和异常处理等关键编码手法。已有276人学习浏览，项目附带了MySQL连接驱动安装包、可执行程序与调试文件，便于直接运行验证，也可作为编写设计文档和准备答辩的参考资料。
1. 这套 C# + MySQL 房屋租赁管理系统，到底能帮你解决什么问题
如果手里有几套房或者管过几十套出租房源，你一定体验过那种“房租记在微信里、合同塞在柜子中、押金退没退只能靠翻聊天记录”的恐慌感。房屋租赁管理系统就是专门来治这个病的：它把“房、客、钱、约”四件事收进一个软件里，登录后一眼看清楚哪套房空着、哪个租客该交房租了、哪份合同下个月到期。而 C# 做界面和业务逻辑、MySQL 做数据存储，是这套系统在从业者圈子里最常见、也最容易上手维护的技术组合，没有之一。
这套 .zip 里装的，正是一个基于 Windows 桌面端的房屋租赁管理项目，典型形态是 WinForms（老练、稳定、控件全）或者 WPF（界面更现代），背后挂一个本地或远程的 MySQL 数据库。它能解决“电脑白痴也能点着录入房源”“财务不用对着 Excel 哭”这两类刚需。适合谁？适合 C# 初学者拿来做毕业设计或求职项目，也适合小中介、二房东团队直接改改部署到自己的 Windows 电脑上投入使用。与其看一堆飘在云端的 SaaS 演示视频，不如把这个工程跑起来，你立刻就能知道租务软件到底长什么样。
2. 环境准备与首次启动：拿 C# 把这个项目跑起来，先过这几道坎
2.1 从 .zip 拿到源码后，不要急着双击 .exe，先清点并还原项目结构
很多第一次拿到这种压缩包的人，第一件事是解压后疯狂双击 .sln 或者 .exe，然后被一堆“未能加载文件或程序集”的报错砸懵。实际上，当你解压这套基于 C# + MySQL 的房屋租赁管理系统后，先应该像开箱验货一样，把里面的内容按类别清点一遍。一个标准的 C# 毕业设计/小项目，.zip 里通常包含这些部分：
房屋租赁管理系统/ │ HouseRental.sln // 解决方案文件，VS 双击入口 │ HouseRental.suo // VS 用户配置（可选，有时不在包里） │ ├─ HouseRental/ // 主项目目录（WinForms 或 WPF 工程） │ │ HouseRental.csproj // 工程文件，里面标了.Net版本 │ │ App.config // 配置文件，MySQL 连接串基本在这 │ │ │ ├─ Forms/ // 窗体：登录、主窗体、房源管理、租客管理、合同管理、账单 │ ├─ Models/ // 实体类：House.cs、Tenant.cs、Contract.cs、Bill.cs │ ├─ DAL/ // 数据访问层，几乎全是 SqlHelper / MySqlHelper │ └─ Utils/ // 工具类：验证、日期计算、导出Excel等 │ │ └─ database/ └─ house_rental.sql // 数据库脚本，MySQL 中一键导入这里的核心顺序是：先找 .sql 脚本，再找 App.config（或 app.config），最后才是打开 .sln。为什么？因为这套系统的业务逻辑跑得再好，只要 MySQL 里没有对应的数据库和表，登录窗口输入什么账号密码都会撞上“连接数据库失败”的硬墙。你在 VS 里按 F5 之前，要把房子的地基打好——数据库必须先建出来。
至于用什么版本的工具链，我的建议非常朴素：如果你的 .zip 内工程是 .NET Framework 4.5 或 4.7.2（看 csproj 里的 TargetFrameworkVersion），那么请安装 Visual Studio 2019 或 2022 社区版，安装时勾选“.NET 桌面开发”工作负载。除非工程明确写着 .NET 6/8，否则你不需要装最新的 .NET SDK，装了反而可能遇到“目标框架不匹配”的玄学问题。注意，不要用 VS Code 打开 .sln 硬编 WinForms，等你把项目结构、设计器文件、资源文件全部手动配齐，天都亮了。
2.2 MySQL 侧的准备：5.7 vs 8.0 怎么选，导入 house_rental.sql 的正确姿势
既然标题把 MySQL 挂在 C# 后面，数据库这边往往才是最坑人的环节。这套房屋租赁系统查询下载到的多数是老工程，SQL 脚本大多按 MySQL 5.7 的语法写的（比如ENGINE=InnoDB DEFAULT CHARSET=utf8，甚至可能有TYPE=InnoDB这种古董写法）。如果机器上已经装了 MySQL 8.0，导入时大概率会遇到Unknown storage engine或者 utf8 字符集相关告警，但一般不影响建表。不过，为了少踩坑，我会优先建议你装MySQL 5.7.44或者 8.0 都行，但确认一件事：mysql-connector 的版本，后面细说。
MySQL 安装完成后，用命令行或者 Navicat 做下面三件事。第一，建立一个专用数据库用户，不建议用 root 直连系统，因为 C# 的连接串要存明文密码，root 权限太大，万一这台机器要给别人演示或交接，root 泄露等于把整个 MySQL 送人。第二，把house_rental.sql导入进来。命令行导入的写法最稳：
mysql -u root -p -e "CREATE DATABASE IF NOT EXISTS house_rental DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;" mysql -u root -p house_rental < database/house_rental.sql这段命令的逻辑是：先用-e方式执行建库语句，显式指定utf8mb4字符集和排序规则；然后用输入重定向把 .sql 脚本喂给house_rental库。为什么不直接source？更建议：mysql -u root -p进入交互界面后执行USE house_rental;再source database/house_rental.sql。原因在于，很多 .sql 脚本里没有CREATE DATABASE语句，你直接重定向到不存在的库，会得到一堆No database selected的报错，别问我是怎么知道的。
导入成功后，用SHOW TABLES;验证一下。正常的房屋租赁系统至少会有这四张核心表：house_info（房源表）、tenant_info（租客表）、contract_info（合同表）、payment_record（收款记录表）。有些系统还会带user_info（操作用户表）、house_type（房型字典表）等。如果SHOW TABLES的结果只有零星几张，甚至报脚本语法错误，请打开 .sql 文件看前三行注释，确定它到底是 MySQL 5.x 还是 MariaDB 的导出产物，再对症处理。
2.3 修改连接字符串并成功登录：从 App.config 到 MySql.Data.dll
数据库备好后，回到 C# 工程的核心配置——连接字符串。大多数这类项目会提供一个登录窗体，里面的“服务器地址”“用户名”“密码”可能是硬编码在代码里的，也可能写在App.config的connectionStrings节点里。我更推荐你用后者的实现，这也是多数从业者的做法。如果压缩包里的代码写死了，你可以自己加一个配置文件段，一劳永逸。下面这段是 WinForms 项目里最标准的写法：
<connectionStrings> <add name="HouseRentalDb" connectionString="Server=127.0.0.1;Port=3306;Database=house_rental;Uid=rental_user;Pwd=your_password;CharSet=utf8mb4;SslMode=None;Allow User Variables=True;" providerName="MySql.Data.MySqlClient" /> </connectionStrings>参数说明：Server是 MySQL 所在机器的 IP。本机调试填127.0.0.1或localhost都可以，但要注意如果 MySQL 服务端配置了skip-name-resolve，用localhost反而可能解析异常，此时用127.0.0.1更稳；Port默认 3306，除非你自定义过；Database必须和导入的库名完全一致；Uid和Pwd对应“专用数据库用户”那一步创建的账号密码；CharSet=utf8mb4是为了让中文写入读取不乱码；SslMode=None是经典小坑——用 MySQL 8.0 连接器连接新版 MySQL 时默认要 SSL，而本地开发服务器常常没配证书，不设 None 会直接抛“SSL Connection Error”。Allow User Variables=True是为了防止某些系统用到SET @var这类用户变量存储过程时被连接器拦截。
改完配置文件，先别急着点登录。请确认你的项目引用里存在MySql.Data.dll。如果没有，最常见的方法是打开“解决方案资源管理器” -> 右键项目 -> “管理 NuGet 程序包” -> 搜索MySql.Data并安装。需要注意版本选择：如果 MySQL 是 5.7，用MySql.Data8.0.x 也兼容，但有时会有“Authentication method 'caching_sha2_password' not supported”的报错（这通常是 MySQL 8.0 的默认认证插件导致）。解决方法是登录 MySQL 后执行：
ALTER USER 'rental_user'@'localhost' IDENTIFIED WITH mysql_native_password BY 'your_password'; FLUSH PRIVILEGES;这条 SQL 的意思很直白：把用户的认证插件改回mysql_native_password，C# 连过去才不闹脾气。如果是 MySQL 5.7 则不存在这个问题，因为老版本默认就是原生密码认证。至此，启动程序，输入脚本里内置的管理员账号（常见的是 admin / 123456，也有的在user_info表里直接能查到），如果顺利进入主界面，地基就算打完了。
3. 数据库表设计拆解：房源、租客、合同、账单这四张表是怎么串成一条业务链的
3.1 从 ER 关系到实际建表语句：为什么合同表是所有业务的粘合剂
搞定了环境，我们要把目光拉回房屋租赁管理系统最值钱的部分——数据库表结构。很多新手拿到 .zip 之后，只顾着把代码跑起来，却从不看 SQL 脚本，结果面试时被问“这个系统的表怎么设计的”直接卡壳。实际上，这种从业者积累下来的系统能跑得稳，靠的就是表之间的关系设计得顺。典型的表结构关系是：一栋房（房源表）可对应多份历史租约（合同表），一份合同对应一个客户（租客表），一份合同又产生多条收租记录（账单/收款表）。而合同表就是穿起整条业务线的“绳子”。
以一张简化的contract_info表为例，它通常会包含contract_id、house_id（外键指向房源表）、tenant_id（外键指向租客表）、start_date、end_date、monthly_rent、deposit、status等字段。写建表语句时，最考验功底的是设计status字段：它是一个 TINYINT 类型，0 表示“履行中”，1 表示“已到期”，2 表示“已退租”。为什么不直接删除记录？因为你要算历史、要追溯押金退还，物理删除记录等于毁掉审计链路，属于给自己埋雷。
连接表关系时，不要试图在 C# 代码里写一堆复杂的 JOIN 来替代合理的外键。虽然 MySQL 的 InnoDB 引擎支持外键约束，但此类管理系统在早期开发阶段往往没有真正启用外键（因为插入数据时要严控顺序，开发量增大），更大的可能性是只在逻辑层做关联——也就是 DAL 层写 SQL JOIN 查询。所以你在读表的脚本时，如果看到KEY idx_house_id (house_id)这种普通索引而非CONSTRAINT fk_xxx FOREIGN KEY，请不要惊讶，这是该场景下业界的“快速迭代”习惯，谨慎但真实。
3.2 租金计算与逾期标记：用一条 SQL 算清楚“谁该交钱、谁已欠租”
理解表结构之后，你最该关心的一个业务场景是“租金账单是怎么自动生成的”。房屋租赁系统的核心价值就在这里。绝大多数系统的做法是：租房合同签订时（或每月月初），由程序根据contract_info里的monthly_rent和start_date在payment_record表里生成应收记录。这套系统里未必有定时任务去自动生成，但一定有个“生成账单”按钮，背后逻辑是启发式的——查询所有status = 0（履行中）和status = 1（已到期但未结清）的合同，然后为每个合同补生成从上一期账单日期到当前日期之间缺失的月份账单。
具体到 SQL，你可以用一条 GROUP BY 定位欠租房客：
SELECT c.contract_id, t.tenant_name, h.house_name, SUM(CASE WHEN p.pay_status = 0 THEN p.amount ELSE 0 END) AS unpaid_amount FROM contract_info c LEFT JOIN tenant_info t ON c.tenant_id = t.tenant_id LEFT JOIN house_info h ON c.house_id = h.house_id LEFT JOIN payment_record p ON c.contract_id = p.contract_id WHERE c.status = 0 GROUP BY c.contract_id, t.tenant_name, h.house_name HAVING unpaid_amount > 0 ORDER BY unpaid_amount DESC;这段 SQL 的逻辑说明：先把合同、租客、房源、收款记录四张表串起来，LEFT JOIN保证即使某合同还没有任何收款记录，也能显示在报表里；然后通过SUM(CASE...)把未支付（pay_status = 0）的金额加总；HAVING unpaid_amount > 0过滤出真正欠钱的；最后按欠款金额倒序排列，让财务打开报表一眼看到最大“老赖”。在 C# 侧，你只需把这段 SQL 交给MySqlCommand执行并填充到DataGridView即可，无需逐条循环计算。这正是这套系统把 MySQL 当持久层用的精髓：能交给数据库算的聚合操作，不要拿 C# 的 for 循环去做。
3.3 退租与押金结算：为什么说改数据状态比删数据更安全
系统跑起来之后，还有一个必然要做的高频操作——退租。这个操作要是写成“从合同表 DELETE 掉记录”，那这家公司的财务账三个月必乱。标准做法是“状态流转”：把contract_info.status从 0 改为 2，同时把house_info.house_status从“已租”（1）改为“空置”（0），再在payment_record中生成一条押金退还或抵扣的记录。这一套动作在一个事务里完成，SQL 大致长这样：
START TRANSACTION; UPDATE contract_info SET status = 2, end_date = NOW() WHERE contract_id = 15; UPDATE house_info SET house_status = 0, current_tenant_id = NULL WHERE house_id = 8; INSERT INTO payment_record (contract_id, amount, pay_status, create_time, remark) VALUES (15, -2000.00, 1, NOW(), '退租押金退还'); COMMIT;参数说明与注意点：负金额代表退款，这样到月底统计“实收总额”时，两条 SQL 相减即可。pay_status = 1表示这笔退款已经结清/已支付。一定要三条语句用一个START TRANSACTION包住，任何一环失败就ROLLBACK，否则会出现“房子退了，合同还在履行中”的状态错乱。这是我不想再次翻车的血泪教训，写在这里供你参考。
4. 核心功能代码实现：把业务界面和 C# 后台串起来的那些关键写法
4.1 登录窗体的防 SQL 注入写法：从拼接字符串到参数化查询的转变
房屋租赁系统的登录窗体看着不起眼，却是整个系统安全的第一道闸门。很多从网上下载的老代码，喜欢这么写登录判断：
string sql = "SELECT * FROM user_info WHERE user_name = '" + txtUser.Text + "' AND password = '" + txtPwd.Text + "'"; MySqlCommand cmd = new MySqlCommand(sql, conn);如果你拿到的源码里是这样，劝你立刻改成参数化查询。因为这种写法一旦遇上txtUser.Text输入' OR '1'='1，密码随便填，WHERE条件永远为真，整个后台就被脱裤子了。租房系统里全是客户姓名、手机号、身份证号，泄露一次就够你喝一壶。改造后的写法业界通用，如下：
string sql = "SELECT * FROM user_info WHERE user_name = @username AND password = @password"; using (MySqlCommand cmd = new MySqlCommand(sql, conn)) { cmd.Parameters.AddWithValue("@username", txtUser.Text.Trim()); cmd.Parameters.AddWithValue("@password", txtPwd.Text.Trim()); // 如果系统里是MD5加密，在这里传入hash值 using (MySqlDataReader reader = cmd.ExecuteReader()) { if (reader.Read()) { // 登录成功：记录当前用户ID，打开主窗体 this.Hide(); MainForm mainForm = new MainForm(reader["user_id"].ToString()); mainForm.Show(); } else { MessageBox.Show("用户名或密码错误"); } } }逻辑说明：@username和@password是强类型占位符，MySQL 驱动会把传入值当纯文本处理，输入的任何 SQL 片段都会失去执行能力。这是 C# 连 MySQL 时的基本素养，也是这套系统最值得你动手重构的地方。参数说明：Trim()去掉首尾空格，避免用户手滑多敲一个空格导致“明明账号正确却登不进去”的尴尬；密码是否加密取决于原系统实现，如果user_info表里存的是 32 位大写 MD5，你就得先用MD5.Create()加密再比对，而不是存明文。
4.2 房源管理的增删改查：DataGridView 与数据源绑定的取舍
登录后进入主窗体，最核心的操作区是“房源管理”。“新增房源”“修改房租”“标记空置/已租”这些动作，本质上是对house_info表一行记录的增删改查。多数此类系统的实现方式是：左边是房源分类树或搜索框，右边是一个DataGridView表格。一个小技巧：当你把DataTable赋给DataGridView.DataSource后，用户直接在表格里改了单元格，并不等于数据库已经更新，你需要在“保存”按钮里把改动批量写回 MySQL。新手常在这里犯迷糊，以为界面上改了就完事，然后一刷新数据全没了。
批量保存的常见做法是循环DataTable中被修改的行（RowState = Modified），逐条执行 UPDATE。虽然性能不算极致，但对于一栋楼几十套房完全足够：
private void SaveHouseChanges(DataTable dt) { string sql = @"UPDATE house_info SET house_name=@house_name, house_price=@house_price, house_status=@house_status, house_remark=@house_remark WHERE house_id=@house_id"; using (MySqlConnection conn = new MySqlConnection(connectionString)) { conn.Open(); foreach (DataRow row in dt.Rows) { if (row.RowState == DataRowState.Modified) { using (MySqlCommand cmd = new MySqlCommand(sql, conn)) { cmd.Parameters.AddWithValue("@house_name", row["house_name"]); cmd.Parameters.AddWithValue("@house_price", row["house_price"]); cmd.Parameters.AddWithValue("@house_status", row["house_status"]); cmd.Parameters.AddWithValue("@house_remark", row["house_remark"]); cmd.Parameters.AddWithValue("@house_id", row["house_id"]); cmd.ExecuteNonQuery(); } } } } // 逐条提交之后，统一刷新DataGridView。注意：如果数量上百，建议改用事务 }这段代码的逻辑说明：先打开一个连接，然后遍历DataTable中被改动过的行，逐行执行带参数化条件的 UPDATE。参数说明：RowState是 ADO.NET 的“行状态机”，只有用户真的改过某个单元格，状态才是Modified，否则跳过，这样避免无意义的网络往返。事务的问题我在这里提一嘴：如果房源数量超过 200 条，建议把循环包进事务，出错了能整体回滚，不然改到一半报错，数据库里一半新数据一半旧数据，那可真是给运维喂救心丸了。
4.3 合同管理中的“自动计算到期日”：DateTime 运算与 MySQL 日期函数的配合
合同管理模块的“签订合同”功能，是租务系统里最容易算错的地方。你要跟租客签一年合同，起始日是2024-03-15，终止日到底是2025-03-14还是2025-03-15？如果只存一个end_date，后面退租结算、到期提醒全靠它，算错了影响一堆下游逻辑。稳妥做法是：界面让用户选起始日期和租期（比如 12 个月），C# 用AddMonths计算到期日，然后作为参数传到 SQL 里。同时，在 C# 侧做一次验证，防止租期选成负数或超长。
DateTime startDate = dtpStartDate.Value.Date; int months = Convert.ToInt32(cmbDuration.SelectedItem); // 从下拉框拿到 6 / 12 / 24 DateTime endDate = startDate.AddMonths(months).AddDays(-1); string sql = @"INSERT INTO contract_info (house_id, tenant_id, start_date, end_date, monthly_rent, deposit, status, create_time) VALUES (@house_id, @tenant_id, @start_date, @end_date, @monthly_rent, @deposit, 0, NOW())"; using (MySqlCommand cmd = new MySqlCommand(sql, conn)) { cmd.Parameters.AddWithValue("@house_id", selectedHouseId); cmd.Parameters.AddWithValue("@tenant_id", selectedTenantId); cmd.Parameters.AddWithValue("@start_date", startDate); cmd.Parameters.AddWithValue("@end_date", endDate); cmd.Parameters.AddWithValue("@monthly_rent", txtRent.Text.Trim()); cmd.Parameters.AddWithValue("@deposit", txtDeposit.Text.Trim()); cmd.ExecuteNonQuery(); }这里的关键点：AddMonths(months).AddDays(-1)表达的是“租一年，最后一天是 12 个月后的前一天”，符合中文租赁习惯中“租到明年今天前一天”的口径。参数说明：monthly_rent虽然看起来像数字，但用字符串传参也可以，MySQL 会做隐式转换，前提是你前端控件里做了输入校验（decimal.TryParse判空），否则用户填个“abc”进来，程序会在数据库执行阶段才报错，处理成本更高。节点提醒一句：房屋租赁管理系统里的日期计算，永远怀有“边界日”戒心，比如 2 月 29 日签一年合同，AddMonths会自动溢出到 2 月 28 日，这是 .NET 的规则，你要么接受，要么在文档里写清楚，不要让它变成“黑匣子”。
5. 必踩的五个坑与排查手册：从运行时崩溃到数据错乱的血泪经验
5.1 现象：登录时报MySql.Data.MySqlClient.MySqlException: Authentication method 'caching_sha2_password' not supported
原因：这个坑发生得最多，尤其当你的 MySQL 8.0 服务器默认认证插件是caching_sha2_password，而项目引用的MySql.Data版本较老（6.x 或 7.x），它无法识别这种新式密码哈希。C# 一连接到主机，握手就失败，程序连登录窗都过不去。
解决：两个方向二选一。要么升级MySql.DataNuGet 包到 8.0.33 以上，让驱动支持新插件；要么在 MySQL 里把用户认证插件改回mysql_native_password（执行的 SQL 见第 2.3 节）。我个人的偏好是两种都做：升级一遍兜底，数据库用户也改回原密码方式，彻底跟驱动版本说拜拜。此坑之后，“SSL 连接错误”的坑也可能顺带出现，按下面一条一起处理。
5.2 现象：程序运行正常，但登录后主界面所有中文都变成???问号
原因：字符集错乱。大概率是数据库连接串没带CharSet=utf8mb4，或者建库时用了latin1。C# 端写入中文 → MySQL 端无法识别 → 输出时来回转码，最后全成了问号。
解决：三步走。第一步，连接字符串加CharSet=utf8mb4；第二步，检查数据库和表的默认字符集，统一执行ALTER DATABASE house_rental CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;以及ALTER TABLE ... CONVERT TO CHARACTER SET utf8mb4;；第三步，如果 .sql 脚本在建表语句里指定了DEFAULT CHARSET=latin1，老实打开脚本全局替换掉，再重新导入。这类问题不是代码逻辑 bug，属环境错配，排查时不要疯狂断点，先查库的元数据。
5.3 现象：新增房源时报Incorrect string value: '\xE6\x88\xBF...' for column
原因：这条和 5.2 类似，但更具体——表的字段字符集落后于连接串。连接串已经告诉 MySQL“我发 utf8mb4 给你”，但某张表的某个字段还是utf8甚至latin1，存不进去。
解决：单表修复时执行ALTER TABLE house_info MODIFY house_name VARCHAR(100) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;。如果一张表里多个字段都有问题，用ALTER TABLE house_info CONVERT TO CHARACTER SET utf8mb4;一把梭更彻底。这套系统是中文业务，所有 varchar/text 字段都该是 utf8mb4，没有什么例外；如果有字段存的是表情符号，更只有 utf8mb4 能接得住。
5.4 现象：同一套程序，在开发电脑上跑得好好的，拷到客户机器上连不上数据库
原因：连接配置里的Server是本机 IP127.0.0.1，但部署到客户现场时数据库在另一台机器（或者客户机器上 MySQL 服务端口被防火墙拦了）。这是 C/S 架构最经典的部署坑，不是代码问题。
解决：把连接字符串的Server改成目标数据库机器的局域网 IP，并用命令行测试端口连通性：telnet 192.168.1.100 3306。另外，MySQL 服务端需要确认bind-address没被设置为只允许本机（/etc/mysql/mysql.conf.d/mysqld.cnf中bind-address = 127.0.0.1需要注释掉或改成0.0.0.0），并创建授权用户时用'rental_user'@'%'而不是'localhost'。很多人在这一步直接心态崩溃，以为是程序 Bug，其实用telnet探一下端口就真相大白了。
5.5 现象：退租后重新出租，租客列表和房源表的状态数据出现“魂淡”式错乱
原因：退租/出租操作没有包事务，或者代码里是先改了房源状态、后插入合同，结果第二步抛异常了，第一步没有回滚。最终房子显示“已租”但没有有效合同；或者合同显示“履行中”，房子却是“空置”。这是 “状态不一致”的典型表现，追溯起来极耗精力。
解决：退租与新房客入住，这两组操作必须在同一个TransactionScope或MySqlTransaction中执行。在前面的 3.3 章节里已经给出过事务 SQL。C# 侧写法就是using (var transaction = conn.BeginTransaction()) { ... transaction.Commit(); }，里面任何一条 SQL 失败就transaction.Rollback()。房屋租赁系统最怕数据前后对不上，这个坑值得在代码审查时瞪大眼睛找。
6. 这套房屋租赁系统的进阶改造与交付验证技巧
当核心功能跑通之后，真正让这个项目“值钱”的功夫在打磨阶段。下面三个方向的改造，是我验证过最有性价比的加分项。第一，把账单的“逾期未付”字体用红色高亮显示，并在主窗体加载时自动查询一遍payment_record里pay_status = 0且due_date < CURDATE()的记录，做个弹窗提醒。不要觉得这是小事，对一个收租系统来说，能提醒“谁该交租了”比华丽的图表有用十倍。第二，给系统补一个“数据备份”按钮，底层用MySqlCommand执行BACKUP DATABASE house_rental TO '...'，或者更简单的方法——通过Process.Start调用mysqldump命令。每月备份一次，是应对机器崩溃的后悔药。第三，如果压缩包里的界面是用 WinForms 写的，你可以考虑在同套数据库不变的情况下，把前端升级成 WPF 版的ListView或DataGrid，因为 WPF 对自定义样式和 MVVM 的支持更好，面试时讲起来也更有亮点。
在交付或者验收之前，给你一套自己可以照着做的验证清单。第一，用不同的角色账号登录（管理员和普通操作员），看权限控制是否真的生效，输入错误密码三次会不会被锁定，这关系到系统在真实场景下的可用性。第二，造一笔压测数据：往house_info表里插入 300 套房源、tenant_info插入 500 个租客、payment_record插入 5000 条流水，然后打开财务报表页，看查询耗时是否还在可接受范围（3 秒内为佳）。如果明显卡顿，优先给payment_record表的contract_id和pay_status建联合索引。第三，把 Windows 系统时间改到下个月 1 号，重启程序，确认“到期提醒”和“账单生成”功能是否按预期触发。如果日期逻辑写死成DateTime.Now，它一定会跑偏，所以这个测试很有必要。
最后一个忠告来自我的个人习惯：永远在代码里保留一句“数据修复”入口，它不需要出现在界面上，只要你留一个命令行参数（比如HouseRental.exe --repair-payment-status），专门执行一段“状态对账”SQL：把所有status = 0的合同和house_info.house_status比对，把不一致的标记出来。生产环境出问题的时候，这段隐藏代码能帮你省下很多尴尬。这就是打包交付时很多工程师容易忽略的“后门”，它不是用来做坏事，而是给自己留一条避险通道。希望这些跳过的坑和实操思路，能让你少走我当初走过的弯路。祝你早日把 .zip 里的代码变成一套跑得稳、算得准的租务管理系统。
本文还有配套的精品资源，点击获取
