企业官网建设流程全解析

简介：一份面向C#课程设计的学校食堂订餐系统完整项目文档，适合计算机相关专业学生、需要完成C/S架构课程设计或毕业设计的开发者参考。文档围绕系统需求分析、概要设计、详细实现与测试评估展开，核心采用C/S结构，借助Socket进行客户端与服务端消息传递，并应用多线程、多任务思想构建服务器。客户端功能覆盖浏览菜品、点菜订餐与评分、个人资料管理、投诉留言；服务端支持顾客信息、菜单、订单、管理员信息等模块管理，并包含数据库设计、数据流图、界面原型等关键内容。资源以单个doc文件形式打包，大小795KB，内容为完整课程设计文稿，可对照开发环境Visual Studio .NET与SQL Server进行实际搭建。目前已有794人浏览学习，适合需要快速理解食堂订餐系统整体架构、模块划分及C#网络编程实现思路的读者，可直接作为课程设计文档模板或功能扩展基础。

1. 学校食堂订餐系统：C#课程设计绕不开的经典题型

“C#课程设计学校食堂订餐系统”这个题目，在课程设计选题表里的出现频率高到几乎成了C#基础综合能力的“结业考”。它不像图书管理那样只练增删改查，也不像聊天室那样要碰网络编程，难度正好落在“已经入门C#、刚拖过WinForms控件、数据库语法半熟不熟”的区间。做完它，集合、委托、事件、LINQ、数据库连接、界面交互全都被串起来用了一遍。这篇笔记从数据模型、界面搭建、并发校验讲到答辩加分，目标是让照着做的人能复现出一套能演示、能讲清、能扛住提问的系统。

2. 从表结构到ORM选型：把订餐业务落进数据库

2.1 角色与菜品：四张核心表怎么拆

设计数据库时，多数人犯的第一个错误是“一张表走天下”，把用户名、菜品名、订单号全塞进一张表，字段越加越多，查询越来越慢。订餐系统的业务不复杂，常规拆法就是四张表：Users（用户）、Dishes（菜品）、Orders（订单主表）、OrderItems（订单明细）。用户和订单是一对多，一个学生能下多单；订单与明细是一对多，一单能点多个菜；菜品与明细是一对多，一个菜能出现在多张订单里。这样拆完，“查某个学生今天点了哪些菜”就是两次JOIN的事。

这是我的建表脚本（SQL Server），课程设计拿去改字段名就能用：

CREATE TABLE Users ( UserId INT IDENTITY(1,1) PRIMARY KEY, UserName NVARCHAR(20) NOT NULL, Password NVARCHAR(50) NOT NULL, Role INT NOT NULL DEFAULT 0, -- 0学生 1窗口 2管理员 RealName NVARCHAR(20), CreateTime DATETIME DEFAULT GETDATE() ); CREATE TABLE Dishes ( DishId INT IDENTITY(1,1) PRIMARY KEY, DishName NVARCHAR(50) NOT NULL, Price DECIMAL(8,2) NOT NULL, WindowId INT NOT NULL, -- 所属窗口的用户ID Stock INT NOT NULL DEFAULT 0, -- 当日库存，0则前端禁点 Status INT NOT NULL DEFAULT 1 -- 1上架 0下架 ); CREATE TABLE Orders ( OrderId INT IDENTITY(1,1) PRIMARY KEY, OrderNo NVARCHAR(30) NOT NULL, -- 业务单号，展示用 UserId INT NOT NULL, -- 下单学生 TotalPrice DECIMAL(10,2) NOT NULL, Status INT NOT NULL DEFAULT 0, -- 见状态机枚举 CreateTime DATETIME DEFAULT GETDATE() ); CREATE TABLE OrderItems ( ItemId INT IDENTITY(1,1) PRIMARY KEY, OrderId INT NOT NULL, DishId INT NOT NULL, Quantity INT NOT NULL, SubTotal DECIMAL(10,2) NOT NULL );

逻辑说明：Role用int存而不是字符串列，方便登录后按数字分发窗体，也方便以后扩展角色数量。Dishes里的WindowId关联的是Users表的UserId，业务含义是“这个菜属于哪个窗口”，在User表里Role=1的那批人就是窗口账号。金额字段全部用DECIMAL，算总和不会出现二进制浮点误差，ORDER BY TotalPrice时排序也稳定。

参数说明：IDENTITY自增主键适合单机课程设计，但OrderNo在界面展示时不要用自增ID，我在代码里一般生成yyyyMMddHHmmss+随机三位数，可读性好，也不会让用户一眼看出订单总量。Stock字段是当天份数，课程设计阶段可以让管理员在菜品管理里手动维护，不用做定时重置；报告里提一句“生产环境应加每日库存快照”就够了。

不要在Orders表里冗余存“用户名、窗口名”，存ID再JOIN。新手总觉得“直接把窗口名写进订单表多方便”，但窗口改名之后历史订单里的名字就错了。用ID关联，改名只改Users表一处，订单自动跟着变。答辩时老师问范式，这就是第三范式的现场案例。

2.2 订单状态机：五个状态怎么流转

订单表里的Status如果直接写数字，读代码的人得猜“0是什么”。C#里最舒服的写法是先定义枚举，再在业务层转换：

public enum OrderStatus { Pending = 0, // 已提交，待窗口接单 Accepted = 1, // 窗口已接单，备餐中 Ready = 2, // 出餐完成，待取餐 Completed = 3, // 已取餐 Canceled = 4 // 已取消 }

状态流转的规则要提前定死，这是整个系统最容易乱的地方。学生提交订单，状态只能是Pending；窗口端只对Pending状态的订单做操作：接单变Accepted，拒单直接Canceled；备餐完成后变Ready；取餐后变Completed。取消操作必须限定在Pending状态，Accepted之后就不允许学生单方面取消，否则窗口已经备好餐，学生一取消，饭就砸在窗口手里。

我给学生审代码时见过一个反面案例：取消订单直接执行DELETE删除。这样窗口端正在做菜，突然查不到这张单，后厨一片混乱。正确做法是把状态置为Canceled，数据还在，窗口端能看到“已取消”而不会继续备餐。状态机说白了就是把现实中食堂的业务规则翻译成代码里的状态转移表，课程设计报告里画一张状态图，老师对这块的印象分会明显上去。

2.3 EF Core还是ADO.NET：选型不翻车

这是课程设计里必须先定的技术路线。学校机房如果允许装NuGet包、联网拉依赖，优先EF Core：代码量少一半，表结构改动时不用手动同步SQL语句，答辩提“ORM”也是加分项。如果机房是离线环境，或者你的课程设计报告明确要求展示原生SQL语句，那就老老实实用ADO.NET（SqlConnection + SqlCommand），别为了追新把自己卡在装包这一步。

用EF Core写DbContext很简单：

public class FoodDbContext : DbContext { public DbSet<User> Users { get; set; } public DbSet<Dish> Dishes { get; set; } public DbSet<Order> Orders { get; set; } public DbSet<OrderItem> OrderItems { get; set; } protected override void OnConfiguring(DbContextOptionsBuilder options) { options.UseSqlServer( @"Server=.;Database=CampusFood;Trusted_Connection=True;TrustServerCertificate=True;"); } }

逻辑说明：DbSet对应数据表，EF Core会在首次运行时按实体类自动建库建表（配合EnsureCreated或Migrate）。如果你从ADO.NET转过来，会明显感觉到实体类和数据库表一一对应，写查询时不用再拼字符串。

参数说明：连接字符串里Server=.表示本机默认实例，如果接的是命名实例要写成localhost\SQLEXPRESS格式。TrustServerCertificate=True这行，是SQL Server 2019及以上版本常见的坑，不加它本地连接也可能报证书链错误；如果老师机房还是2008或2012，这行可以去掉。不想装SQL Server的话，把包换成Microsoft.EntityFrameworkCore.Sqlite，连接字符串改成Data Source=CampusFood.db，实体类一行不用动，整套系统就能变成单文件绿色版，拷到哪台演示机器都能跑。

选型的另一个判断维度是看这门课偏“数据库课程设计”还是偏“程序设计”。偏数据库的课，老师想看到手写SQL和范式分析，用ADO.NET对着报告更好讲；偏软工或C#的课，用EF Core能把精力花在业务逻辑上。我带课设时一般建议：报告有SQL加分项，就ADO.NET；报告只要求“实现系统”，就EF Core。

3. 用WinForms搭起订餐主流程：登录、点餐与订单刷新

3.1 登录与角色分发：一个登录窗体跳三个主界面

WinForms项目里第一个窗体就是登录窗。放两个TextBox一个按钮，查询Users表，密码正确后把UserId和Role存到静态类里，再按Role打开不同的主窗体。这里不要Close掉登录窗，Hide就行，学生退出登录回到登录页时不必重新创建窗体。

public static class CurrentUser { public static int UserId { get; set; } public static int Role { get; set; } public static string Name { get; set; } } private void btnLogin_Click(object sender, EventArgs e) { string sql = "SELECT UserId, RealName, Role FROM Users WHERE UserName=@u AND Password=@p"; using (SqlConnection conn = new SqlConnection(connStr)) { SqlCommand cmd = new SqlCommand(sql, conn); cmd.Parameters.AddWithValue("@u", txtUserName.Text.Trim()); cmd.Parameters.AddWithValue("@p", txtPassword.Text.Trim()); conn.Open(); SqlDataReader reader = cmd.ExecuteReader(); if (reader.Read()) { CurrentUser.UserId = reader.GetInt32(0); CurrentUser.Name = reader.GetString(1); CurrentUser.Role = reader.GetInt32(2); OpenMainFormByRole(CurrentUser.Role); } else { MessageBox.Show("用户名或密码错误"); } } } private void OpenMainFormByRole(int role) { Form mainForm = role switch { 0 => new StudentForm(), 1 => new WindowForm(), 2 => new AdminForm(), _ => throw new InvalidOperationException("未知角色") }; mainForm.Show(); this.Hide(); }

逻辑说明：CurrentUser静态类是全局会话状态的载体，后续所有窗体读当前登录人就用它。参数化查询避免SQL注入，答辩时老师问“输入单引号会不会崩”，就靠这段回答。OpenMainFormByRole里用的switch表达式是C# 9语法，如果学校用VS2017编译会报错，那就改回if-else。

参数说明：AddWithValue虽然方便，但对“用户名”这种字符串字段，更严谨的写法是new SqlParameter("@u", SqlDbType.NVarChar, 20)显式指定类型。课程设计阶段AddWithValue够用，但报告里提一句“生产环境建议显式指定参数类型”，老师会觉得你考虑过ADO.NET的隐性类型转换问题。密码这里是明文比对，被问到就说“生产环境应使用哈希加盐存储”，能把话题圆回来。connStr是窗体级字段，课程设计直接写死在代码里可以；如果你愿意多做一步，放到App.config的connectionStrings里，算是加分细节。

三个主窗体之间的公共代码（比如LoadOrders）建议抽到公共类或基类里，别在三个窗体里各写一份数据库查询，否则后面改表结构要改三个地方。WinForms虽不像Web有那么多分层约束，但把“数据访问”“业务逻辑”“界面”分开写，是你跟别人代码拉开差距的第一步。

3.2 点餐联动：选择菜品、数量与金额的实时计算

学生端主界面左侧是菜品列表（DataGridView），右上角放NumericUpDown设置份数，右下角显示单价和小计。用户切换选中行时，单价跟着变；调数量时，小计实时重算；点“加入订单”时，把当前行的信息做成OrderItem对象加到购物车List里。

private void dgvDishes_SelectionChanged(object sender, EventArgs e) { if (dgvDishes.CurrentRow == null) return; decimal price = Convert.ToDecimal(dgvDishes.CurrentRow.Cells["Price"].Value); lblPrice.Text = price.ToString("F2"); UpdateSubtotal(); } private void UpdateSubtotal() { int qty = (int)numQuantity.Value; decimal price = Convert.ToDecimal(lblPrice.Text); lblSubtotal.Text = (price * qty).ToString("F2"); } private void btnAddToCart_Click(object sender, EventArgs e) { DataGridViewRow row = dgvDishes.CurrentRow; if (row == null) return; OrderItem item = new OrderItem { DishId = Convert.ToInt32(row.Cells["DishId"].Value), DishName = row.Cells["DishName"].Value.ToString(), Price = Convert.ToDecimal(row.Cells["Price"].Value), Quantity = (int)numQuantity.Value }; cartItems.Add(item); BindCartGrid(); UpdateTotalAmount(); }

逻辑说明：这里的cartItems是窗体级字段List<OrderItem>，这就是C#数组和集合区别的典型场景——数组长度固定，List 可以动态Add，购物车条目数不确定，用集合正合适。SelectionChanged事件在用户切换选中行时触发，显示当前菜价；UpdateSubtotal把价格与份数相乘，显示成两位小数。

参数说明：Convert.ToDecimal在单元格值是DBNull时会抛异常，所以读取前先判CurrentRow为null。更保险的写法是if (row.Cells["Price"].Value is DBNull) continue;。份数用NumericUpDown而不是TextBox，从控件层面就拦截了负数、字母、小数份数这三种非法输入，比在按钮事件里写正则省事。金额用ToString("F2")保证8.5显示成8.50，界面不会出现金额长短不一的问题。

提交订单时，要把购物车里的数据一次性写入数据库，而不是每点一次“加入”就往数据库插一条。课程设计里的订单提交应该是一个事务——插入订单主表、插入订单明细、扣减库存三件事要么全成功要么全失败。这个流程放第5章细讲，这里先提醒一点：提交成功后要清空cartItems并重新拉取订单列表，不然学生连续下两单，第二单会把第一单的菜一起提交进去。

3.3 订单列表：数据源绑定与刷新时机

DataGridView是WinForms里最常用的表格控件。要显示订单列表，最常见的是两种做法：把DataTable直接赋给DataSource，或者在内存构造List 再绑定。两者课设里都能用，但有个重要区别：DataTable绑定自带列排序能力，而List 绑定后如果列表内容变了，界面不会自动感知，必须重新给DataSource赋值。这个坑展开在第4章讲，这里先给出标准写法：

public void LoadOrders(int userId) { string sql = @" SELECT OrderNo, CreateTime, CASE Status WHEN 0 THEN '待接单' WHEN 1 THEN '备餐中' WHEN 2 THEN '待取餐' WHEN 3 THEN '已完成' WHEN 4 THEN '已取消' END AS StatusText, TotalPrice FROM Orders WHERE UserId=@userId ORDER BY CreateTime DESC"; DataTable dt = new DataTable(); using (SqlConnection conn = new SqlConnection(connStr)) { SqlDataAdapter adapter = new SqlDataAdapter(sql, conn); adapter.SelectCommand.Parameters.AddWithValue("@userId", userId); adapter.Fill(dt); } dgvOrders.DataSource = dt; }

逻辑说明：SQL语句里直接用CASE把状态数字翻译成中文，比在C#代码里再写一串if省事。SqlDataAdapter.Fill一次把数据灌进DataTable，赋给DataGridView后自动显示所有列。默认情况下列头就是数据库列名，想改成好读的中文，直接在SELECT里写别名：OrderNo AS 订单号。

参数说明：LoadOrders在窗体Shown事件里调用一次，保证窗体显示时列表是最新的；同时它应该是public方法，因为订单状态在其他窗体改完后要回调它来实现刷新。比如窗口端把订单置为“已完成”，回到学生端时调用LoadOrders(CurrentUser.UserId)重新拉一遍。数据量小，同步调用不会卡界面；如果订单量上千或者查询变慢，再考虑用Task.Run包装，这就是c# task的用法介入的时机，课设阶段不要提前优化。

列显示顺序也常让人头疼。DataGridView启用AutoGenerateColumns时，列顺序由SELECT顺序决定；如果想让序号、时间、金额固定排布，可以关掉自动生成列，在设计器里手动加DataGridViewTextBoxColumn并绑定DataPropertyName。这个方法比动态调整Columns索引稳定，网格列多了之后基本是必选项。

4. 订餐系统课程设计避坑：编译、连接与数据刷新实录

4.1 连接字符串只在开发机生效，换台电脑就连不上

现象：在自己电脑上程序跑得正常，整个项目文件夹拷到教室或答辩机器上，一登录就报“建立到服务器的连接时发生错误”或者“找不到指定的服务器实例”。

原因：连接字符串写死了Server=localhost\SQLEXPRESS，目标机器要么没装SQL Server，要么实例名不叫这个，要么数据库文件根本没跟过去。这套环境问题在课程设计答辩里出现频率极高，属于典型的本地玄学。

解决：演示环境分两种。如果答辩机器固定装好了SQL Server，提前去改连接字符串里的实例名就行。如果环境不确定，我建议把数据库切换到SQLite，连接字符串变成Data Source=CampusFood.db，把.db文件放在项目输出目录，整个文件夹拷走就能跑，不用装服务、不用配账号。EF Core切到SQLite只换Provide包和连接串，实体类完全不用动，课设阶段这是性价比最高的后悔药。

除了连接方式，还要注意SQL Server的认证模式。有的机器只开了Windows身份验证，连接字符串里写User ID=sa;Password=...就连不上；反之亦然。我一般让学生在连接字符串里用Trusted_Connection=True，至少保证在班里大部分电脑上能跑通。

4.2 DataGridView绑了List<T>，更新数据后界面纹丝不动

现象：窗口端点“接单”后，数据库里Status字段确实从0变成了1，但界面上的DataGridView那一行还是显示“待接单”，除非重启程序。

原因：List<T>没有实现INotifyPropertyChanged接口，控件不会监听集合里某个对象属性的变化。数据库变了，但内存里的绑定源没通知控件重绘。

解决：最简单可靠的办法是数据操作成功后重新绑定一次：改完Status后调用LoadOrders(CurrentUser.UserId)重新查询再赋DataSource。每次刷新都重新查数据库，课设阶段数据量小，性能根本不是问题，别用“避免重复查询”当借口绕过自动刷新需求。刷新方法如果被多个按钮调用，就封装成一个公共方法，别各写各的。

重新绑定还有一个副作用：CurrentRow会回到第一行，如果学生正在看第三行，刷新后跳到第一行。课设阶段可以接受；要保留选中行的话，刷新前记录dgvOrders.CurrentRow.Index，刷新后设置dgvOrders.Rows[oldIndex].Selected = true;。

4.3 ComboBox绑定List<User>，下拉显示的是类全名

现象：给下拉框绑定窗口用户列表，运行时下拉框里每一行显示的都是CampusFood.Model.User这种命名空间全名，而不是窗口真名。

原因：ComboBox默认调用对象的ToString()方法，你定义的User类没有重写ToString，CLR只能把默认的类型全名字符串打出来。

解决：绑定后立即指定DisplayMember和ValueMember：

List<User> windows = GetWindowUsers(); comboBoxWindow.DataSource = windows; comboBoxWindow.DisplayMember = "RealName"; // 下拉显示的名字 comboBoxWindow.ValueMember = "UserId"; // 选中后取到的ID int windowId = Convert.ToInt32(comboBoxWindow.SelectedValue);

逻辑说明：GetWindowUsers()是查询Users表里Role=1的辅助方法，返回List 。DisplayMember对应类里的public属性名，ValueMember是选中后comboBoxWindow.SelectedValue要拿到的值。选中项不要用SelectedItem强转再取属性，直接用SelectedValue拿ID，省一次类型转换。

参数说明：赋值顺序别搞反，先设DataSource，再设DisplayMember和ValueMember。反过来的话偶发显示空白，排查起来很费劲。如果列表需要显示“窗口名（编号）”这种组合文本，就在User类里加一个只读属性public string DisplayText => $"{RealName}({UserId})";，然后DisplayMember指向它。

4.4 跨窗体传值的新手坑：new出来的窗体拿不到登录用户

现象：从学生主窗体打开“我的订单详情”窗体时，传过去的UserId是0，查询结果为空。

原因：登录用户ID存在登录窗体的局部变量里，登录窗体Hide后不销毁，但新窗体访问不到那个局部变量，代码里也找不到公开属性可以读。

解决：最好的做法是用静态类CurrentUser（见3.1节）保存会话数据，任何窗体直接读CurrentUser.UserId，不用构造函数传值。如果两个窗体要做实时联动，比如订单列表窗体要通知点餐窗体“某个菜库存不够了”，这时才轮到C#委托和事件出场——在源窗体上声明一个事件，目标窗体订阅它，比互相持有窗体引用解耦得多。课程设计里的传值九成用静态类就能解决，但如果你在报告里写了“使用事件实现窗体通信”，这个亮点值得体现。

还有一个隐性坑：事件订阅后没退订。源窗体关闭时事件仍挂在目标窗体上，目标窗体再次打开时事件会触发两次，出现莫名重复执行。习惯是在FormClosed事件里做-=退订，这个细节写进报告能展示你对事件生命周期的理解。

5. 并发与校验：让订餐系统在饭点流量下站稳

5.1 库存扣减：一条UPDATE解决超卖

食堂订餐系统的峰值出现在饭点前半小时，几百个学生同时点同一道热门菜，如果代码是“先查库存、够就扣、不够提示”，两个请求同时读到库存为1，都会认为“够”，最后库存变成-1，这就是超卖。避免超卖最稳的土办法，是让扣库存这一件事在数据库层面完成：

private bool TryReduceStock(SqlTransaction tran, int dishId, int qty) { string sql = "UPDATE Dishes SET Stock = Stock - @qty WHERE DishId=@id AND Stock >= @qty"; SqlCommand cmd = new SqlCommand(sql, (SqlConnection)tran.Connection, tran); cmd.Parameters.AddWithValue("@qty", qty); cmd.Parameters.AddWithValue("@id", dishId); return cmd.ExecuteNonQuery() > 0; }

逻辑说明：UPDATE语句自带行锁，两个并发请求同时执行这条SQL时，只有一个会更新成功，另一个在等待锁释放后重算发现Stock不满足条件，影响行数为0，返回false。你拿到false就可以提示“库存不足”并回滚整个订单事务。这比“SELECT查库存再用if判断”可靠一个量级，代码量只有几行。

参数说明：事务对象tran由订单主流程创建后传进来，同一个事务里执行扣库存、插入订单主表、插入订单明细，三件事要么全部提交要么全部回滚，不能出现“库存扣了但订单没生成”的中间状态。事务用完必须Commit或Rollback，我习惯在try/catch/finally里保证每个分支都收尾，而不是在catch里只弹个提示就放过去。

事务不是“让三个操作变快”，而是“让三个操作要么都发生要么都不发生”。扣库存失败回滚后，前面插入订单主表那条语句产生的影响也必须回滚，否则订单表里会出现一条没有明细、库存却少了的脏数据。

5.2 输入校验：在前端就把脏数据拦住

用户输入不可信，这条在WinForms里同样成立。所有从TextBox进数据库的字段，都要过一遍校验。最朴素的写法是：

private bool ValidateDishInput() { if (string.IsNullOrWhiteSpace(txtDishName.Text)) { MessageBox.Show("菜名不能为空"); txtDishName.Focus(); return false; } if (!decimal.TryParse(txtPrice.Text, out decimal price) || price <= 0) { MessageBox.Show("价格必须是大于0的数字"); txtPrice.Focus(); return false; } if (txtDishName.Text.Length > 20) { MessageBox.Show("菜名不能超过20个字符"); return false; } return true; }

逻辑说明：TryParse比Convert.ToInt32/ToDecimal安全，用户输入“abc”时Convert会抛FormatException，TryParse直接返回false走提示分支。校验顺序上把“空值检查”放最前面，“格式检查”次之，“范围检查”最后，这样用户在一处错误修正后不会马上撞上下一处错误，体验更好。

参数说明：长度上限要和数据库字段定义一致。表里NVARCHAR(20)就限制20个字符，否则界面上输入30个字的菜名，写入数据库时报“将截断字符串或二进制数据”，这条报错信息很难看懂。去掉字符串两端空白用Trim，在用户名和密码输入时尤其重要，很多人输密码时多按了一个空格，比对失败还找不到原因。

5.3 全局异常与日志：程序崩了，至少留下证据

WinForms默认遇到未处理异常会弹一个难看的错误对话框然后进程退出。课程设计要求不高，但至少有两点要做到：一是把异常信息留到日志文件里，二是别让异常直接闪退。做法是在Main方法里挂全局异常事件：

[STAThread] static void Main() { Application.SetUnhandledExceptionMode(UnhandledExceptionMode.CatchException); Application.ThreadException += (s, e) => { File.AppendAllText( "error.log", $"[{DateTime.Now:yyyy-MM-dd HH:mm:ss}] {e.Exception.Message}\r\n{e.Exception.StackTrace}\r\n"); MessageBox.Show("程序发生未处理的异常，详细信息已写入error.log"); }; Application.Run(new LoginForm()); }

逻辑说明：ThreadException捕获UI线程上的未处理异常，AppDomain.UnhandledException接管非UI线程的崩溃。课程设计里的多线程场景不多，但异步刷新偶尔会踩到，两个事件都挂上更稳。日志文件路径默认是程序当前工作目录，如果程序被快捷方式从其他目录启动，写文件可能撞上权限不足，课设演示时一般遇不到，但真实环境很常见。

参数说明：日志追加用File.AppendAllText而不是File.WriteAllText，后者每次覆盖会丢掉前面的痕迹。时间戳格式yyyy-MM-dd HH:mm:ss精确到秒，挺够用了。答辩时老师说“你的程序崩了”，你能打开error.log翻栈信息，比空口解释强一百倍。

6. 验收前的冲刺：统计图表、CSV导出与答辩自检

6.1 用Chart控件画一周销量柱状图

WinForms自带Chart控件（System.Windows.Forms.DataVisualization.Charting），不用引第三方包就能画柱状图。把Orders按天分组统计数量，绑定到Series的Points，再设置ChartType=Column，一个“近7日订餐量趋势”就出来了。这个小功能代码量不到20行，却是老师最容易一眼看到的亮点。

6.2 订单导出CSV：让Excel能直接打开

导出CSV是“系统能对接外部”的最简单证明。按顺序拼每列的值，字段间用逗号分隔，行尾加\r\n，用Encoding.UTF8写入文本文件再改扩展名为.csv，就能被Excel直接打开。如果想让财务按时间归档，用Substring截取订单号前8位日期段作为文件名后缀，这个字符串截取写法顺手也演示了C#处理文本的能力。注意字段里如果含逗号或换行，要用双引号包起来，否则导出的表格会列错位。

6.3 答辩自检：五个必答问题提前备好

我每次帮学生预演答辩，必问这五个：数据库为什么拆四张表；订单状态为什么用int不用字符串；密码为什么用参数化查询；库存怎么防止同时下单超卖；系统有哪些不足。前四个从第2、4、5章里就能找到答案，最后一个不要回“没有不足”，老老实实说“库存每日重置未自动化、密码明文存储、未做多窗口分类筛选”，然后补一句“如果继续做，我会优先解决这三项”，老师对有自知之明的回答印象更好。

这几年带课设，我见过太多代码写得很顺、答辩却因为紧张把项目讲砸的同学。我的习惯是把整个项目跑一遍录成短视频，答辩前自己看一遍，哪些页面加载慢、哪些按钮会手抖，心里有数，真上台的时候反而从容些。希望帮到你。

本文还有配套的精品资源，点击获取