简介这份WinformSQL Server外卖系统是一套面向C/S架构学习者的完整实战项目适合课程设计、毕业设计或入门进阶练习。项目整体由用户端、商家端、骑手端、管理员四个角色端构成用户端实现商品浏览、跨店铺购物车、结算、钱包及个人订单管理商家端支持商品与订单管理、骑手派单骑手端可查询订单并执行派单管理员负责全平台人员与业务管控核心业务闭环完整拿到即可运行且附带数据库。压缩包共392个文件主体为C#源码文件.cs、界面资源.resx/.resources、界面示意图.jpg/.png另含SQL脚本、配置文件、可执行程序等整体17.63MB目录结构清晰便于按模块查阅。已有556人学习使用对希望快速上手WinformSQL Server开发、理解多角色业务系统分层设计的读者具有很好的参考与复用价值。1. 先把「winformsqlserver外卖系统」翻译到真实场景它到底解决谁的问题拿到「winformsqlserver外卖系统」这类标题很多第一反应是点餐小程序或手机App。实际上WinForm 桌面端 SQL Server 这套组合服务的是小程序之外的另外一半场景商家总店管理后台、食堂窗口、校园跑腿调度、连锁门店收银台的订单管理端。这类系统不需要花哨前端要的是稳定直连数据库、快速录入、订单状态可控。不依赖 Web 服务部署一套 Windows 机器配上 SQL Server 就能跑数据全在自己手里改表、导出、对接打印机都方便。适合两类人一是想完整走一遍 WinForm SQL Server 项目流程的开发者二是要给中小商家做内部订单管理工具、又不想引入太重分布式架构的从业者。这个小而完整的系统正好把「登录 → 点餐 → 下单 → 出餐 → 状态变更 → 对账」这条链路用最稳的方式铺开。2. 数据表先于功能从点餐-出餐-配送反推核心表结构与订单状态机2.1 为什么先设计表而不是先画界面WinForm 开发最容易犯的错是先把窗体拖出来再回头补数据库。等到对接订单明细时才发现表结构撑不起业务流程改界面容易改表结构牵一发动全身。正确顺序是从「一份订单在系统里会经历什么」反推数据表。一份外卖订单至少经历四个环节顾客下订单、商家接单出餐、骑手/配送员取餐送达、顾客确认完成。每一步都要留痕不能只存一个「订单最终状态」否则出了问题根本不知道是哪一环丢的。从这条链路能拆出六张核心表用户表顾客、商家表、菜品表挂在商家下面、订单主表、订单明細表、订单状态日志表。其中订单详情表绝对不能省外卖会点多个菜主表和明细表分开才能对得上金额。2.2 建表脚本把六张核心表一次建齐按上述链路表结构直接用 SQL 脚本建我一般会把字段名、类型、约束在脚本里一次敲定不依赖可视化设计器。下面这套脚本可以直接在 SQL Server Management Studio 里执行CREATE TABLE T_User ( Id INT IDENTITY(1,1) PRIMARY KEY, Name NVARCHAR(50) NOT NULL, Phone NVARCHAR(20) NOT NULL UNIQUE, CreateTime DATETIME NOT NULL DEFAULT GETDATE() ); CREATE TABLE T_Merchant ( Id INT IDENTITY(1,1) PRIMARY KEY, Name NVARCHAR(100) NOT NULL, Address NVARCHAR(200) NULL, Phone NVARCHAR(20) NULL, Status TINYINT NOT NULL DEFAULT 1, -- 1正常 0停用 CreateTime DATETIME NOT NULL DEFAULT GETDATE() ); CREATE TABLE T_Dish ( Id INT IDENTITY(1,1) PRIMARY KEY, MerchantId INT NOT NULL REFERENCES T_Merchant(Id), Name NVARCHAR(100) NOT NULL, Price DECIMAL(10,2) NOT NULL, Stock INT NOT NULL DEFAULT 0, Status TINYINT NOT NULL DEFAULT 1, -- 1上架 0下架 CreateTime DATETIME NOT NULL DEFAULT GETDATE() ); CREATE TABLE T_Order ( Id INT IDENTITY(1,1) PRIMARY KEY, OrderNo NVARCHAR(32) NOT NULL UNIQUE, CustomerId INT NOT NULL REFERENCES T_User(Id), MerchantId INT NOT NULL REFERENCES T_Merchant(Id), TotalAmount DECIMAL(10,2) NOT NULL, Status TINYINT NOT NULL DEFAULT 0, CreateTime DATETIME NOT NULL DEFAULT GETDATE(), PayTime DATETIME NULL, FinishTime DATETIME NULL ); CREATE TABLE T_OrderDetail ( Id INT IDENTITY(1,1) PRIMARY KEY, OrderId INT NOT NULL REFERENCES T_Order(Id), DishId INT NOT NULL REFERENCES T_Dish(Id), Count INT NOT NULL, Price DECIMAL(10,2) NOT NULL, SubTotal DECIMAL(10,2) NOT NULL ); CREATE TABLE T_OrderStatusLog ( Id INT IDENTITY(1,1) PRIMARY KEY, OrderId INT NOT NULL REFERENCES T_Order(Id), OldStatus TINYINT NOT NULL, NewStatus TINYINT NOT NULL, Remark NVARCHAR(200) NULL, CreateTime DATETIME NOT NULL DEFAULT GETDATE() );字段类型说明Status 用 TINYINT 而不是字符串是为了排序和判断快且不会被录入人员填出「已送出」这类冗余写法金额一律 DECIMAL(10,2)不碰 FLOAT避免出现 19.99 变成 19.99000001 的对账问题名称和备注用 NVARCHAR因为要存中文VARCHAR 在排序规则不当的时候容易出乱码。OrderNo 用 UNIQUE 约束业务上保证同一笔订单号不会因为程序重复点击而插入两条。建完表后还要补两个常用索引。查询「某商家今天有哪些订单」和加载订单明细是高频操作没有索引会全表扫CREATE INDEX IX_Order_Merchant ON T_Order (MerchantId, CreateTime DESC); CREATE INDEX IX_OrderDetail_Order ON T_OrderDetail (OrderId);索引说明第一个索引服务商家端「今日订单」列表按 CreateTime 倒序可以直接取最新单第二个索引让订单详情查询不逐条扫描明细表。不要每个字段都建索引索引多了写入变慢这两条对这个系统已经够用。2.3 订单状态机的取舍状态流转必须由业务层控制订单表里的 Status 字段承担整个系统最核心的状态判断。我常用一组数字状态0 待支付、1 已支付、2 制作中、3 配送中、4 已完成、-1 已取消、-2 超时关闭。负数状态单独占一段正数状态按时间顺序排列这样查历史订单时一眼能看出链路走到哪一步断了。状态机要解决的真正问题是「状态不能被随意跳转」。比如一笔订单不能从「已支付」直接跳成「已完成」中间至少要经过「制作中」和「配送中」。很多人把状态流转逻辑散落在各个窗体的按钮点击事件里商家端改一下、顾客端又改一下最后状态乱了根本查不出来。我的做法是先在业务层定义一张允许流转的规则表第四章会放具体代码同时保留 T_OrderStatusLog 表每笔订单每次变状态都必须写一条日志等于给状态机装了黑匣子。谁能改状态、从什么状态改到什么状态、什么时候改的全部有据可查。3. 三层架构封装数据库访问连接串、SqlHelper 与 Dapper 的一次落地3.1 为什么 WinForm 小项目也要分三层「WinForm 直接拖一个 DataGridView再拖一个 SqlDataAdapter 绑定最快」——这套说法在小 Demo 里成立一旦加到十张表、十几个窗体就会变成灾难。每个窗体各自写连接串改一次密码要全局替换同一个查询在订单窗体和统计窗体各写一遍改一个字段漏改另一处UI 线程被 SQL 卡死是家常便饭。给 WinForm SQL Server 系统做三层结构不是为了堆概念是为了把三类变化隔开界面变、业务流程变、数据库访问变。界面层只调用业务层业务层只调用数据层数据层只认 SQL 和参数。常见的项目分层是TakeOut.UIWinForm 窗体、TakeOut.BLL订单、菜品等业务逻辑、TakeOut.DALSqlHelper 与仓储、TakeOut.ModelDTO/实体。连接字符串放在 UI 层的 App.config 里由 BLL 构造时传入 DAL不让数据层自己去读配置文件这样单元测试和换数据库都不动界面代码。3.2 最小可跑的 SqlHelper第一条查询先跑通不引第三方库时一个 SqlHelper 足够支撑整系统。下面这个版本覆盖查询、增删改、取单值三种最常见操作代码量不大但都是老项目里真正落地的写法using System.Data; using System.Data.SqlClient; namespace TakeOut.DAL { public sealed class SqlHelper { private readonly string _connStr; public SqlHelper(string connStr) { _connStr connStr; } public DataTable Query(string sql, params SqlParameter[] ps) { using (var conn new SqlConnection(_connStr)) using (var cmd new SqlCommand(sql, conn)) { if (ps ! null ps.Length 0) { cmd.Parameters.AddRange(ps); } var adapter new SqlDataAdapter(cmd); var table new DataTable(); adapter.Fill(table); return table; } } public int Execute(string sql, params SqlParameter[] ps) { using (var conn new SqlConnection(_connStr)) using (var cmd new SqlCommand(sql, conn)) { if (ps ! null ps.Length 0) { cmd.Parameters.AddRange(ps); } conn.Open(); return cmd.ExecuteNonQuery(); } } public object ExecuteScalar(string sql, params SqlParameter[] ps) { using (var conn new SqlConnection(_connStr)) using (var cmd new SqlCommand(sql, conn)) { if (ps ! null ps.Length 0) { cmd.Parameters.AddRange(ps); } conn.Open(); return cmd.ExecuteScalar(); } } } }逻辑说明Query 方法用 SqlDataAdapter 的 Fill 执行查询不用手动 Open适配器会自动管理连接状态Execute 和 ExecuteScalar 用于 UPDATE 和 INSERT前者返回受影响行数后者返回第一行第一列的值常用来取自增主键。参数说明所有外部输入必须放在 SqlParameter 里禁止拼字符串进 SQL这是防注入的底线Execute 方法返回值为 0 时说明 UPDATE 没匹配到行要结合业务判断是数据不存在还是条件没满足。3.3 升级到 Dapper用一行代码完成查询映射随着查询变多DataTable 的缺点是列名要靠魔法字符串访问改字段名编译器不报错运行期才崩。我一般会在这个阶段引入 Dapper 这类微型 ORM不改变手写 SQL 的习惯只把结果映射成强类型对象。先给 Dish 实体加一个类public class Dish { public int Id { get; set; } public int MerchantId { get; set; } public string Name { get; set; } public decimal Price { get; set; } public int Stock { get; set; } public byte Status { get; set; } }用 Dapper 查询菜品using System.Data.SqlClient; using Dapper; public Dish GetDishById(int dishId, string connStr) { using (var conn new SqlConnection(connStr)) { const string sql SELECT Id, MerchantId, Name, Price, Stock, Status FROM T_Dish WHERE Id Id;; var dish conn.QueryFirstOrDefaultDish(sql, new { Id dishId }); return dish; } }逻辑说明QueryFirstOrDefault 把查询结果自动映射到 Dish 实体匿名对象 new { Id dishId } 里的 Id 会自动匹配 SQL 参数 Id不需要逐个声明 SqlParameter代码量下降一大截。选 Dapper 而不是全自动 ORM是因为这个系统里查询多是多表 Join手写 SQL 更直观Dapper 只负责映射和执行不帮我们猜 SQL出问题时排查路径短。如果团队更习惯实体自动建表、想要内置分页和批量操作可以换成 SqlSugar 一类全功能 ORM但在项目初期我倾向 Dapper给后面留出自由调 SQL 的空间。3.4 三个必调参数连接超时、命令超时、连接池连接字符串不是一长串抄完就结束里面有三个参数我几乎每次都会显式确认。第一个是 Connect Timeout默认 15 秒数据库服务器在内网可以保留 15跨网段或数据库负载高时加到 30第二个是 CommandTimeout不写在连接串里而是 SqlCommand 的属性默认 30 秒涉及报表查询或大批量更新时调到 60否则一个慢查询直接抛「超时已过期」第三个是 Max Pool Size默认是 100WinForm 客户端几十台机器同时连同一个实例时100 够用但如果代码里忘关连接设再大也会被打满。常用连接串写法如下appSettings add keyConnectionString valueServer.;DatabaseTakeOutDB;Integrated SecurityTrue;Connect Timeout15;Max Pool Size100 / /appSettings参数说明Server. 代表本机默认实例如果部署到独立数据库服务器要写成 IP 地址或机器名加实例名Integrated SecurityTrue 走 Windows 身份验证适合内网部署省去在代码里保存明文密码跨机器部署时改用 SQL Server 身份验证需要配 User Id 和 Password同时注意 Persist Security Info 保持 False避免连接串泄露。连接池这个参数分工明确PoolingTrue 默认就是开的不用写要设置的是 Max Pool Size 和 Min Pool Size。Min Pool Size 建议设 0WinForm 客户端不是高并发服务没必要启动就预热连接。4. 让下单事务可信并发扣库存、状态机约束与 UI 防假死4.1 一笔订单至少牵动四张表没有事务迟早出脏数据下订单的动作不是 INSERT 一张 T_Order 就结束。一次完整下单要写订单主表、写订单明细、扣菜品库存、写状态日志四件事要么全部成功要么全部不成功。有人问「先插入主表再逐条插明细最后扣库存怎么了」——中途任何一条 INSERT 报错订单主表已经落库页面却提示下单失败顾客再点一次就生成两笔单或者库存扣了但订单没生成用户付了钱商家看不到单。SqlTransaction 就是给这一串操作包一层「要么全做要么全不做」的边界。我在下单事务里会把扣库存放在写明细之前这样一旦库存不足事务回滚时主表和明细根本没写进去不会留下孤儿订单。事务级别我习惯用 ReadCommitted不需要 Serializable那会让并发吞吐明显下降。4.2 并发扣库存的反直觉写法把判断条件写进 UPDATE库存扣减是外卖系统并发问题最集中的地方。秒杀单品、最后一单库存两个窗口同时下单最常见的翻车写法是「先 SELECT 查库存判断足够再 UPDATE 减库存」。两个请求同时读到库存是 1都判断可以通过结果库存变成 -1。正确姿势是让 UPDATE 语句自己带条件影响行数为 0 就说明没抢到完全不需要锁表和 SELECT。public int CreateOrder(OrderDto dto, string connStr) { using (var conn new SqlConnection(connStr)) { conn.Open(); using (var tx conn.BeginTransaction(IsolationLevel.ReadCommitted)) { try { // 1. 先插入订单主表拿到自增主键 const string orderSql INSERT INTO T_Order (OrderNo, CustomerId, MerchantId, TotalAmount, Status, CreateTime) VALUES (OrderNo, CustomerId, MerchantId, TotalAmount, 0, GETDATE()); SELECT CAST(SCOPE_IDENTITY() AS int);; string orderNo DateTime.Now.ToString(yyyyMMddHHmmss) dto.CustomerId.ToString().PadLeft(4, 0); int orderId conn.ExecuteScalarint(orderSql, new { OrderNo orderNo, dto.CustomerId, dto.MerchantId, dto.TotalAmount }, tx); // 2. 扣库存把库存足够这个判断条件写进 UPDATE const string stockSql UPDATE T_Dish SET Stock Stock - Count, UpdateTime GETDATE() WHERE Id DishId AND Stock Count AND Status 1;; int affected conn.Execute(stockSql, new { dto.DishId, dto.Count }, tx); if (affected 0) { tx.Rollback(); return -1; } // 3. 写订单明细 const string detailSql INSERT INTO T_OrderDetail (OrderId, DishId, Count, Price, SubTotal) VALUES (OrderId, DishId, Count, Price, SubTotal);; conn.Execute(detailSql, new { OrderId orderId, dto.DishId, dto.Count, dto.Price, SubTotal dto.Count * dto.Price }, tx); // 4. 写状态日志 const string logSql INSERT INTO T_OrderStatusLog (OrderId, OldStatus, NewStatus, Remark, CreateTime) VALUES (OrderId, -1, 0, 用户提交订单, GETDATE());; conn.Execute(logSql, new { OrderId orderId }, tx); tx.Commit(); return orderId; } catch { tx.Rollback(); throw; } } } }这段代码的关键在第二步。UPDATE 条件里直接写 Stock Count数据库引擎在更新行时会加行锁两个并发请求同时执行第一个成功让库存变成 0第二个再执行发现条件不满足影响行数是 0于是返回 -1 表示库存不足。整个过程没有显式 SELECT FOR UPDATE也没有自定义锁靠 SQL Server 行锁机制天然串行化同一条菜品的更新。参数说明SCOPE_IDENTITY 取当前连接当前事务插入的自增主键不要用 IDENTITY后者可能被触发器返回的其他自增值覆盖OrderNo 用时间加客户号拼接只是演示真实环境建议加随机数或用序列生成防止同一秒重复单号。4.3 界面不能卡死把耗时操作丢出 UI 线程WinForm 里最常见的「假死」就是点下单按钮后整个窗体白屏鼠标转圈因为 SQL 操作直接在 UI 线程执行等待数据库返回期间界面无法重绘。下单快则几百毫秒慢查询几秒用户此时会习惯性再点一次按钮导致重复提交。解决办法是异步执行数据库操作并把按钮在异步期间禁用。private async void btnSubmitOrder_Click(object sender, EventArgs e) { btnSubmitOrder.Enabled false; try { int orderId await Task.Run(() { var dal new OrderDal(_connStr); return dal.CreateOrder(_dto); }); MessageBox.Show($下单成功订单号{orderId}); } catch (Exception ex) { MessageBox.Show($下单失败{ex.Message}); } finally { btnSubmitOrder.Enabled true; } }逻辑说明Task.Run 把 CreateOrder 放到线程池执行await 让 UI 线程在等待期间保持响应MessageBox 回到 UI 线程弹窗没有跨线程操作控件的问题。注意 async void 只出现在事件处理器里普通业务方法不要用 async void否则异常无法被捕获。参数说明下单成功回调里不要立刻重新查询整个订单列表可以先拿返回值更新当前行的状态等用户刷新时再全量查询减少不必要的数据库压力。4.4 状态流转的约束用白名单挡住非法跳转状态机不用数据库触发器约束时最好在业务层放一张规则表。我在 BLL 里维护一个 Dictionary每个状态只允许跳到白名单里的目标状态private static readonly Dictionaryint, Listint AllowTransitions new() { [0] new Listint { 1, -1 }, // 待支付 - 已支付 / 已取消 [1] new Listint { 2, -1 }, // 已支付 - 制作中 / 已取消 [2] new Listint { 3, -1 }, // 制作中 - 配送中 / 已取消 [3] new Listint { 4 }, // 配送中 - 已完成 [4] new Listint(), // 已完成终态 [-1] new Listint(), // 已取消终态 [-2] new Listint() // 超时关闭终态 }; public static bool CanTransit(int currentStatus, int nextStatus) { return AllowTransitions.TryGetValue(currentStatus, out var targets) targets.Contains(nextStatus); }逻辑说明CanTransit 在每次状态变更前调用比如骑手点「送达」时程序先判断当前状态是 3 配送中才能进入 4 已完成。如果商家误操作把「待支付」直接改成「已完成」规则表直接拒绝。这套规则还有一个好处新增状态时只需要改一个 Dictionary不用去翻所有窗体找哪里在写 UPDATE Status。状态变更成功后同一事务里写 T_OrderStatusLog保持日志和状态强一致。5. 部署验证期高频坑排查从连不上库到数据丢了的 6 个真实现场5.1 坑 1本机能连客户机器连不上——SQL Server 协议与防火墙现象开发机上程序跑得飞快打包到门店电脑后打开窗体报「建立与 SQL Server 的连接时发生网络相关错误」。原因SQL Server 默认安装未必启用 TCP/IP 协议Windows 防火墙默认也拦截 1433 端口。解决在数据库服务器上打开 SQL Server 配置管理器确认 SQL Server 网络配置里 TCP/IP 已启用服务重启一次再在防火墙入站规则里放行 1433 端口。验证方式是在客户端机器上打开命令提示符执行 telnet 数据库IP 1433能连上说明网络层通了再回查程序里的连接串。注意改协议和防火墙都要以管理员身份操作普通用户权限经常改完重启服务不生效。5.2 坑 2连接串里那个 .mdf 的玄学别让编译覆盖你的数据现象开发时连接串写成 AttachDbFilename|DataDirectory|\TakeOutDB.mdf反复调试几天后突然发现之前录入的测试数据全没了。原因Visual Studio 默认会把 .mdf 文件复制到输出目录每次重新编译可能用项目文件覆盖 bin 目录里的数据库等于每次构建都在「重置数据」。解决这类系统不要用 AttachDbFilename直接在 SQL Server 实例里创建 TakeOutDB连接串写成 Server.;DatabaseTakeOutDB;Integrated SecurityTrue;。这样数据库固定存放在实例的数据目录里和编译输出完全隔离。已经用 .mdf 的项目可以先把当前数据备份再在 SSMS 里附加一次并改为普通数据库连接。5.3 坑 3下单后窗体白屏转圈用户以为程序死了现象点击下单、导出报表这类耗时操作界面卡住不动最多几秒后弹窗严重时被系统提示「无响应」。原因数据库操作阻塞在 UI 线程消息循环无法处理重绘和点击。解决按第四章 4.3 的做法把 ExecuteNonQuery、DataTable.Fill、Dapper 查询都放到 Task.Run 或 BackgroundWorker 里。排查时可以看任务管理器程序「无响应」不代表死锁等查询超时结束后通常会恢复。上线前用慢查询或大数据量订单表做一次压测把命令超时调合理比在用户现场等报错强。5.4 坑 4运行几小时后报「连接池已达到最大大小」现象系统早上正常中午开始此起彼伏抛异常提示连接池满。原因某个查询路径里用了 SqlConnection 但没释放连接池里的连接被占用不归还累积到 Max Pool Size。最常见的漏网之鱼是 DataReader 没关或者 SqlDataAdapter.Fill 之后连接没 Dispose。解决把每处 SqlConnection 都改成 using 块确保异常路径也能释放DataReader 用完后在 finally 里关闭。顺带把连接串里的 Max Pool Size 调到 200 先缓解但这只是治标真正要查的是哪些 SQL 频繁打开连接不释放最简单的方法是在 SQL Server 的 sys.sysprocesses 视图里看当前连接数和每个连接的登录名。5.5 坑 5外键约束让删除订单变成连锁反应现象想清理测试数据先 DELETE T_Order 报错提示外键冲突先删商家也报错T_Dish 还引着它。原因表之间有依赖关系删除顺序必须从子表到父表。解决不要在一张表上硬删按 T_OrderStatusLog → T_OrderDetail → T_Order → T_Dish → T_Merchant 的顺序清理或者干脆业务上做逻辑删除。外卖系统里订单是凭据真实环境不太建议物理删除更稳的做法是在每张表加 IsDeleted 字段查询默认过滤删除只是 UPDATE。订单数据留底是后面和商家对账的唯一依据物理删除等于给自己埋雷。5.6 坑 6没有备份调度误操作后只能干瞪眼现象运营人员误删了一批订单状态想把数据库恢复到昨天发现没有任何备份文件。原因开发阶段只关心功能没把备份纳入交付物。解决把备份脚本写进部署文档用 Windows 计划任务每天凌晨执行一次 sqlcmd 命令BACKUP DATABASE TakeOutDB TO DISKD:\Backup\TakeOutDB.bak WITH INIT;。同时在系统「关于」页面加一个手动备份按钮背后执行同一条 BACKUP 语句并提示备份文件路径。数据恢复就是最后一根救命稻草这步不做这个方向做再完善也谈不上可靠。6. 上线后加一道保险状态日志触发器与每日数据体检 SQL6.1 给订单状态加一个 AFTER UPDATE 触发器业务层状态机已经挡住大部分非法流转但上线初期难免有人手贱直接改数据库状态「救火」或者某个入口绕过了 BLL 直接执行 UPDATE。我习惯再让数据库层兜底一道在 T_Order 上挂一个 AFTER UPDATE 触发器状态字段变化时自动往 T_OrderStatusLog 写一条记录。有了它哪怕有人用 SSMS 直接改状态也会留下痕迹。CREATE TRIGGER trg_Order_StatusLog ON T_Order AFTER UPDATE AS BEGIN SET NOCOUNT ON; INSERT INTO T_OrderStatusLog (OrderId, OldStatus, NewStatus, Remark, CreateTime) SELECT i.Id, d.Status, i.Status, CASE WHEN i.Status -1 THEN 系统侧直接取消 ELSE 数据库层状态变更 END, GETDATE() FROM inserted i INNER JOIN deleted d ON i.Id d.Id WHERE i.Status d.Status; END;逻辑说明inserted 和 deleted 是 UPDATE 触发的两张逻辑表inserted 保存更新后的新值deleted 保存更新前的旧值。WHERE i.Status d.Status 能过滤掉那些改了个其他字段、状态没变的 UPDATE避免日志表被无意义数据灌满。注意这个触发器只做记录、不做拦截真正的流转约束仍靠 BLL 层规则表触发器是黑匣子而不是裁判。日志表会持续增长计划任务里每周清理一次三个月前的成功日志即可。6.2 每日体检 SQL用一条查询找出金额对不上的订单状态日志只能说明流程走了不能证明数据对得上账。我还有个习惯是每天跑一遍「订单金额一致性体检」把所有订单主表的应收金额和明细表逐行小计比对差一分钱都要暴露出来。这样在顾客投诉前就能发现问题而不是等月底对账时被商家质问。SELECT o.Id AS 订单号, o.TotalAmount AS 应收, ISNULL(SUM(d.SubTotal), 0) AS 实算 FROM T_Order o LEFT JOIN T_OrderDetail d ON o.Id d.OrderId GROUP BY o.Id, o.TotalAmount HAVING ABS(o.TotalAmount - ISNULL(SUM(d.SubTotal), 0)) 0.01;如果这条查询返回任何行说明订单金额和明细不一致优先检查下单事务里 SubTotal 和 TotalAmount 的计算逻辑其次是是否有手工改金额的旁路。把这个 SQL 挂在第 6.1 节那个计划任务里一起跑结果输出成文本文件我习惯让系统在启动时检查这个文件有异常直接在托盘区弹红点提醒。做过两套类似系统的经验是上下线最容易出问题的就是漏算配送费、满减没进明细、退款改了状态却没记日志这三类问题靠这张体检 SQL 基本都能在第二天上班前发现。希望这个组合能帮你的外卖系统在交付后少踩几个半夜救火的坑。本文还有配套的精品资源点击获取
