简介：一套基于C#与Windows窗体（Winform）开发的外卖订餐系统源码及数据库配套包，适合正在完成课程设计或毕业设计的初学者。项目包含用户注册登录、菜单管理、订单处理、后台管理等典型业务模块，并预置admin管理员账号，能够完整演示从下单、支付到状态跟踪的闭环流程。压缩包共68个文件，以cs源码、resx与resources界面资源、jpg界面截图和exe可执行程序为主，另含mdf/ldf数据库文件、pdb调试符号、sln工程文件以及部署说明txt，整体大小仅1.26MB，目录结构清晰便于快速定位。数据库连接字符串位于load.cs中，需先附加DB目录下的test1.mdf文件，再按实际环境修改连接配置即可运行。通过研究该项目，可以系统接触Winform控件布局与事件驱动、ADO.NET数据访问、SQL Server数据库管理、以及基本权限控制等实用技术；已有1294人学习下载，适合作为C#桌面应用开发入门后的综合练手项目，也适合作为毕业设计的参考资料。
1. 从解压到跑通：这份 C# 外卖订餐系统源码包里到底藏着什么
拿到《基于 C# 的外卖订餐系统（源码+数据库）.zip》时，我习惯先看压缩包里有什么，再决定从哪下手。解压出来是 Winform 工程、一个load.cs、一套 SQL Server 数据库文件（test1.mdf 和 test1rz.ldf），外加部署须知。这说明它不是纯静态页面，而是一个跑在 Windows 桌面上的 C/S 业务系统：前台点餐、后台管理、订单流转都在同一个 C# 程序里完成。对正在做课程设计的人，它最值钱的部分不是界面长什么样，而是从数据库表到界面控件的完整调用链；对刚学 C# 的人，也能从里面看到 ADO.NET 参数化查询和事务是怎么落地的。接下来就按我实际复现的顺序，把文件结构、数据库附加、连接字符串、订单业务和典型坑逐层拆开。
2. 源码结构和数据库文件：附加 .mdf 之前需要知道的四件事
先别急着打开解决方案。压缩包里的每个文件都有它存在的理由，搞清楚之后，后面排错时你能直接判断是"数据库没附加"还是"代码引用了错误路径"。
2.1 解决方案里每个文件是干什么的：从 .sln 到 load.cs 的一次清点
把压缩包展开，标准的文件构成是下表这样：
| 文件 / 目录 | 作用 | 能不能动 |
|---|---|---|
| 外卖订餐系统.sln | 解决方案入口，双击后用 Visual Studio 打开 | 不要改 |
| 外卖订餐系统.suo | 记录上次编辑器窗口布局的二进制文件 | 可以删 |
| 外卖订餐系统-Winform | 主工程目录，窗体与逻辑代码都在这里 | 主要改这里 |
| load.cs | 数据库连接字符串所在地 | 必改 |
| DB\test1.mdf | SQL Server 主数据文件 | 附加时用 |
| DB\test1rz.ldf | SQL Server 事务日志文件 | 附加时用 |
| 部署须知.txt | 作者写的运行顺序 | 先读它 |
.sln决定解决方案里包含哪些项目，.suo只负责编辑器状态。很多人遇到"项目打不开""打开后布局全乱"的问题，最后手段就是删掉.suo让它重新生成，这对编译没有任何影响。它不是源码的一部分，但放在压缩包里很容易让人误以为工程文件损坏了。
load.cs被单独放在外层，这个命名在课程设计里很常见：整个程序的所有数据库操作都从这个类里读取连接字符串。它的职责单一，就是提供连接配置。改连接的时候只需要搜connectionString关键字，把它作为唯一修改点，而不是在每个窗体里到处找。
数据库文件成对出现是有原因的。.mdf是主数据文件，.ldf是日志文件，SQL Server 在附加时会把两者做一致性校验，只看.mdf判断不了这个库完整不完整。所以单独拿一个.mdf去附加必失败，这也是后面最常见的错误之一。
2.2 load.cs 里那行连接字符串：每个参数都改给谁看
打开load.cs，你看到的基本是两种形态之一：
private string connectionString = "Server=.;Database=test1;Integrated Security=True;";或：
private string connectionString = "Server=localhost\\SQLEXPRESS;Database=test1;User ID=sa;Password=123456;";第一行的Server=.表示连接本机默认实例；第二行的localhost\SQLEXPRESS表示本机上的 SQL Server Express 命名实例。两者指向的是完全不同的引擎，装的是 Express 版却在连接串里写.，SQL Server 会直接拒绝连接。改成实例名后通常就能通，前提是你的 Express 服务确实叫SQLEXPRESS。
Database=test1要和附加后的数据库名保持一致。注意库名不一定等于 mdf 文件名：如果本机已经存在一个 test1，SSMS 附加时会要求你重建名或直接失败，这时候连接串里的Database就改成实际库名。经常有人在这上面翻车，程序一直提示找不到数据库，最后发现附加时被系统自动加了个_new后缀。
Integrated Security=True表示用 Windows 身份验证，不需要用户名密码；如果需要用 SQL Server 身份验证登录，就改成User ID=sa;Password=xxx。这两种模式在部署到别的机器上时差异很大，第 5 章专门有一条讲这个。
改完连接串，先别急着跑程序。在 Visual Studio 的服务器资源管理器里新建连接，填同样的配置点"测试连接"，如果这里都不通，说明问题在数据库服务或网络，而不是你的业务代码。这一步能省掉一半的盲目排错。
2.3 在 SQL Server 里附加 test1.mdf 的正确操作
图形化操作路径：SSMS 里右键"数据库"节点 → 附加 → 添加 → 选中 DB 目录下的 test1.mdf。如果弹出"已存在文件"，说明同名数据库已经附加过了，要么删掉旧的，要么用命令行方式改名字附加。
命令行方式对应的是CREATE DATABASE FOR ATTACH：
CREATE DATABASE [test1] ON (FILENAME = N'D:\OrderSystem\DB\test1.mdf'), (FILENAME = N'D:\OrderSystem\DB\test1rz.ldf') FOR ATTACH;FILENAME必须写绝对路径。这里有个高频坑：路径里有中文目录名时，SQL Server 经常报"无法打开物理文件"。原因主要是文件访问权限和默认排序规则对非 ASCII 路径处理得不稳定。
最简单的方式是把整个工程目录挪到纯英文路径，比如D:\OrderSystem下，然后再附加。如果日志文件名和 mdf 内部记录不一致，附加时报 LOG 文件不匹配，常见做法是改用FOR ATTACH_REBUILD_LOG重建日志文件：
CREATE DATABASE [test1] ON (FILENAME = N'D:\OrderSystem\DB\test1.mdf') FOR ATTACH_REBUILD_LOG;这个命令会自动生成一个新的 ldf，副作用是原日志里的事务记录不保留。对课程设计来说几乎没有影响，唯一要考虑的是：如果这个库之前被做过时间点恢复，重建日志后历史备份链会断。实际使用中这种场景很少，直接跑这个命令是最快的路。
2.4 admin 账户在数据库里是怎么存的：权限控制的基本盘
系统预设管理员 admin，说明用户表是存在的。课程设计里常见结构如下：
| 字段 | 类型 | 说明 |
|---|---|---|
| UserId | int 自增 | 主键 |
| UserName | nvarchar(50) | 登录名，admin 在这里 |
| Password | nvarchar(50) | 密码，可能明文也可能哈希 |
| Role | int | 0 管理员，1 普通用户 |
登录验证的 C# 写法，常见是参数化查询取回角色字段：
public int Login(string userName, string password) { string sql = "SELECT Role FROM Users WHERE UserName=@name AND Password=@pwd"; using (SqlConnection conn = new SqlConnection(connectionString)) using (SqlCommand cmd = new SqlCommand(sql, conn)) { cmd.Parameters.AddWithValue("@name", userName); cmd.Parameters.AddWithValue("@pwd", password); conn.Open(); object result = cmd.ExecuteScalar(); return result == null ? -1 : Convert.ToInt32(result); } }ExecuteScalar返回第一行第一列，正好对应 Role 字段。查不到用户就返回 null，方法返回 -1 表示登录失败。参数化在这里同时解决两个问题：防注入和避免拼字符串时的语法错误——如果密码里碰巧有单引号，拼接写法当场崩溃，参数化完全不受影响。
这章四件事全部过完，健康的运行状态是：SSMS 里能看到 test1 库，load.cs 里的连接串能通过测试连接，用 admin 能登进去。三件事都成立，再进入业务层拆解。
3. 把订单业务跑通：菜品、订单明细与 ADO.NET 事务写入
数据库附加成功只是开始。外卖系统的核心在于订单怎么写进库、状态怎么流转。理解这部分，才能真正把这套源码当成自己的项目去讲。
3.1 菜品、订单、订单明细的数据结构
外卖系统至少有三张核心表：Dishes、Orders、OrderItems。它们的关系可以概括为一对多：一个用户可以下多张订单，一张订单包含多条明细。
| 表 | 核心字段 | 定位 |
|---|---|---|
| Dishes | DishId, Name, Price, Category | 菜品目录 |
| Orders | OrderId, UserId, Status, TotalAmt, OrderTime | 订单主表 |
| OrderItems | ItemId, OrderId, DishId, Quantity, Price | 订单明细 |
明细表里的 Price 和菜品表的 Price 是两回事。下单那一刻，必须把菜品价格快照到 OrderItems.Price 里，而不是在报表时再去连表查 Dishes.Price。如果菜价后来涨了，历史订单的金额还是应该按购买时计算，这是业务系统的常见约定。很多初学者把明细表做成只存 DishId + Quantity，一旦菜单价格变动，旧订单的金额就全乱了。
外键关系上，OrderItems.OrderId 引用 Orders.OrderId，OrderItems.DishId 引用 Dishes.DishId。有外键的好处是数据库帮你挡住了"删除正在被订单引用的菜品"这类操作；没外键也能跑，但会留下脏数据。
在 SQL Server 里查看这三张表的做法：展开数据库 → 表，右键表 → 选择"编辑前 200 行"。如果表结构和上面不一致，比如字段名是 MealName 而不是 Name，后续代码里所有列名都要跟着调整。
3.2 ADO.NET 参数化写入：下订单的代码骨架
下单操作涉及两张表：Orders 插一条汇总，OrderItems 插入每道菜。两张表要么一起成功，要么一起回滚，所以必须用事务包住：
using (SqlConnection conn = new SqlConnection(connectionString)) { conn.Open(); SqlTransaction tx = conn.BeginTransaction(); try { SqlCommand cmd = new SqlCommand( "INSERT INTO Orders(UserId, Status, TotalAmt, OrderTime) " + "VALUES(@uid, 0, @total, GETDATE()); SELECT SCOPE_IDENTITY();", conn, tx); cmd.Parameters.AddWithValue("@uid", userId); cmd.Parameters.AddWithValue("@total", totalAmt); int orderId = Convert.ToInt32(cmd.ExecuteScalar()); foreach (CartItem item in cart) { SqlCommand detailCmd = new SqlCommand( "INSERT INTO OrderItems(OrderId, DishId, Quantity, Price) " + "VALUES(@oid, @did, @qty, @price)", conn, tx); detailCmd.Parameters.AddWithValue("@oid", orderId); detailCmd.Parameters.AddWithValue("@did", item.DishId); detailCmd.Parameters.AddWithValue("@qty", item.Quantity); detailCmd.Parameters.AddWithValue("@price", item.Price); detailCmd.ExecuteNonQuery(); } tx.Commit(); } catch { tx.Rollback(); throw; } }BeginTransaction之后的命令都要显式传入事务对象，这是最容易写错的地方。第二个命令如果漏传 tx，SqlCommand 会在自己新开的连接上执行，然后报错或干脆把第一条命令也锁到别的事务里。
ExecuteScalar配合SCOPE_IDENTITY()是取自增主键的经典做法。SCOPE_IDENTITY只拿当前会话最后插入的标识值，比@@IDENTITY安全——后者可能被触发器改写，拿到一个完全无关的编号。
AddWithValue的问题在数据类型映射上。默认会把字符串当 nvarchar，数字当 int 或 decimal，但如果表字段是 char(10) 这种定长类型，参数值和字段长度不匹配时会出现隐式转换，轻则性能差，重则截断报错。老练一点的做法是指定 SqlDbType，比如：
cmd.Parameters.Add("@price", SqlDbType.Decimal).Value = item.Price;3.3 订单状态流转：从已下单到配送中
Orders.Status 字段担当状态机，常见的整型定义如下：
| 状态值 | 含义 |
|---|---|
| 0 | 已下单，等待商家确认 |
| 1 | 商家已接单 |
| 2 | 配送中 |
| 3 | 已完成 |
| -1 | 已取消 |
推进状态的代码通常是：
public int UpdateOrderStatus(int orderId, int newStatus) { string sql = "UPDATE Orders SET Status=@status WHERE OrderId=@oid"; using (SqlConnection conn = new SqlConnection(connectionString)) using (SqlCommand cmd = new SqlCommand(sql, conn)) { cmd.Parameters.AddWithValue("@status", newStatus); cmd.Parameters.AddWithValue("@oid", orderId); conn.Open(); return cmd.ExecuteNonQuery(); } }这段代码能跑，但允许任意状态跳转，比如把已完成订单直接改回已下单。严谨做法是加一层校验，只放行合法迁移：
bool IsValidTransition(int oldStatus, int newStatus) { switch (oldStatus) { case 0: return newStatus == 1 || newStatus == -1; case 1: return newStatus == 2 || newStatus == -1; case 2: return newStatus == 3; default: return false; } }状态迁移校验写在 C# 里的好处是逻辑集中、调试方便。写在数据库触发器里也能做，但课程设计阶段代码可读性更重要。
除了更新状态，「查询我的订单」也是高频功能。它本质上是把 Orders、OrderItems、Dishes 三张表按用户做关联汇总，常见写法是 JOIN 后按 OrderId 分组，然后在 DataGridView 里绑定显示。理解状态机和事务这两块之后，这套源码里最复杂的业务逻辑就已经拿下了。
4. 界面与事件：Winform 里把 DataGridView 和增删改查串起来
源码包的价值在业务逻辑，但用户接触到的只有界面。Winform 的界面层和数据库之间隔着一层事件，这章把它们串起来。
4.1 DataGridView 绑定菜品表：三行代码里的数据流
展示菜品列表，最直接的写法是：
string sql = "SELECT DishId, Name, Price, Category FROM Dishes"; DataTable dt = new DataTable(); using (SqlDataAdapter da = new SqlDataAdapter(sql, connectionString)) { da.Fill(dt); } dataGridView1.DataSource = dt;SqlDataAdapter.Fill内部自动处理了打开连接、填充 DataTable、关闭连接的完整流程。它适合查询结果要整体展示的场景，ExecuteReader则适合逐行处理大量数据的场景。这里返回的数据量不过几十行，用 Adapter 最省事。
DataGridView 显示后，常见的调整项：
| 需求 | 写法 |
|---|---|
| 隐藏主键列 | dataGridView1.Columns["DishId"].Visible = false |
| 改列标题 | dataGridView1.Columns["Name"].HeaderText = "菜品名称" |
| 金额右对齐 | dataGridView1.Columns["Price"].DefaultCellStyle.Alignment = DataGridViewContentAlignment.MiddleRight |
| 禁止用户编辑 | dataGridView1.ReadOnly = true |
筛选功能建议先套 BindingSource，而不是直接改 DataTable：
BindingSource bs = new BindingSource(); bs.DataSource = dt; dataGridView1.DataSource = bs; bs.Filter = "Category='套餐'";BindingSource 解耦了界面和底层数据。修改 DataGridView 里显示的单元格不会反向污染 DataTable，Filter 也能在内存里直接过滤，不必重新查库。很多初学者会直接在 DataGridView 的行上做界面级删除，结果只是画面上少了一行，关掉重开又出现了——因为数据库根本没动。
4.2 按钮事件里的增删改查：从点击到数据库
新增和删除是菜单管理最常用的两个入口。删除为例：
private void btnDelete_Click(object sender, EventArgs e) { if (dataGridView1.CurrentRow == null) return; int dishId = Convert.ToInt32(dataGridView1.CurrentRow.Cells["DishId"].Value); string sql = "DELETE FROM Dishes WHERE DishId=@id"; using (SqlConnection conn = new SqlConnection(connectionString)) using (SqlCommand cmd = new SqlCommand(sql, conn)) { cmd.Parameters.AddWithValue("@id", dishId); conn.Open(); int affected = cmd.ExecuteNonQuery(); if (affected > 0) LoadDishes(); // 重新绑定列表 } }CurrentRow可能为空，用户可能点击的是表头或空白区域。不判空直接取 Value 会抛 NullReferenceException。Cells["DishId"]的列名要和 SELECT 里的别名一致，如果 SQL 写的是SELECT DishId AS ID，这里就要写成Cells["ID"]。
删除被订单引用的菜品会触发外键冲突。先把检查写清楚，比让用户看数据库报错要友好：
string checkSql = "SELECT COUNT(*) FROM OrderItems WHERE DishId=@id"; // 有引用时提示：该菜品已有历史订单，不能删除新增菜品也是同样的模式，只是 INSERT 语句换掉。这两条代码放在一起看，你会发现 Winform 的增删改查就是连接字符串 + 参数化 SQL + 按钮事件的排列组合。真正需要花心思的是异常情况和边界：判空、主键冲突、外键引用。
4.3 跨窗体传值：子窗体修改后主窗体列表怎么刷新
菜品管理子窗体保存后，主窗体的列表需要刷新。最经典的做法是用事件通知：
// MainForm 中 FrmAddDish frm = new FrmAddDish(); frm.DataChanged += LoadDishes; frm.ShowDialog(); // FrmAddDish 中 public event Action DataChanged; private void btnSave_Click(object sender, EventArgs e) { // 执行 INSERT... DataChanged?.Invoke(); Close(); }DataChanged?.Invoke()是 C# 6 之后的标准写法，事件没有订阅者时直接跳过，不会抛 NullReference。主窗体把LoadDishes挂上去，子窗体每次保存成功就通知一次，界面自动刷新。
这里要留意ShowDialog和Show的区别。ShowDialog打开模态窗体，代码在 ShowDialog 之后会阻塞直到子窗体关闭；Show打开非模态窗体，代码继续往下跑。如果你在 Show 之后马上刷新列表，子窗体根本还没打开，刷新没有意义。顺带提一个 Winform 初学者常犯的错：子窗体保存后直接在主窗体的 LoadDishes 里又 new 了一个 DataGridView 和连接，造成双份资源释放问题。正确做法始终是让 DataGridView 维持同一个实例，只重新设置 DataSource。
还有一种场景是主窗体需要拿到子窗体输入的值，比如从菜品列表点击"加入购物车"传回主窗体。做法是把值通过子窗体的公开属性暴露，在 ShowDialog 后读取：
frm.ShowDialog(); if (frm.DialogResult == DialogResult.OK) { int selectedDishId = frm.SelectedDishId; }这个模式配合 DialogResult，是 Winform 里最稳定也最好理解的通信方式。
5. 避坑：从附加数据库到登录运行的七条高频排查记录
很多问题不是代码逻辑错，而是环境没对齐。这章按我实际踩过的顺序整理七条高频报错，每条都按现象、原因、解决来写，你照着对号入座就行。如果你按前面的步骤走完依然报错，先别急着改业务代码，停下来看看是不是下面某一条。
5.1 现象：登录时报"无法打开数据库 test1"
原因：数据库没有附加成功，或者附加后的库名和连接字符串里的Database不一致。这个报错出现在登录验证的第一步，说明程序连上了 SQL Server 实例，但实例里找不到 test1 这个库。
解决：SSMS 里刷新数据库节点，执行下面这条 SQL 看真实库名列表：
SELECT name FROM sys.databases;确认 test1 是否存在。如果库名是 test1_new，改 load.cs 里的Database=test1_new；如果库根本不存在，回到第 2 章再附加一次。附加成功后右键数据库 → 属性 → 文件，确认物理路径指向工程里的 DB 目录——路径对不上，下次重启 SQL Server 服务后可能又变成"已分离"状态。
5.2 现象：附加数据库时提示"文件正在使用中"或"权限不足"
原因：mdf/ldf 被同名库占用，或者当前 Windows 用户对 DB 目录没有写权限。从压缩包解压到 Program Files，或以管理员安装在受保护目录时尤其容易出权限问题。
解决：把工程目录移到纯英文路径，例如D:\OrderSystem。右键 DB 目录 → 属性 → 安全，给当前用户配"修改"权限；同时检查 mdf/ldf 文件属性，"只读"勾选会直接导致附加失败。若仍报"正在使用中"，打开 SSMS 检查 sys.databases 里是否已有同名库，先分离或删除再附加。注意分离操作要在 SSMS 里右键数据库 → 任务 → 分离完成，不要直接删文件。
5.3 现象：编译通过，运行时报找不到 System.Data.SqlClient.SqlConnection
原因：项目目标框架和运行环境不匹配。源码在旧 .NET Framework 4.x 下开发，拿到新版 .NET 6/8 的 Visual Studio 里直接编译时，System.Data.SqlClient 不再默认引用。
解决：在 NuGet 包里安装 System.Data.SqlClient，或者把项目目标框架改回 .NET Framework 4.7.2 或 4.8。我一般优先改目标框架，因为整个解决方案的其他依赖多半也是按 Framework 编译的，改运行库版本反而容易引发连锁冲突。改完框架记得重新生成解决方案，而不是直接按 F5 继续跑旧编译产物。
5.4 现象：本机跑得好好的，部署到客户机提示"连接超时"或"用户登录失败"
原因：三种情况叠加出现是常态——连接串Server还写 localhost（连的是客户机自己）、SQL Server 没开混合验证模式导致 sa 登录失败、1433 端口被防火墙拦截。
解决：Server改成开发机的 IP 地址，例如Server=192.168.1.100;Database=test1;User ID=sa;Password=xxx。在开发机的 SSMS 里，实例属性 → 安全性 → 选"SQL Server 和 Windows 身份验证模式"，给 sa 启用并设一个强密码。最后在 Windows 防火墙放行 1433 端口，验证命令是：
telnet 192.168.1.100 1433能连通会进入空白窗口，连不上会直接提示失败。改完记得重启 SQL Server 服务，否则新的身份验证模式不生效。
5.5 现象：菜品价格显示 0.30000000000000004 这种怪值
原因：价格字段在数据库里用的是 float，而不是 decimal。float 是二进制浮点，0.1 + 0.2 在内存里本来就不是精确的 0.3。显示层再把它直接绑到 DataGridView，就看到了这串尾巴。
解决：数据库里金额一律用 decimal(10,2)，C# 侧读取用Convert.ToDecimal，插入时指定SqlDbType.Decimal。如果已有的数据已经用 float 存了，先执行一次类型转换：
ALTER TABLE Dishes ALTER COLUMN Price decimal(10,2);float 适合科学计算，不适合任何涉及钱的地方。这个坑在课程设计里经常被忽略，因为数据量小、金额恰好能整除时看不出问题。
5.6 现象：改了 load.cs 的连接字符串，程序还是连旧库
原因：工程里可能不止一处 connectionString。有的窗体文件里直接写死了连接串，load.cs 里的那行只是其中一份；或者项目里还带着 App.config，ConfigurationManager 优先读取配置文件。
解决：在解决方案里全局搜索connectionString，把出现的位置全部列出来统一改，再用"重新生成解决方案"覆盖旧的 exe。如果项目里有 App.config，检查它是否覆盖了 load.cs 里的值——配置文件在 .NET 里的优先级通常高于代码里写死的字符串。
5.7 现象：登录成功，但菜品列表一片空白
原因：没报错说明 SQL 能执行，但查不到数据。通常三个方向：表名不在 Dishes（可能是 Menu、Product 之类）；数据库里只有 Users 表，没有初始化菜品数据；或者当前登录账号的权限只看得到部分数据。
解决：在 SSMS 里手动执行：
SELECT TOP 10 * FROM Dishes;确认数据存在。若没有数据，找部署须知里是否提到初始化脚本；没有脚本就自己往 Dishes 表插入几条菜品记录，菜单模块马上就有数据可显示。如果表名不对，用这条 SQL 列出所有表名：
SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES;然后回到代码里把 SELECT 的表名改成实际表名。这七条覆盖了从环境准备到业务逻辑的大部分翻车现场，剩下的小问题基本靠断点能定位。
6. 进阶技巧：把连接字符串外置到 App.config，并用 SQL Profiler 验证参数化查询
6.1 用配置文件干掉硬编码
load.cs 里的连接字符串是硬编码，每次换环境都要改代码重新编译。更好的做法是把它挪到 App.config：
<connectionStrings> <add name="OrderDb" connectionString="Server=.;Database=test1;Integrated Security=True;" providerName="System.Data.SqlClient"/> </connectionStrings>C# 侧读取：
string conn = ConfigurationManager.ConnectionStrings["OrderDb"].ConnectionString;改动之后，部署到新机器只需改 App.config 一行，不用重新生成 exe。如果项目里还没有 App.config，在解决方案里右键项目 → 添加 → 新建项 → 应用程序配置文件，VS 会自动生成一个。这个习惯是我在维护老项目时被逼出来的——那时候每次去现场都要带笔记本改代码重新编译，后来才意识到配置文件早该这么干。
6.2 用 SQL Profiler 验证参数化查询有没有生效
SQL Server Profiler 能捕捉 SqlClient 发送到数据库的完整 SQL。参数化查询会显示为exec sp_executesql N'SELECT ...'加上参数列表；拼接字符串则是整条 SQL 直接可见。看到后者的地方，就是该改成参数化的位置。
打开 Profiler 后新建跟踪，事件选择 RPC:Completed 和 SQL:BatchCompleted，然后运行程序做一次登录和下单。回到 Profiler 里按文本筛选INSERT，就能看到真实的 SQL 语句。如果你发现某个查询没走参数化，即使功能正常，也建议改掉——这既是防注入，也是避免拼接字符串里单引号导致意外报错。
这套源码包我按上面的流程完整复现过一遍，从解压到跑通订单流程大概半小时。从那以后，我每次拿到带数据库的 C# 源码包，都会先花两分钟验证三点：连接字符串实例名对不对、数据库有没有附加成功、登录查询是不是参数化写法。这三项通过之后，剩下的时间就都能花在业务逻辑上，而不是在深夜和报错窗口对线。希望帮到你。
本文还有配套的精品资源，点击获取
