先讲个真实场景。上星期有个从单片机转过来做上位机的朋友找我说C#语法他一周就过完了但真开始写和PLC通信的采集程序时总觉得代码是“拼出来的”不是“长出来的”。他自己也说不清哪儿不对就是感觉每个关键字都认识组合起来就发虚。我问他你知道为什么写业务代码之前必须先聊清楚“基础构件块”吗他把教材翻出来一看发现里面全是变量、运算符、数组、方法、类这些名词的孤立解释从来没有人告诉他这些构件是怎么咬合在一起、又为什么以这种形式存在。其实学C#和搭房子是一个道理——你连砖、梁、水泥各自承担什么都不知道图纸再漂亮也盖不起来。这篇就是照着这个思路来的。我会用自己实际写上位机、写服务、调别人代码时的真实体会把C#里最核心的构件块拆开讲清楚。不是抄语法手册而是告诉你每个构件为什么存在、在什么场景下最顺手、以及我踩过的坑长什么样。适合刚入门C#的读者也适合那种“语法全认识、代码不会组织”的过渡期选手。1. 先从一张“构件清单”说起C#里到底有哪些基础构件块很多人学C#容易焦虑因为名词太多字段、属性、委托、事件、泛型、反射、LINQ、异步……每个都能单独写一本厚书。但你如果退一步看会发现这些构件其实分成五类每一类解决一类问题。数据构件变量、数据类型、字符串、数组、集合。它们负责“装东西”。你从串口读到的报文、从数据库查出来的记录、界面上输入框里的字符串最终都要落到这些容器里。逻辑构件if/else、switch、for、foreach、while以及方法。它们负责“做事情”。什么时候判断、什么时候循环、把一段逻辑封装成什么样的方法都在这一层。结构构件类、接口、继承、泛型。它们负责“组织代码”。当项目从几百行涨到几千行、几万行时没有这层构件代码就是一坨无穷无尽的面条。协作构件委托、事件、回调。它们负责“让对象之间说话”。串口收到数据怎么通知界面按钮被点击了怎么触发处理逻辑网络服务收到新连接怎么分发答案都在这一层。容错与扩展构件异常处理、日志、反射、特性。它们负责“出了问题怎么办”和“怎么不改代码的扩展功能”。这五类构件是层层递进的。你得先会装数据才能写逻辑逻辑多了就需要类来组织类与类之间要通信就轮到委托和事件最后一个真正能交付的系统还得考虑异常和扩展。C#这门语言和C、Java最大的不同也是它能在上位机、工控、桌面工具、Web服务等场景里都吃得开的原因在于它是托管的强类型语言。什么意思呢就是你不用手动管理内存垃圾回收器GC会帮你回收不再使用的对象但类型上它又极其严格你没法像写Python那样随手把一个整数塞进字符串变量里。这种“严格但省心”的特性恰恰是它适合做工业控制类软件的原因——出了Bug容易定位内存也不太容易越写越乱。提示Garbage CollectorGC是C#的一个隐形构件。它会自动回收你不再引用的对象内存但代价是运行时偶尔会“暂停”一小会儿。写高性能代码时你要理解它但入门阶段你只需要知道内存不用手动free这已经是天大的福利了。2. 数据构件变量、类型、字符串和藏在字节里的坑2.1 值类型和引用类型的分水岭比你想的重要学C#最绕不过去的一个分水岭就是值类型和引用类型。int、bool、float、double、decimal、char以及所有用struct声明的自定义类型都是值类型。它们的特点是变量直接装着数据本身。string、数组、List、Dictionary、所有用class声明的自定义类型都是引用类型。它们的特点是变量装的是“指向数据的地址”。你可以这么记忆值类型是“抄在本子上的电话号码”你把它递给别人对方拿到的是号码本身他改不改不影响你本子上的内容。引用类型是“写在共享白板上的通知”你递给别人的只是一支笔尖朝向白板的激光笔他拿着激光笔去修改白板上的字你看到的白板也变了。最典型的问题就是class Point { public int X; public int Y; } struct PointStruct { public int X; public int Y; } // 引用类型传递的是地址 var p1 new Point { X 1, Y 2 }; var p2 p1; p2.X 100; Console.WriteLine(p1.X); // 输出 100p1 和 p2 指向同一个对象 // 值类型传递的是副本 var s1 new PointStruct { X 1, Y 2 }; var s2 s1; s2.X 100; Console.WriteLine(s1.X); // 输出 1s1 完全不受影响这个特性直接决定了你会不会写出“莫名其妙的Bug”。我见过不少新手在写配置类时直接用class然后在某个方法里改了参数对象的字段结果外面所有引用这个对象的地方全跟着变了排查了半天才发现是引用类型别名问题。C#里有一个很实用的关键字叫ref它能把值类型也变成“引用式传递”。比如ref int x作为方法参数时方法内部对x的修改会直接作用到调用方的变量上。这个在解析二进制报文、交换两个大结构体的场景里很常用能帮你省掉一次拷贝。2.2 byte、char、string 根本不是一回事热搜词里高频出现c byte char的区别说明这是新人最容易混的三个类型。byte是0到255的整数。它没有“字符”的含义纯粹是八位二进制数据。你在串口通信、TCP报文、文件流里读到的都是byte。char是单个Unicode字符用一对单引号包裹比如A、中。它本质上是一个UTF-16编码单元占16位。需要注意的是char不等于byte一个中文字符在C#里是一个char但在UTF-8编码下要占三个byte。string是字符的不可变序列。你用双引号写你好时得到的是一个string对象。string在C#里是引用类型但它有值类型的“气质”——对它做任何修改都不会改变原字符串而是生成一个新字符串。这里有个极大的坑字符串拼接。string result ; for (int i 0; i 10000; i) { result a; // 每次都生成一个新字符串 }这段代码在数据量小的时候看不出问题但当你循环十万次时你会明显感觉到卡顿。因为每次都在堆上创建一个新的string对象旧对象等着GC回收分配和回收的压力都非常大。正确姿势是用StringBuildervar sb new StringBuilder(); for (int i 0; i 10000; i) { sb.Append(a); } string result sb.ToString();在实际做上位机日志模块、拼SQL语句、拼接报文时这条经验能直接让你少挨几次骂。2.3 从0x3F800000说起字节序、浮点数与报文解析热搜词里有个具体问题“0x442f0000 对应的浮点格式数据为:”。这类问题全都是在解析二进制报文时遇到的。比如你用C#和PLC通信收到一串byte数组里面有两个字节是设备状态、四个字节是温度值温度值是按IEEE 754单精度浮点数编码的。怎么解读用BitConverter。byte[] bytes { 0x00, 0x00, 0x80, 0x3F }; float temperature BitConverter.ToSingle(bytes, 0); Console.WriteLine(temperature); // 输出 1这里最关键的陷阱是字节序。0x3F800000在内存里是什么顺序取决于机器的“端序”。大多数PC是小端序所以BitConverter.GetBytes(1.0f)得到的是00 00 80 3F这个倒过来的顺序。而你从网络报文里解析到的字节往往是3F 80 00 00这样的网络序大端序。所以做报文解析时一定要先确认协议规定的字节序再决定要不要做转换byte[] networkBytes { 0x3F, 0x80, 0x00, 0x00 }; if (BitConverter.IsLittleEndian) { Array.Reverse(networkBytes); } float value BitConverter.ToSingle(networkBytes, 0);这个经验在Modbus TCP、OPC UA、自定义串口协议里统统适用。你去搜“c#连接西门子opc”“c#上位机”的时候会看到无数人在问类似的问题根源都是字节序和二进制解析。2.4 字符串截取、去空格和编码判断字符串截取是日常高频操作。Substring、IndexOf、Replace、Trim、Split、Join这六个方法几乎能覆盖你八成的需求string raw PLC_Device_01; string deviceName raw.Substring(4); // 从第4个字符开始取得到 Device_01 string code raw.Substring(0, 3); // 取前3个字符得到 PLC // 去掉字符串中间的空格 string messy 温度 25.5 ℃; string cleaned messy.Replace( , ); // 去掉所有空格 // 如果要去掉制表符、换行等所有空白字符用正则更稳 string collapased System.Text.RegularExpressions.Regex.Replace(messy, \s, );至于热搜词里另一个高频问题“怎样判断不带BOM的文本文件编码模式”这个做日志解析时会遇到。当你用File.ReadAllText读取一个文本文件时如果不指定编码.NET会先检测BOM字节顺序标记。有BOM当然好UTF-8、UTF-16都能认出来。但很多国产设备、老系统导出的文件是没有BOM的这时候StreamReader默认会按UTF-8去解码遇到不合法字节序列就会解析出乱码。我的常用策略是先按UTF-8严格模式尝试解码如果抛异常再按GB2312/GBK去解码。粗暴但有效byte[] fileBytes File.ReadAllBytes(log.txt); // 先尝试 UTF-8 严格解码 try { var utf8 new System.Text.UTF8Encoding(false, true); string text utf8.GetString(fileBytes); // 如果这里没抛异常大概率就是UTF-8 Console.WriteLine(text); } catch (System.Text.DecoderFallbackException) { // UTF-8解码失败改用 GB2312 string text System.Text.Encoding.GetEncoding(GB2312).GetString(fileBytes); Console.WriteLine(text); }3. 数组与集合面试必问的“区别”本质上是个选型问题3.1 数组和List的底层差异“C#中数组和集合分别是怎么定义的使用上有什么区别”这是面试高频也是实际开发中选型的基础。数组的定义方式很直接int[] arr new int[10]; // 固定长度10 int[] arr2 { 1, 2, 3, 4 }; // 直接初始化List的定义方式Listint list new Listint(); list.Add(1); list.Add(2);它们最核心的区别有三个长度是否可变。数组一旦定义长度就锁死了。List可以随意Add、Remove、Insert它会自动扩容。内存布局。数组是一段连续的内存访问arr[5]和arr[6]是相邻地址CPU缓存友好所以遍历性能极高。List内部其实也是数组但它会在扩容时申请更大的数组把旧元素拷贝过去这个拷贝动作是有代价的。类型灵活度。数组是强类型的List 也是。但如果你用的是老旧的ArrayList里面存的是object值类型会被装箱Boxing性能差且类型不安全。现在写代码一律用List ArrayList可以进博物馆了。3.2 什么场景必须用数组很多新人学完List之后就完全不用数组了。其实数组有它不可替代的位置。固定长度的协议帧解析。比如你的上位机要和设备通信协议规定了一帧数据刚好是32字节。那你就用byte[32]长度完全确定解析下标也不会错到哪儿去。用List反而多余。跨语言调用P/Invoke。当你用C#调用C的DLL时很多C接口要求传数组指针这时候C#里的byte[]可以直接封送List反而要额外处理。性能敏感的循环。数组遍历比List遍历少一层间接寻址在极端热路径上差距明显。但别过度优化普通业务代码用List更方便。我的习惯是默认用List只有在“长度固定不变”“要传给非托管代码”“热路径上追求极致的访问速度”这三种场景才改回数组。3.3 Queue、Dictionary、HashSet在真实项目里的位置集合家族里除了List还有几位日常出镜率非常高的成员。Queue先进先出队列。它最适合处理“数据不断进来你要按顺序慢慢处理”的场景。最典型的就是串口数据缓存——设备一直不停发数据而你的UI解析线程不可能每条都实时处理那就先Put进队列处理线程按顺序取。热搜词里有“c# queue 队列接收数据”说明这个场景非常普遍。在上位机里我经常用ConcurrentQueue来替代需要手动加锁的Queue它天生线程安全System.Collections.Concurrent.ConcurrentQueuebyte[] queue new(); // 串口数据接收线程 void OnSerialDataReceived(byte[] chunk) { queue.Enqueue(chunk); } // 处理线程 void ProcessLoop() { while (queue.TryDequeue(out byte[] data)) { // 解析一帧数据更新波形写日志 } }DictionaryTKey, TValue哈希表按键查值的速度是O(1)。最适合做配置映射比如把设备ID映射到设备对象把变量名映射到当前值。Dictionarystring, double tagValues new(); tagValues[锅炉温度] 98.5; tagValues[压力] 1.2; if (tagValues.TryGetValue(锅炉温度, out double temp)) { Console.WriteLine($当前温度: {temp}); }HashSet去重集合它只关心“某个元素在不在里面”不关心顺序也不允许重复。比如你要过滤一批已经处理过的设备ID用HashSet比List的Contains快得多数据量越大越明显。我可以用一张表把这几个集合的选型思路总结出来集合类型底层结构擅长场景不擅长场景数组连续内存固定长度、高性能遍历、互操作频繁增删List动态数组大多数顺序集合操作频繁在头部插入要整体移动Queue队列先进先出的消费缓冲随机访问中间元素DictionaryTKey,TValue哈希表按键快速查找、映射关系需要保持插入顺序HashSet哈希集合去重、快速判断是否存在需要排序、按下标访问很多面试官爱问“数组和集合的区别”本质上就是在考你会不会根据场景选型。你要是能讲出底层结构和各自适合的战场这道题基本就稳了。4. 流程与控制方法设计是最容易被忽视的基础构件4.1 流程控制代码的可读性直接决定项目的存活率C#的流程控制构件和大多数语言类似if/else、switch、for、foreach、while、do-while。但是“会用”和“用得好”之间的差距往往比入门者和资深者的差距还大。举几个我平时review代码时最常开喷的点不要写超过三层的if嵌套。三层嵌套你还能人肉跑通五层以上就是灾难。太深的条件逻辑拆成小方法每个方法只处理一种情况加上return提前退出可读性立刻上一个台阶。foreach里不要修改集合。这是新手必踩的坑在foreach循环里对List调用Add或Remove运行时直接抛出InvalidOperationException提示“Collection was modified”。如果你确实要在遍历过程中删元素用for倒序删除或者先收集要删除的元素循环结束后统一删除。switch表达式是新宠。从C# 8.0开始switch可以写成表达式配合模式匹配非常简洁string GetMessage(int code) code switch { 200 OK, 404 Not Found, 500 Server Error, _ Unknown };这种写法比传统switch-case省掉一堆break而且编译器能帮你检查分支覆盖是否完整。现在的C#是12/13时代了老式的switch-case除了个别场景比如要fall through基本都可以用switch表达式替代。4.2 方法远不止“一段代码”那么简单方法是逻辑构件里最重要的一个但它往往被初学者当成“把代码包一包”的工具。实际上方法设计的质量决定了你代码的复用程度和可测性。几个核心点方法应该只做一件事。这是“单一职责原则”在方法级的表现。如果一个方法既解析报文、又更新数据库、还刷新界面那你就没法单独测它也没法复用其中任何一部分。我的习惯是方法名应该能概括它做的事情如果你的方法名需要用“And”来连接两件事就拆。参数的传递方式要刻意设计。C#有ref、out、in三个修饰符。out常用于“方法内部必须赋值”的场景比如int.TryParseif (int.TryParse(input, out int number)) { Console.WriteLine(number); }ref用于“调用方已有值方法要修改它”。in用于只读传递避免拷贝。能用out表达“这个方法可能失败”的场景就不要返回null或者用魔法数。避免返回null。新手写代码时特别喜欢返回null作为“没有找到”的标记但调用方只要忘记判空就会吃NullReferenceException。更稳妥的做法是返回可空类型或者用Try模式// 不推荐 string FindName(int id) { return _names.ContainsKey(id) ? _names[id] : null; } // 推荐 bool TryFindName(int id, out string name) { if (_names.TryGetValue(id, out name)) { return true; } name string.Empty; return false; }4.3 递归要克制循环不够就再想想递归看起来很精巧但C#里递归用得不好容易爆栈。StackOverflowException在C#里是无法被catch捕获的进程直接崩掉没有任何挽回余地。我见过最典型的问题是计算斐波那契数列时用递归n稍微大一点就指数级膨胀。// 千万别这么写 long Fib(int n) { return n 2 ? 1 : Fib(n - 1) Fib(n - 2); }改成循环之后复杂度直接从指数级降到O(n)long Fib(int n) { if (n 2) return 1; long prev 1, current 1; for (int i 3; i n; i) { (prev, current) (current, prev current); } return current; }换句话说凡是能用循环解决的问题优先用循环。递归只在树形结构遍历、目录遍历这类天生递归的场景里保留。真要用递归记得控制深度并且想清楚终止条件。5. 委托、事件与回调让C#代码“活”起来的核心构件5.1 把委托理解成“方法的类型”委托是C#面试里出现频率最高的关键词也是新人和老手之间分水岭最明显的一个知识点。很多教材把委托讲得玄而又玄我的理解就一句话委托就是方法的类型。int类型可以装整数bool类型可以装真假而委托类型可以装一个方法。比如我定义一个委托delegate void NotifyHandler(string message);这个委托类型能装“一个接收string参数、返回void的方法”。我可以把一个普通方法装进去也可以把一个lambda表达式装进去// 普通方法 void ShowInConsole(string msg) { Console.WriteLine($[控制台] {msg}); } NotifyHandler handler ShowInConsole; handler(设备已连接); // 或者直接用lambda NotifyHandler handler2 msg Console.WriteLine($[控制台] {msg});为什么需要这种“方法的类型”因为有了它你就可以把方法作为参数传来传去实现一种“动作注入”的效果。比如你要写一个通用的数据处理函数处理流程是固定的但“处理完之后怎么通知别人”这个动作是可变的那你把这个动作做成一个委托参数传入就完事了。在现代C#里你几乎不需要自己去声明个性化委托直接用框架自带的Func和Action就够了Actionstring notify msg Console.WriteLine(msg); // 无返回值 Funcint, int, int add (x, y) x y; // 有返回值5.2 多播委托和闭包陷阱委托还有一个特性它是多播的。你可以在一个委托实例上挂多个方法Actionstring notify msg Console.WriteLine($写入日志: {msg}); notify msg Console.WriteLine($刷新界面: {msg}); notify(温度报警);执行一次notify两个方法会顺序执行。这在“一个事件引发多个动作”的场景里非常有用。但多播委托有两个坑你要记住异常会中断后续方法。如果第一个方法抛异常后面的方法就不会执行了。所以挂在委托链上的方法自己要处理好异常。闭包捕获循环变量的坑。这个非常经典上面说过一次这里用代码再演示一遍var actions new ListAction(); for (int i 0; i 3; i) { actions.Add(() Console.WriteLine(i)); } foreach (var action in actions) { action(); } // 你以为是 0,1,2实际上可能是 3,3,3原因是lambda表达式捕获的是变量i本身而不是它当时的值。循环结束后i变成3所有lambda看到的都是3。C# 5.0之后foreach的迭代变量被改成每次循环一个副本所以foreach没这个坑但for循环依然有。要修复就再复制一份局部变量for (int i 0; i 3; i) { int copy i; // 关键每次循环都复制一个 actions.Add(() Console.WriteLine(copy)); }5.3 事件是“受保护的委托”热搜词里同时出现了“c#委托”“c#委托和事件”“c#回调委托”所以事件和委托的关系必须说透。事件本质上是一个被C#语法特别封装的委托字段。它和裸委托的区别在于从类的内部看你可以随意触发Invoke但从类的外部看别人只能通过和-订阅或退订不能直接调用也不能随意重置为null。这个限制很重要。它保证了事件的“发布者”能控制触发时机而“订阅者”只负责挂方法进去无法越权触发事件。定义一个事件的典型写法public class SerialPortManager { // 事件声明 public event Actionstring DataReceived; private void OnDataReceived(string data) { // 触发事件。?.表示如果没人订阅就不执行 DataReceived?.Invoke(data); } public void SimulateReceive() { OnDataReceived(模拟串口数据); } }使用方var manager new SerialPortManager(); manager.DataReceived msg Console.WriteLine($收到数据: {msg}); manager.SimulateReceive();这里有个工作上的血泪教训事件订阅了就要退订。如果你的管理器是短生命周期对象而它订阅了一个长生命周期对象的事件短对象会一直被长对象引用着GC永远回收不了它这就是内存泄漏。老手一提到事件就强调-不是没有道理的。比如在窗口关闭时manager.DataReceived - OnDataReceived;5.4 回调到底是怎么回事“回调”这个词在C#里其实没有新概念它就是把一个委托实例传给某个方法让对方在合适的时机调用它。最常见的一个场景是异步通知void ReadDataFromDeviceAsync(Actionstring callback) { // 模拟耗时操作 Task.Run(() { Thread.Sleep(1000); callback(读取完成); }); } ReadDataFromDeviceAsync(msg Console.WriteLine(msg));当你搜“c#回调委托”的时候你可能会看到各种复杂解释其实本质就是这么点事。委托是回调的载体回调是委托的用途两者不分家。6. 类、接口与泛型把构件组织成能维护的骨架6.1 封装和属性其实是“方法”的糖衣类class是C#里组织代码的核心单位。字段存数据方法做操作而属性Property是二者之间的桥。很多人不理解属性存在的意义觉得直接用公共字段多简单。但从设计角度看字段是赤裸的属性是有门的。public class Device { // 自动属性编译器帮你生成一个私有字段 public string Name { get; set; } // 只读属性外部只能读只有类内部能改 public int Status { get; private set; } // 计算属性不是存数据而是算出来的 public string DisplayStatus Status 1 ? 在线 : 离线; }属性的本质是方法。每个带get的属性编译后都是一个get_Name方法带set的是set_Name方法。所以属性可以在getter和setter里加校验、加通知、加延迟加载逻辑。这就是“封装”的威力。6.2 接口和抽象类怎么选才不纠结类与类之间需要协作继承给了你“复用代码”的能力接口给了你“定义契约”的能力。抽象类 有状态的、能共享实现的基类。子类往往是一种特殊化的关系is-a。比如“温度设备”和“压力设备”都是“设备”可以把公共字段、公共方法放进抽象基类Device。接口 纯契约不带状态严格说C# 8之后接口可以有默认实现但总体上它描述的是“能做什么”而不是“是什么”。比如IDisposable表示“这个对象可以释放资源”IComparable表示“这个对象可以比较大小”。这更像是能力声明can-do。我给你一个很朴素的经验如果你想表达“子类必须复用我的代码并且顶替我的位置”用抽象类。如果你想表达“只要你能干这件事我就接受你”用接口。优先选接口。因为它让系统更松耦合测试时也容易用Mock替换。比如我要实现一个数据采集器它可以从串口、网口、USB三个渠道采集数据。这时我会定义一个接口IDataSource三个实现类各自实现Open、Read、Close。上层逻辑只依赖接口完全不关心数据是从哪来的public interface IDataSource { void Open(); byte[] Read(); void Close(); } public class SerialDataSource : IDataSource { /* 实现串口逻辑 */ } public class TcpDataSource : IDataSource { /* 实现TCP逻辑 */ } public class UsbDataSource : IDataSource { /* 实现USB逻辑 */ }6.3 泛型和反射基础构件里的“动静”组合泛型让你的代码能编译时确定类型避免装箱拆箱也避免运行时的类型转换错误。List 、DictionaryTKey, TValue就是典型的泛型构件。反射走的是另一条路运行时检查类型信息。比如你有一个对象想看看它有哪些属性或者动态创建它用反射Type type typeof(Device); foreach (var prop in type.GetProperties()) { Console.WriteLine(prop.Name); } // 动态创建实例 object device Activator.CreateInstance(type);反射的经典应用场景是插件系统程序启动时扫描某个目录下的DLL通过反射找到实现了某个接口的类再加载它。但反射性能较差每次调用都有不小的开销。现在C#有了源生成器Source Generator很多以前必须用反射做的“找类型、生成代码”的工作可以在编译时就完成性能大幅提升。入门阶段你不需要写源生成器但要知道反射不是万能的能编译时解决的就别拖到运行时。7. 异常处理与跨语言调用排查错误也是构件系统的一部分7.1 try/catch/finally和using到底在兜什么底代码终究会出错而C#处理错误的主要机制就是异常。try/catch/finally的典型场景是解析用户输入、读写文件、调用网络服务、操作数据库。这些都可能抛异常而异常不是“Bug”本身它是程序在运行中遇到意外情况时的报警机制。写异常处理最容易犯的三个错误我挨个说第一个错误catch超大类异常后吞掉它。try { int.Parse(input); } catch (Exception ex) { // 什么都不做 }这是最恶劣的写法。你不仅把错误信息扔了还把程序可能处于的“中间状态”掩盖了后面想排查根本无从下手。至少要Console.WriteLine(ex)或者写进日志。第二个错误用异常控制正常流程。int result; try { result int.Parse(input); } catch { result 0; }这种情况明明用int.TryParse更合适异常处理本身有开销拿它来做业务判断既慢又丑。第三个错误不知道using是try/finally的语法糖。当你操作文件、串口、数据库连接这类需要释放资源的对象时using是姿势最优雅的写法using (var reader new StreamReader(data.txt)) { string content reader.ReadToEnd(); } // 无论是否抛异常reader都会在离开using块时调用DisposeC# 8之后还有using声明语法可以少写一层花括号using var reader new StreamReader(data.txt); string content reader.ReadToEnd();这两种写法等价选哪个纯粹看个人喜好但效果都是资源一定被释放。7.2 AccessViolationC0000005级别的错误不是try/catch能兜住的热搜词里有条非常实在的问题“c#调用c出现access violation c0000005”。这个问题我年轻时也撞过好几次。C0000005是Windows的访问违规错误码意思是程序试图访问一个没有权限或根本不存在的内存地址。当你从C#通过P/Invoke调用C的DLL时C那侧如果写了越界内存、释放了野指针、或者字符串缓冲区长度不够进程往往会直接崩溃而且大概率抛不出能被C#捕获的AccessViolationException。为什么会这样因为非托管代码崩溃时进程状态可能已经损坏CLR无法保证托管运行时还能安全运行。所以很多情况下你看到的不是异常而是进程“噗”地一下没了。碰到这个错误我的排查思路是这样先排除调用约定不匹配。C#默认的CallingConvention是Winapi如果你的C接口是cdecl需要在DllImport里显式声明CallingConvention CallingConvention.Cdecl。这个错了参数栈都对齐不了。再检查封送Marshal策略。char或wchar_t在C#里对应string时要指定CharSet。Ansi对应单字节Unicode对应UTF-16。搞错了指针长度就不对。重点检查缓冲区大小。C函数如果往一个char buffer里写内容而这个buffer在C#侧只分配了几个字节C一写就越界。这个问题用眼睛看代码很难发现最好配合WinDbg抓一下崩溃时的dump看崩溃地址附近的访问模式。最后考虑对象生命周期。如果你把C#对象的指针传给了CC那边在异步操作里还留着这个指针而C#侧的GC已经把对象回收了后面C再用这个指针就会崩。这个问题尤其隐蔽。一句话总结出现C0000005时先默认非托管侧内存有问题不要指望C#的try/catch能救你。7.3 日志是整个错误处理体系里不可或缺的构件热搜词里出现了“c#如何用nlog”可见日志在真实项目里有多重要。没有日志你排查问题就只能靠猜猜是最费时间的。NLog的用法非常简单。先在项目里安装NLog包再写一个NLog.config配置文件?xml version1.0 encodingutf-8 ? nlog xmlnshttp://www.nlog-project.org/schemas/NLog.xsd xmlns:xsihttp://www.w3.org/2001/XMLSchema-instance targets target namefile xsi:typeFile fileName${basedir}/logs/${shortdate}.log layout${longdate}|${level:uppercasetrue}|${logger}|${message}${exception:formattostring} / /targets rules logger name* minlevelInfo writeTofile / /rules /nlog然后直接在代码里用using NLog; private static readonly Logger logger LogManager.GetCurrentClassLogger(); logger.Info(设备已连接: {DeviceId}, deviceId); logger.Error(ex, 解析报文失败);用日志的几个小建议日志分级要合理。Info记录常规流程Debug记录详细报文Error记录异常。别把没用的Debug信息刷成Info日志文件会爆炸。日志要带上下文。光写一句话“读取失败”没用要有设备ID、报文内容、异常堆栈。上线后把日志级别调到Info或Warn调试时再开Debug。NLog的动态日志级别可以在运行时改不用重启进程遇到难缠问题非常有用。8. 新一代构件LINQ、Task与async/await怎么和基础构件咬合8.1 LINQ不是魔法它是委托和泛型的组合LINQ语言集成查询在C#里地位非常特殊。它让集合处理变成了一种“查询语言”而它的底层构件恰恰是你前面学的委托和泛型。比如你要从一个设备列表中选出所有在线设备并按名称排序var onlineDevices devices .Where(d d.Status 1) .OrderBy(d d.Name) .Select(d d.Name) .ToList();Where、OrderBy、Select这些方法接收的参数本质上都是委托。lambda表达式d d.Status 1其实就是一个匿名方法对应一个Func委托。LINQ的两个使用要点内存数据用LINQ没问题。集合不大时怎么查都是毫秒级的事代码还极其好读。注意查询只执行一次还是多次。这是LINQ新手最容易踩的坑。Where返回的是一个延迟执行的查询对象如果你把它遍历两次查询会执行两次。如果查询里有耗性能的操作比如IO你无意中执行了多遍都不知道。解决办法是加一个.ToList()立刻物化结果。8.2 async/await的本质是状态机不是多线程热搜词里有“c#task的用法”和“c#多线程”这俩经常被混为一谈但必须分开。Task是一个“异步操作”的句柄。await不是“等待这个Task在另一个线程跑完”而是“当前方法先挂起线程可以去做别的事等Task完成后再回来继续执行”。打个比方你请人修水管你不需要一直盯着他干活。你递给他一把钥匙他可以自己进门等他修好了给你打电话你再回去验收。这期间你可以干自己的事。async/await就是这个“递钥匙等电话”的模型挂起的当前线程不会被阻塞。一个典型的异步文件读取public async Taskstring ReadLogAsync(string path) { using var reader new StreamReader(path); return await reader.ReadToEndAsync(); }注意几个实践要点async方法最好是IO密集型场景。读写文件、请求网络、访问数据库这些天生异步。如果是密集计算用async并不能提速反而白白引入状态机开销。密集计算要加速考虑的是Task.Run配合真正的并行而不是await。async void是禁区但事件处理器除外。async void方法抛出的异常无法被调用方catch程序可能直接崩。普通业务方法一律返回Task。只有事件处理器因为签名限制才不得不写成async void而且里面的异常一定要自己兜住。注意CancellationToken。网络请求、长时间任务都可能因为用户取消操作而需要中断。用CancellationTokenSource可以优雅地取消Taskvar cts new CancellationTokenSource(); Task.Run(() { while (!cts.IsCancellationRequested) { // 处理数据 } }, cts.Token); // 在需要结束时调用 cts.Cancel();8.3 用Task组织TCP服务端的多客户端连接热搜词里有一条“c# tcplistener 多客户端”这是个非常典型的上位机场景也是个很好的“新构件组合起来”的示例。一个基础的TCP服务端模型是一个监听线程不断Accept新连接每个连接分配一个Task去处理用ConcurrentDictionary管理在线客户端。var clients new System.Collections.Concurrent.ConcurrentDictionarystring, TcpClient(); var listener new TcpListener(IPAddress.Any, 9000); listener.Start(); while (true) { TcpClient client await listener.AcceptTcpClientAsync(); string clientId Guid.NewGuid().ToString(); clients.TryAdd(clientId, client); Console.WriteLine($客户端上线: {clientId}); // 每个客户端一个Task互不阻塞 _ Task.Run(() HandleClientAsync(clientId, client)); } async Task HandleClientAsync(string clientId, TcpClient client) { try { using var stream client.GetStream(); var buffer new byte[1024]; while (client.Connected) { int read await stream.ReadAsync(buffer, 0, buffer.Length); if (read 0) break; // 连接关闭 string message System.Text.Encoding.UTF8.GetString(buffer, 0, read); Console.WriteLine($[{clientId}] {message}); // 你可以把数据放进队列交给解析线程统一处理 // _queue.Enqueue(message); } } catch (Exception ex) { // 记录异常 } finally { clients.TryRemove(clientId, out _); client.Dispose(); } }这段代码基本上能把几个核心构件串起来异步读写、Task、ConcurrentDictionary、try/finally。基础构件块不是孤立的最终都是像这样组合在一起服役。写到这里C#语言的基础构件块已经聊得差不多了。我个人带新人的习惯是先让他们把数据类型、数组和集合这些数据构件练到闭着眼都能选对再重点打磨委托和事件因为理解了“方法作为参数传递”之后读别人的代码会通透很多。然后才轮到类、接口、泛型这些组织级构件最后才是异步和新语法。基础构件块本身不难难的是意识到它们不是一间间独立的储藏室而是一个咬合严密的整体。你手里握着的那把钥匙就是对每个构件背后“为什么存在”的理解。等这把钥匙能转动锁芯你会发现后面学LINQ、学异步、学框架都会快得超出预期。这个系列既然起了个【1】的编号后续我大概率会接着写“怎么用这些构件块搭一个能直接上生产的通用上位机框架”“委托事件在串口通信框架里的完整实践”之类的话题。如果看到这里觉得有帮助也可以自己先试着做一个小工具读一个文本文件把里面所有数字提取出来求和再写进另一份文件。这个小练习能把字符串处理、集合、异常日志这些构件全部过一遍比看十篇教程都管用。
