简介：这份资源面向C#初学者与希望夯实基础的开发者，汇集30个由浅入深的经典练习项目，覆盖变量与流程控制、函数与类对象、面向对象封装继承多态、事件与委托驱动的窗体界面、ADO.NET数据库增删改查，以及async/await异步编程与LINQ集合查询等主题，帮助读者在动手编码中把语法知识转化为实际功能。压缩包共598个文件，约1.06MB，以148个cs源码、31个csproj工程与31个sln解决方案为主，配合exe、pdb、resources、resx等编译与界面资源，以及txt说明、config配置和少量doc文档，完整保留各项目的工程结构，便于逐个打开调试与二次修改。目前已有1661人学习下载。读者可据此按主题挑选项目练手，对照源码理解类设计、事件响应与数据访问的实现思路，逐步积累可复用的编码经验。
1. 从“看得懂语法却写不出东西”说起：C# 经典小项目合集到底解决什么问题
很多人学完 C# 基础语法后卡在同一个地方：变量、循环、类、委托都能看懂，但打开 Visual Studio 新建项目，光标闪了半天不知道第一行写什么。这不是能力问题，是缺少“从需求到可运行程序”的中间层训练。这套 C# 经典小项目合集，正是填这个坑的——它把控制台工具、窗体应用、文件处理、简单游戏、数据管理等常见练手场景拆成一个个能独立跑通的小工程，每个工程都带完整代码和注释。适合两类人：正在做课程设计、需要快速攒出几个能演示的项目的学生，以及想用碎片时间把 C# 手感捡回来的从业者。下面按“需求怎么定、结构怎么搭、代码怎么写、坑怎么避、最后怎么验收”这条线，把整套方案讲透。
2. 项目选型与总体结构：五个小工程覆盖四类核心能力
2.1 为什么选“小项目群”而不是一个大系统
单个大系统对初学者不友好：模块耦合多、调试链路长，一个编译错误能卡一整天。小项目群的好处是每个工程只聚焦一两个知识点，跑通一个就有一份正反馈。这套合集通常按能力维度切分，我一般会把它归成四类：基础语法与逻辑训练（计算器、猜数字、九九乘法表）、面向对象与集合操作（图书管理、学生成绩统计）、文件与数据处理（日志分析、CSV 读写、文本统计）、界面与事件驱动（WinForms 窗体小工具）。四类之间难度递进，但彼此独立，可以按任意顺序练。
选型上有个反直觉的点：不要一上来就做带数据库的完整管理系统。数据库连接、ORM 配置、迁移脚本会把注意力从 C# 语言本身拉走。先用内存集合（List<T>、Dictionary<K,V>）把业务逻辑写顺，等逻辑稳定了再换持久化，这个顺序能少踩很多坑。
2.2 工程目录与命名约定
合集里每个小项目建议独立成一个解决方案下的多个项目，或者干脆一个项目一个文件夹。目录结构我习惯这样组织：
CSharpClassicDemos/ ├── 01_Calculator/ # 控制台计算器 │ ├── Program.cs │ └── Calculator.cs ├── 02_GuessNumber/ # 猜数字游戏 ├── 03_StudentScore/ # 成绩统计（集合 + LINQ） ├── 04_TextAnalyzer/ # 文本统计（文件 IO） └── 05_WinFormTool/ # 窗体小工具（事件驱动）命名上，类名用 PascalCase，私有字段用_camelCase，方法名动词开头。这些约定看着琐碎，但课程设计答辩时老师一眼就能看出代码是不是有组织。每个工程配一个简短的 README，写清“这个项目练什么、怎么运行、输入输出是什么”，后面验收环节会用到。
2.3 技术栈边界：只用到哪些东西
这套合集刻意把技术栈压到最小：.NET 6 及以上（或与课程要求匹配的 .NET Framework 版本）、C# 10 左右的语言特性、控制台 + WinForms 两种宿主、System.IO与System.Linq两个核心命名空间。不引入第三方 NuGet 包，不碰网络请求，不接数据库。这样做的原因是：小项目的价值在于把语言基本功练扎实，依赖越少，出问题时越容易定位到是自己的代码还是环境。
提示：如果课程要求必须用某个特定 .NET 版本，先确认
TargetFramework配置，再动手写代码。版本不匹配导致的编译错误，排查成本远高于改配置。
3. 核心模块实现：从控制台逻辑到窗体事件的三段式落地
3.1 控制台逻辑层：计算器与猜数字的输入校验
控制台项目最容易翻车的地方不是算法，是输入校验。用户输入字母、空串、超范围数字，程序直接抛异常崩掉，演示时非常尴尬。稳妥的做法是把“读输入”和“解析”分开，解析失败就重试，而不是让异常冒到顶层。
// Calculator.cs —— 带输入校验的四则运算核心 public static class Calculator { // 解析用户输入的数字，失败返回 false 并给出提示 public static bool TryReadNumber(string prompt, out double value) { Console.Write(prompt); string? input = Console.ReadLine(); // 用 TryParse 而不是 Parse，避免输入非法时抛异常 if (double.TryParse(input, out value)) return true; Console.WriteLine("输入不是有效数字，请重新输入。"); return false; } // 根据运算符分发计算，除零单独处理 public static double? Compute(double a, double b, char op) { return op switch { '+' => a + b, '-' => a - b, '*' => a * b, '/' => b == 0 ? null : a / b, // 除零返回 null，由调用方提示 _ => null }; } }这段代码的关键点有三个：TryParse替代Parse是输入健壮性的第一道防线；switch表达式让运算符分发比一长串if-else清晰；除零返回null而不是抛DivideByZeroException，把错误处理权交给调用方，控制台层就能统一打印友好提示。猜数字项目同理，核心是“生成随机数 → 循环读猜测 → 比较大小给提示 → 命中退出”，随机数用Random.Shared.Next(1, 101)，循环里同样用TryParse兜底。
3.2 集合与 LINQ 层：成绩统计的查询写法
成绩统计项目练的是List<T>和 LINQ。定义一个Student类，字段包括姓名、学号、三门课成绩，然后用 LINQ 做平均分、排名、及格率统计。这里的设计要点是：把“数据”和“查询”分开，数据用集合装，查询用链式 LINQ 表达，不要在一个for循环里把所有统计揉在一起。
public record Student(string Name, string Id, int Chinese, int Math, int English) { // 计算属性：总分与平均分，避免重复计算逻辑散落各处 public int Total => Chinese + Math + English; public double Average => Total / 3.0; } public static class ScoreAnalyzer { public static void Report(List<Student> students) { // 按平均分降序排名，取前三 var top3 = students.OrderByDescending(s => s.Average).Take(3); // 统计各科及格率（>=60 视为及格） double chinesePassRate = students.Count(s => s.Chinese >= 60) * 100.0 / students.Count; // 按总分分组，观察分数段分布 var distribution = students .GroupBy(s => s.Total / 30) // 每 30 分一档 .OrderBy(g => g.Key); Console.WriteLine("前三名：" + string.Join("、", top3.Select(s => s.Name))); Console.WriteLine($"语文及格率：{chinesePassRate:F1}%"); foreach (var g in distribution) Console.WriteLine($"{g.Key * 30}-{g.Key * 30 + 29} 分：{g.Count()} 人"); } }record在这里比class合适，因为学生数据是不可变的值语义对象，with表达式改成绩也方便。Total和Average写成计算属性，避免在多个地方重复写Chinese + Math + English。LINQ 链式调用里，OrderByDescending、Take、Count、GroupBy是最常用的四个操作，把这四个练熟，大部分统计需求都能覆盖。参数上注意Average用3.0而不是3，否则整数除法会把小数部分截掉，这是血泪经验。
3.3 文件 IO 层：文本统计的流式读取
文本统计项目要求读一个文本文件，统计行数、单词数、字符数、出现频率最高的词。小文件直接File.ReadAllLines没问题，但合集里通常会放一个稍大的日志文件来练流式读取。设计上分两步：读取用StreamReader逐行处理，统计用Dictionary<string, int>累加词频。
public static class TextAnalyzer { public static (int lines, int words, int chars) Analyze(string path) { int lines = 0, words = 0, chars = 0; var freq = new Dictionary<string, int>(StringComparer.OrdinalIgnoreCase); // using 确保文件句柄释放，避免文件被占用 using var reader = new StreamReader(path); string? line; while ((line = reader.ReadLine()) != null) { lines++; chars += line.Length; // 按空白与常见标点切词，去掉空项 var tokens = line.Split(new[] { ' ', '\t', ',', '.', ';', '!' }, StringSplitOptions.RemoveEmptyEntries); words += tokens.Length; foreach (var t in tokens) freq[t] = freq.GetValueOrDefault(t) + 1; } var top = freq.OrderByDescending(kv => kv.Value).FirstOrDefault(); Console.WriteLine($"行数 {lines}，词数 {words}，字符数 {chars}"); Console.WriteLine($"最高频词：{top.Key}（{top.Value} 次）"); return (lines, words, chars); } }using var是 C# 8 之后的写法，作用域结束自动Dispose，比手写try-finally干净。StringComparer.OrdinalIgnoreCase让词频统计不区分大小写，符合自然语言统计的直觉。GetValueOrDefault省掉了“先判断键是否存在”的样板代码。切词用Split加RemoveEmptyEntries是简化版方案，真实场景分词更复杂，但作为练手项目足够，重点是理解“流式读取 + 字典累加”这个模式。
3.4 窗体事件层：WinForms 小工具的控件与事件绑定
WinForms 项目的价值在于理解事件驱动模型。一个典型小工具是“单位换算器”或“简易记事本”：界面上放输入框、按钮、结果标签，按钮的Click事件里做计算或文件保存。设计要点是控件命名规范（txtInput、btnConvert、lblResult）和事件处理逻辑与界面分离。
// MainForm.cs —— 单位换算器的按钮事件 private void btnConvert_Click(object sender, EventArgs e) { // 输入校验：空值或非数字直接提示，不进入计算 if (!double.TryParse(txtInput.Text, out double meters)) { lblResult.Text = "请输入有效数字"; return; } // 换算逻辑抽到独立方法，界面层只负责取值和显示 double feet = UnitConverter.MetersToFeet(meters); lblResult.Text = $"{meters} 米 = {feet:F2} 英尺"; } // UnitConverter.cs —— 纯逻辑，可单独单元测试 public static class UnitConverter { private const double FeetPerMeter = 3.28084; public static double MetersToFeet(double m) => m * FeetPerMeter; }把换算逻辑抽到UnitConverter静态类，好处是界面代码只做“取值—调用—显示”三件事，逻辑可以脱离窗体单独测试。事件处理里先校验再计算，避免用户输入字母时程序抛异常。控件命名带前缀（txt、btn、lbl）是 WinForms 的老规矩，答辩时老师看代码能快速定位哪个控件对应哪段逻辑。
4. 避坑与常见问题：五个最容易翻车的点
4.1 现象：程序编译通过但运行闪退
原因通常是控制台项目里抛了未捕获异常，或者 WinForms 项目在构造函数里访问了尚未初始化的控件。解决方式：控制台项目在Main外层包一层try-catch打印异常信息；WinForms 项目把控件初始化逻辑放在InitializeComponent()之后，不要在字段初始化器里引用控件。
4.2 现象：文件读取报“文件被另一进程占用”
原因是StreamReader或File.ReadAllText用完没释放句柄，或者调试时上一次运行没退出。解决方式：所有文件操作统一用using声明，确保Dispose被调用；调试时先确认没有残留进程，必要时在任务管理器里结束。
4.3 现象：LINQ 查询结果和预期不一致
常见原因是延迟执行：var query = list.Where(...)只是定义了查询，真正遍历时才执行，如果中间修改了list，结果会变。解决方式：需要立即快照时加.ToList()；另外注意整数除法陷阱，Average计算里分母写成3.0而不是3。
4.4 现象：WinForms 界面在高分屏上模糊或控件错位
原因是项目没有声明 DPI 感知，或者用了绝对坐标布局。解决方式：在项目属性里启用 PerMonitorV2 DPI 感知，布局优先用TableLayoutPanel、FlowLayoutPanel和Anchor/Dock，少用固定Location和Size。
4.5 现象：随机数每次运行都一样
原因是每次new Random()时间隔太短，种子相同。解决方式：用Random.Shared（.NET 6+）或把Random实例提升为静态字段复用，不要在循环里反复new Random()。
注意：以上五条里，文件句柄未释放和整数除法是最隐蔽的两个，前者表现为偶发报错，后者表现为结果“差一点点”，排查时优先怀疑这两处。
5. 验收与答辩：怎么证明这套小项目真的跑通了
验收这套合集，不能只看“能编译”。我一般按三层来验：第一层是功能层，每个项目列出输入输出用例，逐条手动跑一遍，比如计算器要覆盖正常四则运算、除零、非法输入三种情况；第二层是代码层，检查是否有未处理的异常路径、文件句柄是否释放、命名是否规范；第三层是演示层，准备一段三分钟的现场演示脚本，按“打开项目 → 说明练什么 → 演示一个正常流程 → 演示一个异常流程 → 展示关键代码”的顺序走。
下面这张表可以直接当验收清单用：
| 项目 | 必测用例 | 通过标准 |
|---|---|---|
| 计算器 | 加减乘除、除零、字母输入 | 不崩溃，有友好提示 |
| 猜数字 | 猜大、猜小、猜中、非数字 | 提示准确，可重开一局 |
| 成绩统计 | 空列表、单人、多人排名 | 排名与及格率计算正确 |
| 文本统计 | 空文件、正常文件、含标点 | 行数词数准确，高频词正确 |
| 窗体工具 | 正常换算、空输入、非数字 | 界面不卡死，提示清晰 |
答辩时有个技巧：主动讲一个你踩过的坑和怎么解决的，比背功能列表更能体现你真的动手写过。比如“我一开始用Parse读输入，演示时输入字母直接崩了，后来改成TryParse并加了重试循环”，这种细节老师一听就知道代码是你自己写的。另外，把每个项目的 README 和运行截图整理成一页纸的说明，答辩时递过去，比口头描述省时间。
从那以后我每次带人做小项目，都强制要求先写验收用例再写代码，跑不通用例就不算完成。这套 C# 经典小项目合集的价值不在于代码多复杂，而在于它把“需求—实现—验收”这个闭环压缩到了每个工程都能在一两天内走完的尺度，练完一轮，再面对课程设计或实际交付，心里就有底了。希望帮到你。
本文还有配套的精品资源，点击获取
