很多人学C#都卡在同一个地方：语法书翻完了，视频课刷完了，收藏夹里躺着一堆“C#入门到精通”，打开Visual Studio却不知道写点什么。这种状态我太熟悉了，不是不努力，而是把“看懂”错当成了“会写”。C#的语法糖很多，foreach、LINQ、async/await看起来都明白，可真遇到一个需求，你根本不知道用哪个、怎么组合。这就是典型的“假性掌握”。

这篇文章想聊的，就是怎么用一套有章法的练习，把C#从“认识它”变成“驾驭它”。我会结合自己带新人、做项目时的练习思路，从热身项目讲到面向对象实战，再到我自己踩过的坑，给出一份可以照着做的练习方案。适合刚学完基础语法却不知道怎么进阶的初学者，也适合写了一两年业务代码、想回头补一补基本功的朋友。

1. 为什么书看懂了，一写代码就卡住：练习的底层逻辑

1.1 看懂只是“输入”，练习才是“输出”

你回想一下学骑自行车的经历。看再多的教学视频，听再多的平衡技巧，都不如自己扶上车把蹬两圈。那个过程中一定会歪、会倒、会紧张，但正是这些“不顺利”教会了你真正的控制感。写代码也一样，C#的知识点本质上是一堆“关于操作的语言描述”，你读懂了它们，只代表信息进入了大脑，不代表你能在需要的时候把它们调用出来。

这里有一个著名的学习金字塔理论：听讲和阅读的知识留存率大概只有5%到10%，而亲自实践、动手操作的知识留存率可以到75%甚至更高。这个差距在编程上特别明显。我见过很多朋友用“我看完了某本书”来描述学习成果，可一让他独立写个小工具，连using该写哪几个都要翻半天。这就是因为整个学习过程只有“输入”，没有“输出”。

所以C#练习的第一步，不是再多找一门课，而是逼自己进入“输出模式”。每学一个知识点，立刻写一个小程序去用一下。学了循环，就写一个求质数的控制台程序；学了类和对象，就做一个学生成绩管理的小模型。哪怕写出来的代码很幼稚，只要是你自己从零敲出来的，它就会在大脑里留下一条真实的神经通路，下次遇到类似需求时，那条路会自己亮起来。

1.2 练习的三层境界：抄写、改造、创造

我给新手练C#时，通常把练习分成三个层次。这三个层次不是割裂的，而是循序渐进的。

第一层是“抄写”。跟着教程把代码敲一遍，甚至直接从书里抄到IDE里，先让它跑起来。很多人觉得抄代码没有意义，其实不是，抄写的核心目的是熟悉手感：熟悉IDE的快捷键、熟悉代码缩进和命名规范、熟悉“写完一段代码后按 F5 运行”这个基本循环。抄写时要注意一件事——不要整段复制粘贴，要一个字符一个字符地敲，并且边敲边想“这行在干什么”。

第二层是“改造”。把抄来的代码做个改头换面。比如教程里写了一个求和的函数，你把它改成求平均值；教程里用List<int>存数据，你改成List<string>然后自己处理排序。改造的妙处在于，你已经有了一个正确的参照物，一旦改坏了还可以对照原版找问题。这个层次的练习能帮你理解代码的“可拆解性”，明白哪些地方是可替换的，哪些地方是结构核心。

第三层才是“创造”。从空白文件开始，只有一句话需求：“给我写一个猜数字游戏”“给我写一个命令行的待办事项本”。不查参考实现，遇到不会的就去查文档、查MSDN，但绝对不搜成品源码。自己设计类的结构、方法的划分、数据的存储方式。这一层才能真正暴露你的薄弱点，通常也是从“学习者”变成“能做东西的人”的转折点。

1.3 完成比完美重要：第一个粗糙的原型价值

我见过太多人栽在一个地方：学了三个月C#，一个完整的项目都没写完。不是他不会，而是总觉得自己的代码“太丑”“不够规范”“没有用设计模式”。这种完美主义是练习的大敌。

你知道吗，软件行业有一句老话叫“先让它跑起来，再让它跑得好”。你在练习阶段，最重要的目标不是写出一份教科书级的优雅代码，而是得到一个可以运行、可以操作、可以看到输出的东西。哪怕它没有注释，哪怕它的命名全是a1、a2，哪怕它所有的逻辑都堆在Main函数里——只要它跑起来了，你就完成了练习中最难的部分：把脑子里的想法翻译成机器能执行的动作。

那个粗糙原型是你接下来所有优化工作的基础。没有原型，谈架构是空中楼阁；有了原型，你才能真实地感觉到哪些地方别扭，为什么要拆分方法，为什么需要类。这种“从实践中提炼出的为什么”，比任何设计原则都更有说服力。

2. 环境选型和热身练习：从Hello World到“会交互的小程序”

2.1 开发工具的理性选择：Visual Studio、VS Code还是Rider

工欲善其事，必先利其器。但关于C#的开发工具，网上的争论很吵，我这里直接给结论。

我的建议很直接：如果你是纯新手，用的是Windows，老老实实装Visual Studio Community。免费、够用、网上绝大多数教程的截图都基于它，你遇到问题搜起来也好搜。如果你用的是Mac或者Linux，或者更喜欢轻量工具，VS Code搭配.NET SDK完全够用，只是第一次建项目时多几句命令行的事，比如dotnet new console -n MyProject，然后code MyProject就能打开。

有一点想提醒你：不要在“选哪个工具”上花超过半天时间。工具只是载体，C#语法和. NET类库才是真正要练的东西。我见过有人折腾IDE主题和插件花了一个星期，却连一个for循环都没写利索，这就是舍本逐末。

2.2 热身练习：让Hello World“活”起来

每个教程的基础都属于Hello World，但大多数人在打印完那一行文本后，就把控制台程序扔到一边了。其实控制台程序是练C#基础语法的最佳场地，因为它没有UI干扰，焦点全在逻辑上。

下面这个热身练习，我管它叫“会自我介绍的机器人”。它只用了变量、输入、输出和字符串插值，但信息量不小：

Console.Write("请输入你的名字："); string name = Console.ReadLine() ?? "匿名用户"; Console.Write("请输入你的出生年份："); bool isInt = int.TryParse(Console.ReadLine(), out int birthYear); if (!isInt) { Console.WriteLine("你输入的年份格式不对，请重新运行程序。"); return; } int age = DateTime.Now.Year - birthYear; Console.WriteLine($"你好，{name}！我猜你今年大约{age}岁。");

这个程序的第一个价值是练习字符串插值（$""）和ReadLine。第二个价值是引入了一个非常实用的函数：int.TryParse。很多新手写转换直接用的是int.Parse，一旦用户输入的不是数字，程序直接崩溃。而TryParse返回的是bool，配合out参数可以优雅地处理输入错误。这个“要不要学”的小选择，就是经验型程序员和纯语法型新手的差距。

练完这个，再往上加变化：包一个while循环，让用户按q才能退出，否则可以一次问多个人的年龄；再改一改，统计一下问过多少人，平均年龄是多少。就这样一步一个台阶，你实际上已经碰到了状态管理、循环控制和累积计算，这些全是编程的基本功。

2.3 带着问题理解变量与类型：值类型、引用类型和垃圾回收

热身练习里，你会反复用到string、int这些类型。这时候就该认真理解一组核心概念：值类型、引用类型，以及. NET的垃圾回收机制。

用生活类比来解释：值类型（int、bool、double，还有自定义struct）像写在便利贴上的数字。你把便利贴递给别人，别人拿到的是抄下来的副本，你在原便利贴上改数字，不影响对方手里的。引用类型（string、数组、class实例）则像一把钥匙，钥匙指向一个公共的储物柜。你把钥匙复制给别人，两个人打开的是同一个柜子，你往柜子里放了东西，别人再打开就能看到。这个区别在写代码时非常重要，比如：

int a = 10; int b = a; b = 20; Console.WriteLine(a); // 输出10，因为b只是a的副本 var list1 = new List<int> { 1, 2, 3 }; var list2 = list1; list2.Add(4); Console.WriteLine(list1.Count); // 输出4，因为list1和list2指向同一个List对象

至于垃圾回收，你不用管它会准确在哪个时机收回对象，只需要建立一种直觉：当没有任何变量再引用一个对象时，这个对象就“没人管了”，.NET的垃圾回收器会在某个时候把它扫走，释放内存。所以你在练习时，如果发现内存一直上涨，通常不是忘了释放内存，而是某个集合里一直在添加对象，导致对象始终被引用、无法回收。这个直觉能帮你省下很多排查性能问题的力气。

3. 练习项目一：控制台记账本，用最土的办法搞定持久化

3.1 需求拆解：不要一上来就写代码

我从这一节开始，会带你把两个经典练习项目完整过一遍。先来看第一个：控制台记账本。

很多新手拿到这类需求，第一个念头是“打开IDE，撸起袖子写Main”。这是要改的。正确做法是先做需求拆解，哪怕只是花十分钟在纸上列一列：这个程序要做什么，不做什么。我给自己列的需求是：

• 用户可以录入一笔账目，要能区分收入还是支出，比如支出为正、收入为负，或者反过来；
• 每笔账目要记录金额、说明文字、发生时间；
• 支持查询：列出所有账目，按时间倒序排；
• 支持统计：算出一个时间段内的总收入和总支出；
• 程序关闭后，数据要留着，下次打开还能看到。

第五条很关键，它引出了“持久化”。一开始你可以只把数据存在内存里，也就是List里面，但你很快会发现，程序一关数据全没了。这时候自然就会想到写文件、读文件。这也是我给新手推荐这个项目的原因——它逼着你从内存走向文件，而不是一上来就上数据库。

3.2 从结构体到List再到文件存储：代码骨架

第一版模型很简单，用结构体或者类都行。我建议先练结构体，等这个项目做完，你再拿着去和类做对比，体会会更深刻：

public enum BillType { Income, // 收入 Expense // 支出 } public struct BillRecord { public BillType Type; public decimal Amount; public string Description; public DateTime Time; }

为什么金额用decimal而不是double或float？这是C#里一个非常经典的知识点：二进制无法精确表示所有小数，double在做金额运算时会出现0.1+0.2=0.30000000000000004之类的误差。记账软件哪怕差一分钱都是事故，所以必须用decimal，它专门为十进制精确计算设计。这种选型的判断力，光看书是学不来的，只有你把那个0.1+0.2打印出来、吓了一跳，才会终身不忘。

主程序里用List<BillRecord>来装账目，接收用户输入并添加记录。然后是文件持久化，我用最原始的写法，用StreamWriter把每条记录拼成一行文本：

string filePath = "bills.txt"; void SaveAllBills(List<BillRecord> bills) { using var writer = new StreamWriter(filePath); foreach (var bill in bills) { writer.WriteLine($"{bill.Type}|{bill.Amount}|{bill.Description}|{bill.Time:yyyy-MM-dd HH:mm}"); } } List<BillRecord> LoadAllBills() { var result = new List<BillRecord>(); if (!File.Exists(filePath)) return result; foreach (var line in File.ReadLines(filePath)) { var parts = line.Split('|'); if (parts.Length != 4) continue; var record = new BillRecord { Type = Enum.Parse<BillType>(parts[0]), Amount = decimal.Parse(parts[1]), Description = parts[2], Time = DateTime.Parse(parts[3]) }; result.Add(record); } return result; }

这里用using var是一个比较新的C#写法，它的效果是当代码块结束时自动调用Dispose，也就是自动关闭文件流。你以后看老项目会经常见到using (var writer = ...)包裹一个代码块的写法，两者等价，但using var更简洁。写练习时把两种都试一遍，再看代码时就不会一头雾水了。

3.3 用户乱输入、文件损坏怎么办：异常处理练习

记账本这个项目，最不缺的就是输入异常。用户要输入金额，可能输入"abc"；输入日期，可能输入"2023年13月"；文件里的某一行因为手动编辑被改坏了，程序一解析就崩。这些都是绝佳的练习素材。

处理用户输入，前面已经练过int.TryParse，这次金额用decimal.TryParse，日期用DateTime.TryParseExact。前者比Parse好在不抛异常，后者比DateTime.TryParse好在可以严格指定格式，免得用户输入什么样你都猜。

处理文件坏行，我建议的做法是“坏的跳过，好的保留”。那几行在解析时用try-catch包住，一旦FormatException或OverflowException出现，就打印一个警告，然后continue继续下一行：

try { var record = ParseLine(line); result.Add(record); } catch (FormatException) { Console.WriteLine($"发现一条格式错误的数据，已跳过：{line}"); } catch (OverflowException) { Console.WriteLine($"发现一条数值越界的数据，已跳过：{line}"); }

不要把整个文件读取放进一个try-catch然后啥也不做干瞪眼，也不要把所有异常类型都写成catch (Exception)然后假装无事发生。练习阶段就养成“捕获特定异常、做最小处理”的习惯，会让你以后少写很多藏着Bug的代码。你在这个项目里练出的异常处理思维，放到ASP.NET Core里就是各种全局异常过滤器的基础。

4. 练习项目二：图书馆借阅系统，在实战中体会面向对象

4.1 从“数据”到“对象”：类和接口的第一次深度使用

记账本那个项目做下来，你的代码大概率是一堆函数加一个全局List，这没问题，因为它是面向过程的写法。但C#是一门强面向对象语言，第二个项目就该升级了。

图书馆借阅系统是经典中的经典。需求无非是：有书、有会员、能借书、能还书、能查谁借了什么书。你先别管数据库和UI，就在控制台里做。我建议你在动手前，先画一个简单的类图，用文字也行：

Book：Id, Title, Author, IsBorrowed, BorrowedByMemberId Member：Id, Name, BorrowedBooks(列表) LoanRecord：BookId, MemberId, BorrowDate, ReturnDate ILibraryService：AddBook, AddMember, BorrowBook, ReturnBook, ListOverdueLoans

这里我特别想让你体会的是接口（interface）的作用。很多新手觉得接口就是“把方法声明抽出来，然后再写一个类去实现，多此一举”。但你想想，如果以后你要把这个系统从控制台版本升级成带UI的版本，或者从内存存储升级成数据库存储，你会怎么做？

如果你把所有的借书逻辑都写在LibraryService这个具体类里，那UI层需要直接引用它，升级存储方案时可能得改一大堆UI代码。但如果你面向接口编程，让UI只依赖ILibraryService，那将来你写一个DatabaseLibraryService或者MemoryLibraryService，只要它们都实现同一个接口，UI层就别想动。这就是“对扩展开放、对修改封闭”的开闭原则，用接口是最朴素的实现方式。

4.2 用集合管理实体关系：Dictionary和List的分工

图书借阅系统里有一个经典查询需求：给定一个会员ID，立刻查出他借了哪些书；给定一本书ID，立刻查出它被谁借走了。用List也能实现，但每次都要遍历一遍，数据量一大就很笨拙。这时候Dictionary就登场了。

public class LibraryService : ILibraryService { private Dictionary<string, Book> _books = new(); private Dictionary<string, Member> _members = new(); private List<LoanRecord> _loans = new(); public bool BorrowBook(string bookId, string memberId) { if (!_books.TryGetValue(bookId, out var book)) throw new ArgumentException("书本不存在"); if (!_members.TryGetValue(memberId, out var member)) throw new ArgumentException("会员不存在"); if (book.IsBorrowed) return false; book.IsBorrowed = true; book.BorrowedByMemberId = memberId; _loans.Add(new LoanRecord(bookId, memberId, DateTime.Now, null)); return true; } }

Dictionary查找的时间复杂度是O(1)，List遍历是O(n)。在图书管理这种场景，用字典按ID找书，几乎是唯一的正确选择。同时你要理解集合之间为什么要分工：书和会员的映射关系用字典，借阅流水这种天然按时间序列增长的数据用List。这种选择不是死记硬背，而是你真正动手写增删改查时，哪个顺手哪个别扭，瞬间就会有体感。

4.3 给系统加一个“催还提醒”：委托和时间的魔法

基础版做完了，我建议你给自己加一个进阶需求：找出所有超期未还的借阅记录，发一条模拟提醒。这里你能学到两个新东西：时间计算和事件通知。

public List<Book> GetOverdueBooks(int maxDays) { var cutoff = DateTime.Now.AddDays(-maxDays); var overdueBooks = new List<Book>(); foreach (var loan in _loans.Where(l => l.ReturnDate == null)) { if (loan.BorrowDate < cutoff) { if (_books.TryGetValue(loan.BookId, out var book)) overdueBooks.Add(book); } } return overdueBooks; }

这段代码用LINQ的Where过滤了已经归还的记录，然后逐条比较日期。DateTime直接做减法，差值是一个TimeSpan类型，你也可以用(DateTime.Now - loan.BorrowDate).TotalDays来判断超期天数。

委托和事件可以玩得更深：定义一个OverdueNotificationEventHandler，当发现一本书超期时，触发一个事件，事件可以挂上多个处理方法，比如一个方法发短信、一个方法发邮件。这就是观察者模式的雏形。你不需要在这个阶段把它做得多标准，但只要你亲手写出了“某个条件满足时，程序自动通知其他模块去做事”的感觉，后面再看ASP.NET Core里的中间件、事件总线这些概念，你都会觉得似曾相识。

5. 练习路上的高频坑：空引用、线程阻塞和装箱陷阱

5.1 NullReferenceException：C#新手的“一生之敌”

如果统计C#新手遇到最多的运行时错误，NullReferenceException绝对排第一，意思是“你调用的这个对象是null，没有实际内容”。

产生这个异常的场景千奇百怪，但本质就一个：你已经声明了一个引用类型变量，但没有给它赋值为真实对象。比如：

Member member = null; Console.WriteLine(member.Name); // 崩溃：NullReferenceException

排查这种异常，我的习惯是三步走。第一步，看异常堆栈，找到是哪一行的什么变量崩了。第二步，在那个变量赋值处下断点，鼠标悬停看它的值是不是null。第三步，往上追为什么是null——是没初始化，还是某个方法返回了null，还是集合里根本没有这个键导致TryGetValue返回了false。

从代码习惯上，有几种办法能大幅降低空引用出现频率。一是多用null条件运算符，也就是?.：member?.Name，如果member是null，整个表达式的结果就是null而不是抛异常；二是用??给个兜底值：string name = member?.Name ?? "未知用户";；三是启用C#的可空引用类型特性，在项目文件里加一句<Nullable>enable</Nullable>，那么编译器会在你写着string name却不允许null的地方给警告，逼你在声明时就想清楚这个变量允不允许null。这些特性不是新语法糖那么简单，它们是帮你把“运行期崩溃”变成“编译期警告”，代价小、收益大。

5.2 async/await的滥用与死锁

学了异步编程基础后，很多人会陷入“到处async”的状态，然后踩进一个很隐蔽的坑：死锁。

先记住一个原则：async void只能在事件处理器里用，其他地方一律用async Task。为什么？因为async void方法的异常无法被调用方捕获，一旦抛出就直接打到线程池，程序会毫不留情地崩溃。而async Task的异常可以被await捕获，行为可预测。

另一个经典误用是用.Result或.Wait()去阻塞等待一个异步任务。在UI程序里，这非常容易造成死锁——因为你阻塞了UI线程，但异步任务的后续部分恰恰需要回到UI线程上继续执行，于是UI线程等着任务，任务等着UI线程，双方互相等，程序就卡死了。正确做法是从头到尾用await，让控制流自然地在异步状态机中流转：

// 错误示范，可能造成UI死锁 var content = httpClient.GetStringAsync(url).Result; // 正确做法 string content = await httpClient.GetStringAsync(url);

你自己练习时，可以故意写一个.Result的UI程序，点一个按钮看它转圈，然后注释掉换成await，感受一下差别。这种“亲手把代码卡死再修好”的经历，比任何文章都能让你记住异步的规则。另外提醒一句，控制台程序的Main函数不能直接await，需要写成static async Task Main(string[] args)，这是C# 7.1后面的语法，教科书里容易漏。

5.3 装箱与拆箱：看不见的性能杀手

装箱（boxing）是指把一个值类型（比如int）转换成引用类型（比如object），这个过程会在堆上创建一个新对象；拆箱则反过来。它们在语法上都能通过，但每次装箱都伴随着内存分配，循环里如果频繁发生，程序性能会肉眼可见地变差。

最常见的“元凶”是遗产代码里的ArrayList和Hashtable，它们存储的是object，所以你往里塞int时就已经装箱了。现在写C#，泛型集合List<T>、Dictionary<TKey,TValue>就是为消灭装箱而生的，你应该默认用它们。还有一个隐蔽的装箱点是字符串拼接：

string result = "数量：" + 42; // 编译器会做装箱/ToString转换 string better = $"数量：{42}"; // 本质是调用ToString，不装箱

说实话，在绝大多数业务系统里，装箱带来的性能损耗不会成为瓶颈，你不需要为了省一次装箱去把代码写得很扭曲。但练习的意义在于，你要能“看见”这些隐藏的操作。我推荐你在写循环的时候搜一下C#的BenchmarkDotNet这个库，选两个写法做个性能对比测试。当你看测试报告里一次次计时数字的差距，那种直观冲击比任何“性能优化指南”都管用——它让你对所有类似问题形成真正的敏感度。

6. 下一步：按你的目标安排练习路线

6.1 三条主路：桌面开发、Web后端、游戏开发

C#的最大特点就是应用领域特别宽，所以练完基础项目后，最该做的事是根据目标倒推练习路线。方向选错了，很容易学几个月觉得没意思然后放弃。

第一条路是Windows桌面应用开发。技术栈通常是WinForms或WPF，数据层可以用EF Core加SQLite或SQL Server。练习项目可以从图书管理系统的桌面版升级开始，给它加个窗口界面、加个表格，你会觉得之前学的控制台逻辑直接搬过来就行。这个方向适合想快速做出“看得见、摸得着”软件的朋友，也适合企业内部工具类开发。

第二条路是Web后端，也是目前最主流的方向。技术栈是ASP.NET Core Web API、EF Core、RESTful API设计、身份认证、部署等。练习项目的节奏可以这样：先写一个简单的待办事项API，实现增删改查；然后给它加用户注册登录，用JWT做认证；再然后加数据库、加日志、加异常处理中间件。这条路的知识面相对广，但每一层都能在实际工作中找到对应场景。

第三条路是游戏开发，用Unity配合C#。练习路径围绕游戏引擎里的MonoBehaviour生命周期、物理碰撞、场景加载、动画状态机展开，和前面两条路的思维方式差别很大。如果你对游戏感兴趣，C#是你进入Unity的最低门槛，没有之一。

6.2 每个阶段的“毕业设计”

与其永远跟在教程后面走，不如给自己定一个阶段性的“毕业设计”。我的建议是这样划分：

阶段一（基础语法完成）：做一个控制台版贪吃蛇。要求是蛇能移动、能吃食物、碰墙或碰自己会结束、分数能显示。这个项目会逼你把键盘输入、游戏循环、坐标计算、集合操作全都串起来，做完后你对基础语法的掌握程度会上一个台阶。

阶段二（面向对象与文件/数据库完成）：做一个带文件存储的图书管理系统，或者记账本的完整版。要求至少有三到五个类、用接口隔离核心逻辑、数据能持久化、错误输入能被优雅处理。完成后你就具备了独立编写“小工具级”程序的能力。

阶段三（选定方向完成）：桌面方向做一个带UI的客户管理工具；Web方向做一个带数据库的博客系统后端；游戏方向做一个有完整玩法的2D小游戏。做完后你就真的可以说自己“能用C#做开发”了。

这三个阶段的核心逻辑是：每完成一个作品，你手中就多一块“能给别人看的实据”。去面试、去参与开源项目、去和同行交流，展示项目永远比说“我读过XX书”更有说服力。练习本身的价值是内化的能力，而这些作品是能力的外在证据。

我个人练C#这几年，最大的体会是：练习不是在“学完之后”才发生的事，它本身就是学习的一部分。把练习项目拆小、做多、反复改，比追求“把一本书啃完”有效得多。我还特别建议你为自己的练习代码开一个Git仓库，哪怕只有你自己看，每完成一个小版本就提交一次。过三个月再回头看最初那个只会打印Hello World的程序，你会真切地看到自己的成长曲线，那种正反馈是持续学下去最稳定的动力。