别人的总结都是“我学了啥”我这次想换个角度聊聊“我踩了哪些坑、绕了哪些弯、最后怎么把C#用顺手的”。如果你正处于从语法入门向真正写业务逻辑过渡的阶段或者正准备用C#做点实际的东西这篇总结应该能帮你省下不少时间。这已经是我第四次系统性地复盘C#了。每次做总结我都会把前一个阶段写的代码翻出来重读一边读一边冒冷汗——很多当时觉得“挺好啊”的写法现在看来要么绕远路要么埋了雷。其实C#这门语言语法不算难难的是用对它的设计模式和思维范式。这次总结我打算换个思路不列知识点清单而是按照“从会写到写对再到写得有设计感”这条主线把我觉得最值得记录的东西拆开揉碎讲清楚顺便把那些文档里查不到、只有实际动手才撞得上的经验一起放进来。1. 整体思路复盘第四次总结到底在总结什么1.1 为什么说这个阶段是“从语法到设计”的分水岭前三次总结的时候我的状态基本是今天学会了类怎么定义明天搞明白了继承怎么用后天发现接口原来可以这么解耦。知识是零散的遇到什么问题就搜什么方案像拼图一样东一块西一块。写出来的代码能用但你让我说清楚“为什么这么设计”我往往答不上来。到了第四次总结我发现自己最明显的变化是不再纠结单个语法点了而是开始关注代码之间的组织方式、变更时的连锁反应、以及一个功能从需求到落地的完整路径。举个例子以前写一个订单服务我会直接new一个订单对象塞上数据往数据库里一怼就完事。但现在我会先想这个订单模块未来会不会换存储是不是有别的系统要订阅订单状态变化如果是那构造函数里直接依赖具体数据库上下文的方式就可能出问题。这其实就是C#学习一个很微妙的分水岭当你开始问“怎么改更好”“这里解耦一下会不会更稳”而不是“这个功能怎么写”的时候说明你已经从语法层面跃迁到了设计和架构层面。第四次总结本质上就是给这个跃迁做一个阶段性的记录。1.2 这次复盘的核心主线对象、集合、异常、调试四件事我把这次复盘的内容分成四条主线对象设计的高级用法、集合与LINQ的实战技巧、异常处理的最佳实践、以及调试与排错的经验沉淀。为什么选这四个方向因为我发现这就是日常开发中碰到的四类最常见的场景。对象设计决定代码的结构骨架集合和LINQ决定数据操作的表达方式异常处理决定系统的健壮边界调试排错决定你解决问题的效率。四次迭代下来这四块是我感触最深、也是踩坑最多的地方。这一篇我就按这个顺序把关键的点一个个展开说。2. 核心细节解析对象设计的高级用法和底层逻辑2.1 属性、字段和构造函数这些基础里藏着设计感所有C#的教程都会教你定义属性Property、字段Field和构造函数。但真正把这三者组合出设计感的很少。我理解的设计感不是花哨而是让代码不容易被误用。先看字段和属性的取舍。很多人习惯把所有数据全写成public字段图省事。但这样做的副作用是字段的读写完全没有控制。比如一个订单对象订单金额如果允许外部随意set那等于任何人都能把100块的订单改成0块。正确的做法是需要对外暴露的数据一律用属性并且尽量把set设为private或init只有类内部使用的状态才用私有字段。属性里还有一个容易被忽略的玩法——计算属性。我以前会把折扣价算好存在数据库里后来发现这纯属给自己找麻烦。存冗余字段意味着你得维护数据一致性一旦折扣规则变了历史数据全部要刷一遍。更好的方案是用只读计算属性public class Order { public decimal OriginalPrice { get; set; } public decimal DiscountRate { get; set; } public decimal FinalPrice OriginalPrice * DiscountRate; }这样价格永远是实时算出来的不会出现“原始价改了但折扣价忘了更新”这种荒唐事。至于构造函数我最大的体会是必要参数必须通过构造函数传入不要留一个无参构造函数然后再靠一堆属性赋值。否则你根本无法保证对象创建完是完整可用的状态。实操经验定义类的时候先问自己三个问题——哪些数据是外部必须提供的哪些数据是内部私有的哪些数据可以被推导而不是存储把这三个问题想清楚类设计的干净程度至少提升一个档。2.2 继承与多态用对地方是神器用错地方是灾难继承可以说是C#里最容易被滥用、也最容易被误解的机制。我早期的错误是“为了复用代码而继承”比如我有一个邮件发送类后来要做短信发送就把共同逻辑抽到父类里让两个子类去继承。看起来省了代码实际上耦合得一塌糊涂。因为邮件和短信虽然都是“发送消息”但它们的生命周期、协议、异常处理方式差异很大硬往一个继承体系上靠导致父类里全是if分支判断类型越改越乱。现在我更倾向于遵循一个原则继承只用于“is-a”关系而不是“has-code-in-common”关系。如果两个类有公共逻辑优先用组合把一个公共的服务类通过构造函数注入进去。这一点在C#里尤其重要因为它有接口Interface这个更灵活的工具。多态方面我踩过最深的一个坑是用switch判断子类类型来做不同处理。这种写法看着直观但每增加一个新子类就要去改switch违反了开闭原则。正确姿势是把行为定义成父类的抽象方法或接口方法让子类各自实现public abstract class NotificationSender { public abstract void Send(string message); } public class EmailSender : NotificationSender { public override void Send(string message) { // 邮件发送逻辑 Console.WriteLine($Email: {message}); } } public class SmsSender : NotificationSender { public override void Send(string message) { // 短信发送逻辑 Console.WriteLine($SMS: {message}); } }调用端只需要依赖抽象基类后续新增通知渠道时不需要改任何已有代码只要新增一个继承类即可。这在思路上是完全不同的不用“告诉程序具体怎么做”而是“告诉程序有什么可以做具体行为由具体对象自己决定”。2.3 接口解耦的第一步别等架构师教你自己就会用C#的接口我第一次学的时候觉得它就是“定义方法的空壳”没什么实际意义直到写单元测试时才品出它的价值。当你依赖具体类的时候测试里想模拟一个假的服务非常困难但当你依赖接口时你可以随手写一个Mock实现替换掉真实依赖。这个体验上的差距是巨大的。接口的设计我推荐遵循“接口隔离原则”别把一堆不相干的方法塞进同一个接口。比如你定义了一个IUserService里面有登录、注册、改头像、绑定手机号、导出发送报表后两个明显就是多余的负担。拆成IUserAuthentication和IUserProfile按需让不同的类去实现整个系统会轻盈很多。还有一点C#的接口支持默认实现Default Interface Methods这也算C# 8之后一个比较实用的增强。默认实现允许你在接口里写带方法体的方法这样当接口新增方法时已有的实现类可以不用立刻改。但使用起来还是要克制因为它本质上让接口位置从纯契约走向了部分实现过度使用会模糊接口的语义。2.4 记录类型与模式匹配让代码更简洁的两个现代C#特性C# 9引入了记录类型recordC# 8开始不断强化的模式匹配Pattern Matching这俩放在一起写数据模型和分支逻辑时体验极佳。记录类型我最大的使用场景是DTO和数据模型的定义。它天然支持值的相等性比较不需要重写Equals和GetHashCode。我最喜欢的是with表达式可以方便产出副本public record ProductDto(int Id, string Name, decimal Price); var product new ProductDto(1, 键盘, 99); var updatedProduct product with { Price 89 };模式匹配方面我以前写业务判断习惯一串if-else既啰嗦又容易漏。现在用switch表达式Switch Expression或者属性模式会简洁很多public string GetDiscountLabel(decimal price) price switch { 1000 大客户价, 500 批发价, 0 零售价, _ 免费 };这种写法不仅短而且把“匹配规则”直接放到一起逻辑一目了然。编译器还会帮你检查穷尽性少了一个分支就会给出警告比手写if漏掉一个判断稳妥太多。3. 实操过程集合操作与LINQ的日常落地3.1 List、Dictionary、HashSet怎么选知道底层实现才不纠结C#的集合类有好几种List、Dictionary、HashSet、Queue、Stack、LinkedList各有适用的场景。很多人没仔细看底层导致用错数据结构结果性能差了一个数量级。List底层是动态数组适合按索引访问但如果你经常在中间插入删除元素每一次操作都要搬动后续元素时间复杂度是O(n)。LinkedList虽然链表插入删除快但你要查某个元素只能从头遍历实际项目里位置访问远多于插入删除所以我很少推荐在业务代码里用LinkedList。Dictionary内部是哈希表查询接近O(1)但它不保证元素顺序。HashSet本质上是只存储键不存储值的Dictionary适合做去重和集合运算比如判断某个值是否存在、求交集并集差异集。这些场景用List去逐个ContainsO(n)的代价在数据量小的时候无所谓数据量一大就能明显感觉到卡顿。我目前的选型原则有序可重复且需索引 → List键值对快速查找 → Dictionary去重和集合逻辑 → HashSet先进先出 → Queue后进先出 → Stack。搞清楚这几种集合的适用边界写代码的时候就不用琢磨了。3.2 LINQ不是炫技是让意图自己说话LINQ是最能提升C#编码幸福感的功能之一。我刚学的时候觉得链式写法很花哨后来才意识到它的核心价值是把“怎么做”变成“做什么”。举一个特别常见的场景从订单列表里取出金额大于100的订单按时间排序取前十条。如果你用foreach去写代码是这样的var result new ListOrder(); foreach (var order in orders) { if (order.Amount 100) { result.Add(order); } } result.Sort((a, b) a.CreatedAt.CompareTo(b.CreatedAt)); var top10 result.GetRange(0, Math.Min(10, result.Count));用LINQ之后变成var top10 orders .Where(o o.Amount 100) .OrderBy(o o.CreatedAt) .Take(10) .ToList();两种写法功能完全一样但第二种可读性高出太多。特别是当筛选条件复杂时链式方法名称本身就构成了语义哪怕三个月后再回来看这段代码也不用在循环里逐个推演。使用LINQ有几个需要特别注意的坑。第一个是延迟执行IEnumerable的查询不是马上执行的只有当你真正遍历或者调用ToList/ToArray等终端操作时才会执行。这意味着如果你对一个IEnumerable查询了两遍实际会执行两遍查询逻辑。对大集合来说这可能带来不必要的性能损耗。第二个是Select、Where等操作会引入额外的对象分配在超高频调用路线上建议减少LINQ链式操作改用传统的for循环更合适。第三是尽量在数据库查询层面就做好筛选和排序别把全表拉回内存再用LINQ过滤这属于最后一道防线。3.3 用表达式树理解LINQ的延迟执行与翻译机制很多人只把LINQ当作集合扩展方法其实它的底层分两种形态委托委托型LINQ to Objects和表达式树型LINQ to Something比如数据库。to Object时Where接收的是一个Func委托运行时直接执行而数据库型LINQWhere接收的是Expression表达式树框架会把这棵树解析翻译成SQL语句再交给数据库执行。理解这个区别你就明白为什么EF Core里查询条件写成item item.Age 18就能生成对应的WHERE子句而如果你在里面调用一个自定义函数EF Core往往无法翻译直接抛异常。我第一次遇到这个报错时还很懵后来才想明白本质原因表达式树需要能被解析成SQL自定义函数没有对应的SQL映射自然不可能翻译。所以在写查询条件时尽量让表达式保持简单可翻译复杂逻辑可以先从数据库取数到内存再做二次处理。4. 常见问题与排查技巧从编译通过到稳定运行的距离4.1 异常处理什么时候捕获什么时候抛出我见过的初学者代码里最常见的是两个极端要么把所有代码全部包在try-catch里吞掉一切异常要么干脆不处理异常让程序直接崩溃。这两种都不可取。我的原则是可预见的业务分支用条件判断处理异常只留给真正异常的情况。什么是可预见的业务分支用户没登录、商品已下架、余额不足这些都应该通过if判断去处理而不应该让它们抛异常。什么是真正的异常数据库连接断了、文件被占用、网络超时这类你无法在业务逻辑里预设条件的情况才适合用try-catch兜底。捕获异常时也是分层处理底层服务只抛出有意义的业务异常不负责消化中间层做转换和包装顶层统一处理。在C#里可以自定义异常类来携带错误码和上下文信息public class BusinessException : Exception { public string ErrorCode { get; } public BusinessException(string message, string errorCode) : base(message) { ErrorCode errorCode; } }关键提醒千万不要catch了异常然后又甩一个空return或者直接忽略。异常被吞掉之后问题往往会在更远的地方以更奇怪的形式冒出来排查成本会翻好几倍。即使吞异常至少也要记一条日志。4.2 日志和调试能定位的问题都不算问题这一轮实践中我改变最大的习惯是从“靠断点水磨工夫调试”转变为“日志先行”。断点适合开发期的小范围排查但线上环境没法停日志就是你唯一能拿到现场的线索。结构化日志是我这次想重点推荐的。别再用字符串拼接写日志了_logger.LogInformation(User {UserId} created order {OrderId} at {Time}, userId, orderId, DateTime.UtcNow);这样写的日志能保留结构化参数后续不管接什么日志系统都可以直接做字段索引按用户ID或订单ID搜索时非常方便。对这个细节我在项目里深受其益——有一次线上排查就是因为日志里带了订单号和用户号直接一条日志就锁定了问题范围而不是在几千行日志里用CtrlF碰运气。调试工具方面Visual Studio的断点条件、监视窗口和调用堆栈都是老生常谈这里提一个容易被忽略的工具Immediate Window和Watch的“即改即生效”可以在调试状态下直接修改变量值再继续运行这比改代码重新编译快很多适合验证某个分支下的处理逻辑是否正确。4.3 几个排坑实例从后台到UI再到并发这一段时间里我记录了几个印象深刻的坑写出来给大家提个醒。第一个坑是async void的滥用。C#里async void方法只能用于事件处理器如果你在一个普通方法里写成async void异常抛出时将无法被调用方捕获直接导致应用崩溃。我第一次在控制台程序里这样写时程序默默退出调试了半天才发现是async void的问题。改用async Task之后错误变得可以被await捕获问题迅速定位。第二个坑是LINQ的延迟执行和大循环的交互。我在一次批量任务里构造了一个IEnumerable查询然后多次去Count和遍历结果发现查询被重复执行接口响应时间翻了好几倍。原因是IEnumerable每次被遍历都会重新执行筛选逻辑。解决办法很简单在开头加一个.ToList()把结果缓存下来避免重复计算。第三个坑是并发环境下Dictionary的读写冲突。多线程同时写入同一个Dictionary会直接抛异常。后来改成ConcurrentDictionary并用TryAdd、AddOrUpdate这类原子操作才算彻底解决。并发集合不是随便换一个类名就行它的API使用方式也跟普通字典有差异比如索引直接赋值不如TryGetValue加TryUpdate来得安全这一点需要在实践中慢慢体会。4.4 性能优化与内存管理学会和GC做朋友C#有垃圾回收GC机制这让大部分开发者不需要手动管理内存但不代表可以对内存问题完全不上心。我在处理大量字符串拼接时用过一个典型反模式在循环里用拼接字符串。字符串是不可变的拼接每次都会产生新字符串旧字符串留待GC回收。循环几百次看不出问题几万次就明显变慢。换成StringBuilder之后性能差距是数量级的。另一个和GC做朋友的经验是避免在热路径上频繁创建大对象谨慎对待闭包捕获。lambda表达式里如果捕获了外部变量编译器会生成一个闭包类每次调用都可能产生新对象。在低频代码中无所谓在每秒执行千百次的高频方法里这就成了GC的负担。最近我写代码时也刻意注意减少不必要的装箱拆箱。比如值类型被转换成object时会发生装箱在集合操作里应当尽量使用泛型而非ArrayList这样的非泛型集合。底层的高频操作如果写成泛型性能和可读性都会更好。5. 一些让代码更稳的隐藏经验5.1 依赖注入带来的变化从手动new到容器管理早期写C#服务类都是直接在里面new依赖对象。后来维护的项目大起来发现这样写测试很难、扩展很难、替换也很难。一个对象依赖了数据库仓库你就没法在单元测试里轻易换成内存数据一个服务依赖了外部API客户端你也没法在测试环境里换成Mock。依赖注入解决的就是这个“换”的问题。把依赖的创建职责上移到容器通过构造函数或者方法的参数传入。C#里现在最常用的就是内置的依赖注入容器配合接口注册一次生命周期后面所有地方都能拿到正确的实现。我在实际使用中对生命周期的理解也是踩过坑之后才清晰的。AddSingleton适合无状态的工具类服务AddScoped适合一个请求内共享状态的服务AddTransient适合轻量且每次都要新实例的对象。如果不小心把有状态的DbContext注册成Singleton很容易出现并发冲突因为DbContext本身不是线程安全的。容器本身不会替你判断对错生命周期的选择得基于你对服务的理解。5.2 异步编程await的粒度是门技术活异步编程是C#日常开发绕不过去的主题。async/await语法本身不难难的是粒度控制。我在项目里见过一个反模式每调一个方法就await一下造成大量小粒度的异步暂停性能反而比同步还差。异步不是越多越好它的意义在于释放线程占用让线程在等待IO时能去处理别的事情。我的经验是在IO边界使用异步比如数据库访问、HTTP调用、文件读写在纯CPU计算里不必使用异步因为它不会让计算更快只会增加上下文切换的开销。还有一个新手常踩的坑是堵死异步比如在同步方法里调用异步方法然后直接.Result或.Wait()。这在低并发下看着没事高并发下很容易引发死锁或线程池饥饿。正确的做法是从头到尾贯穿着async/await让异步在调用链上自然流转。5.3 单元测试给重构装上安全网第四次总结的另一个重要收获是我开始认真写单元测试。以前总觉得测试是额外工作直到有一次重构核心模块改完之后逻辑发生了微妙变化但没有任何提示线上问题报表出来才发现。如果当时有测试覆盖这个错误早就在第一时间拦住了。C#里单元测试的框架选择很多xUnit、NUnit、MSTest都可以我习惯用xUnit加FluentAssertions来写断言。测试类命名我建议遵循“方法名_场景_预期结果”的格式比如Authenticate_WithWrongPassword_ReturnsFailure。这样的测试名本身就是文档问题定位速度极快。写测试不是为了凑覆盖率数字而是把关键业务规则固化下来。每次改动运行一遍测试就像有了安全带能够放心地对代码进行调整和优化。这其中的Mock手段依赖接口和依赖注入如果代码里充满了直接new和静态方法调用测试会非常痛苦。所以单元测试反过来也倒逼我们把代码设计得更加可测。6. 零零散散但必须知道的细节6.1 Nullable与空值处理C# 8之后的一等公民C# 8引入的可空引用类型Nullable Reference Types是一个容易掉以轻心但影响很大的特性。它让编译器能帮助你排查“可能为null”的隐患在编译期就减少空引用异常。开启这个特性后string!这样的标注不再使用而是通过上下文判断。一个string类型的变量如果不加?就表示它是非空的给它的赋值如果可能为null编译器会警告。这个能力让空值处理从运行时推到了编译期等于提前规避了一大批问题。实际使用时有个模式我很喜欢空值合并运算符 ?? 和 空值传播运算符 ?.。以前写if (obj ! null obj.Prop ! null) 这种层层判空现在可以简单写成var displayName user?.Profile?.DisplayName ?? 匿名用户;这一行代码就把级联判空和默认值都搞定了。当然过度使用?. 也可能掩盖一些本应暴露的空值问题判断尺度在于这里空值是不是合法的业务状态。6.2 记录式编程与Source Generator元编程的现代形态C#生态里越来越重视元编程能力。Source Generator允许在编译期生成源代码这一特性在减少样板代码、提升框架性能方面潜力巨大。比如某些序列化框架就在使用Source Generator来生成高效的序列化代码而不是在运行时通过反射来实现。我以前写反射代码去动态读取属性性能差且难以调试。现在许多场景其实可以用Source Generator提前生成强类型代码编译期就能发现问题。虽然不是每个项目都需要自己写生成器但了解这一技术方向能帮你在遇到“样板代码太多”“反射性能不够”这类问题时多一个解法选项。6.3 内存与性能的度量不要靠猜要用工具这一轮项目里我养成了一个习惯做性能调优的前提是先有数据不要凭直觉去优化。我常用的工具包括Visual Studio内置的性能探查器、dotnet-trace和dotnet-counters。分析内存问题时我还会抓dump文件进一步分析。有一回我发现一个后台服务内存持续增长一开始猜是缓存未清理排查很久没头绪。后面用工具抓dump分析堆对象大小发现是某个集合被静态字段引用一直只增不减。真相大白之后修改方案很简单但光靠看代码和猜我可能还要耗上更久。工具的使用让排查时间大幅压缩这是我这轮最值的收获之一。7. 如果重来一遍我最想早知道的几件事写到这一节算是给第四次总结来个我最喜欢的部分一些如果能早点知道可能少走弯路的经验。第一早点用依赖注入和接口组织代码。哪怕是小项目只要有一点扩展的可能接口风格的组织方式都会让后续的修改轻松不少。等代码膨胀到千行以上再想重构成本要高出太多。第二早点写单元测试。测试的价值不是在写的那一刻兑现的而是在未来每一次修改代码时兑现的。它能让你对重构充满信心而不是改了这里怕坏那里。第三早点养成“设计优先”的习惯。拿到需求别急着敲键盘先花点时间想想类的关系、数据的流转、异常的分支以及未来可能的变更方向。这十几分钟的思考常常可以省掉几个小时的返工。第四早点熟悉调试和分析工具。很多人看视频学了一堆语法却不知道程序出问题时怎么下手。工具链的熟练程度决定了你的排错效率这也是经验的一部分。这些说起来都是朴素的经验但每一条背后都是我实实在在踩过的坑摸出来的。让我再选一次的话我会在第一天就按这个方向去走而不是绕了大半圈才悟出来。