C#反射机制实战：从插件化驱动到上位机性能优化

这几年做上位机和自动化项目，我越来越觉得C#反射机制是个绕不过去的东西。很多人一开始听到“反射”两个字就发怵，觉得它是高级编程里才用得上、平时根本碰不到的概念。但真当你接到一个需求——“程序运行的时候，要根据配置文件加载不同品牌的相机SDK，还不能改主程序重新编译”——你会发现自己堵在一堵墙上，而反射就是那扇门。

这篇文章我会用自己在工控上位机、机器视觉项目里的实际经验，把C#反射机制拆开讲清楚。包括它到底解决了什么问题、核心API怎么用、在设备驱动加载和协议解析里怎么落地，以及性能上怎么优化、有哪些坑一定要避开。参考人群就是做上位机开发、visionpro/halcon联合编程、PLC通讯、扫码枪对接这类项目的朋友，当然如果你只是学C#基础，这篇文章也能帮你把“反射”这个面试常客彻底搞明白。

1. 反射机制到底是什么：编译期与运行期之间的一堵墙

1.1 从一次“换相机驱动”的真实需求讲起

先说我遇到过的场景。有一台视觉检测设备，现场用的是A品牌相机，第二天客户说想试试B品牌的，但主程序是已经编译好、部署到工控机上的。如果代码里直接new了一个A相机的对象，那换B相机就得改源码、重新编译、重新发布，一来一回大半天就没了。

但如果用反射，情况就完全不同。我可以约定一套统一的相机接口，把A相机、B相机的类分别写进各自的DLL里，主程序运行时通过配置文件名去加载对应DLL，再创建出实现该接口的对象。整个过程主程序代码不需要改动，换驱动就是换配置文件的事。

这就是反射机制的核心价值：它让程序在运行期可以检查自身或外部程序集的元数据，并能动态创建对象、调用方法和读写属性。换句话说，编译期你不知道的类，运行期可以知道；编译期写不了的新对象，运行期可以创建。

很多做C#入门的朋友会把反射想得很玄，其实它背后依赖的就是CLR得以运行的根基——元数据。托管程序编译出来后，会生成IL代码，同时还会保留一份完整的“类型清单”，类名、方法签名、属性类型、特性标注全都在里面。反射就是程序运行的时候自己去查这份清单，然后按清单去操作类型。

1.2 反射的能力边界：能做什么，不能做什么

反射能做的事情很多，但也不是万能的，我给自己总结了一张“能力表”。

能做的：

• 程序运行时获取程序集、模块、类型列表
• 获取类型的方法、属性、字段、事件、构造函数
• 动态创建实例，调用方法和属性
• 读取类、方法、属性上标注的特性（Attribute）
• 动态加载外部DLL，实现插件化架构

不能做的（或者说代价很大的）：

• 绕过硬编码的性能优势，直接暴力反射调用比普通方法调用慢一个数量级，但可以通过缓存和委托优化到接近原生性能
• 对非公开成员的访问，受运行环境和权限限制，而且会让代码变得非常脆弱
• 反射不能“凭空”改变已经编译好的IL逻辑，它只是按元数据操作类型，不是修改类型本身

还有一点要说清楚，反射不算是什么“特殊黑魔法”，它本质上就是一套.NET提供的对象模型。你new的一个普通对象，底层也是通过类型信息构建出来的，只不过编译器帮你写好了那段“找类型、创建实例”的代码，反射则是把这段过程留到运行期而已。

1.3 用一张“点名册”来理解反射

我上课给新人讲反射时，喜欢用点名册做类比。

程序里有一个类，就像一个真实的学生。编译期你在代码里直接new，相当于你认识这个学生，直接叫他的名字：“张三，过来一下。”这是普通调用。但反射是什么呢？是你手上只有一本全校学生名单（程序集的元数据），你不用提前认识谁，运行的时候翻开册子，按条件筛选：“找出所有身高超过170厘米的男生”，找到之后再点名，把人叫到跟前，再给他安排任务。

这本点名册就是元数据，翻册子的动作就是反射。你不需要在写代码的时候就认识那个类，你只需要知道册子存在、册子能查、查到之后可以通过统一的方式“叫名字”就行。这就是反射能够支撑插件化架构的根本逻辑。

2. 反射核心API的实操地图：拿到类型，就能拿到整个世界

2.1 四个核心对象：Assembly、Type、MemberInfo、Attribute

反射的日常操作基本围绕四个对象打转。

• Assembly：程序集，相当于一个DLL或EXE的集合容器，负责加载和枚举内部类型
• Type：类型，反射的核心入口，用来获取成员信息、创建实例、判断继承关系等
• MemberInfo（以及MethodInfo、PropertyInfo、FieldInfo等派生类）：描述类型里的具体成员
• Attribute：特性，严格来说它也是元数据的一部分，反射可以读取类或成员上标注的特性

这四个对象的关系可以这样理解：程序集是一个公司，Type是公司里的员工花名册上的一位员工，MemberInfo是这位员工的能力项，Attribute则是贴在员工工牌上的标签——停留在描述层。反射就是拿着花名册，找到员工，看他的能力项和标签，然后安排干活。

2.2 加载外部DLL并筛选类型，然后创建实例

我在项目里用得最多的就是Assembly.LoadFrom，把外部驱动DLL加载进来，再用GetTypes遍历里面的类型，通过接口判断或者特性过滤，筛选出目标类。

// 从外部DLL加载程序集 Assembly asm = Assembly.LoadFrom(@"D:\Drivers\HikCameraDriver.dll"); // 遍历该程序集中所有类型 foreach (Type t in asm.GetTypes()) { // 过滤：必须是ICamera的实现类，且是普通类（不是接口/抽象类） if (typeof(ICamera).IsAssignableFrom(t) && !t.IsInterface && !t.IsAbstract) { // 动态创建实例 ICamera camera = (ICamera)Activator.CreateInstance(t); camera.Open(); } }

这段代码是很典型的“插件加载”逻辑。因为所有相机驱动类都实现了统一的ICamera接口，主程序根本不需要引用某个具体相机的类型，拿到实例后直接按接口方法调用就行。

这里我要提醒一句：Activator.CreateInstance创建实例的默认构造器，如果类没有公共无参构造器，这一步会抛MissingMethodException。所以插件类一定要保留一个公共无参构造器，或者用Activator.CreateInstance(Type, object[])传参的方式处理。

2.3 动态调用方法：Invoke的完整姿势

创建实例之后，很多时候我们并不知道实例的具体类型，需要用Type对象去定位方法再调用。这时MethodInfo就派上用场了。

Type type = camera.GetType(); MethodInfo method = type.GetMethod("Trigger", new Type[] { typeof(int) }); if (method != null) { object result = method.Invoke(camera, new object[] { 1 }); }

注意GetMethod的第二个参数，传的是参数类型数组。这个细节特别容易踩坑：如果类里有多个同名重载方法，不传参数类型的话可能抛AmbiguousMatchException，或者拿到的不是你想要的那个重载。所以只要方法有参数，尽量把参数类型数组带上。

如果需要调用泛型方法，还要多一步MakeGenericMethod：

MethodInfo genericMethod = type.GetMethod("MapValue"); MethodInfo closedMethod = genericMethod.MakeGenericMethod(typeof(double)); double value = (double)closedMethod.Invoke(camera, new object[] { 128.0 });

Invoke的执行流程是把所有参数打包成object数组传进去，拿到结果再强转回目标类型。这里有个性能上的代价，后面专门讲优化方案。

2.4 特性本质是元数据：让代码“被标记后自动生效”

反射的另一个典型用法是读取特性，也就是Attribute。很多新手不理解特性到底有什么用，总觉得它就是加个标记，程序又不会自动执行什么。

实际项目中，特性是和反射配合起来用的。比如我做一个协议分发器时，会给每个消息处理函数打上特性标记：

public class ProtocolHandlerAttribute : Attribute { public int MessageId { get; } public ProtocolHandlerAttribute(int messageId) { MessageId = messageId; } } public class MessageHandlers { [ProtocolHandler(0x01)] public void HandleHeartBeat(byte[] data) { } [ProtocolHandler(0x02)] public void HandleStatus(byte[] data) { } }

然后在程序初始化时，用反射扫描所有方法，把MessageId和方法建立映射关系：

var handlers = new Dictionary<int, MethodInfo>(); foreach (var method in typeof(MessageHandlers).GetMethods()) { var attr = method.GetCustomAttribute<ProtocolHandlerAttribute>(); if (attr != null) { handlers[attr.MessageId] = method; } }

这样，收到0x01报文时，查表就能找到HandleHeartBeat并反射调用。后续新增指令，只需在类里加一个新方法并打上特性，分发器完全不用改。这种“打标签 + 反射扫描”的组合，在很多框架里都能看到，比如ASP.NET Core的路由、ABP框架的模块加载，底层思路都是一样的。

3. 上位机与自动化项目里的反射实战场景

3.1 插件化设备驱动：换相机不用重新编译主程序

回到开头那个案例。一个视觉检测工站可能面临多种相机：海康、大华、Basler，甚至有客户用VisionPro的采集卡。如果主程序和每个厂商的SDK都耦合在一起，那维护成本会高到让人崩溃。

我的做法是定义一套面向业务的驱动接口，比如ICamera，包含Open、Close、Trigger、GetImage等方法。不同品牌的相机SDK各自封装成一个DLL，实现这个接口。主程序只认识ICamera，具体创建哪个实现类，由配置文件决定：

{ "CameraDriver": "HikCameraDriver", "Cameras": [ { "Id": 1, "Ip": "192.168.1.10", "Model": "MV-CE060" }, { "Id": 2, "Ip": "192.168.1.11", "Model": "MV-CE120" } ] }

启动时读取配置，再通过反射去DLL目录下扫描所有实现了ICamera的类型，用配置里的驱动名进行匹配。这样新增一个品牌相机，只需要把人家的SDK封装好、放进驱动目录，主程序连代码都不用动。

3.2 设备驱动动态加载的通用套路

我把这套做法抽成了一个通用的驱动加载器，核心思想可以复用到PLC、扫码枪、板卡等多种设备上。

第一步，定义驱动接口，这是整个插件系统的契约。第二步，按约定向驱动DLL里放入实现类。第三步，主程序用反射扫描并缓存可用的驱动类型。第四步，根据配置创建实例并初始化。

public static class DriverLoader { private static readonly ConcurrentDictionary<string, Type> _typeCache = new(); public static List<T> LoadDrivers<T>(string directory) { var result = new List<T>(); var files = Directory.GetFiles(directory, "*.dll"); foreach (var file in files) { var asm = Assembly.LoadFrom(file); foreach (var type in asm.GetTypes()) { if (typeof(T).IsAssignableFrom(type) && !type.IsInterface && !type.IsAbstract) { var instance = (T)Activator.CreateInstance(type); result.Add(instance); } } } return result; } }

这个方案在客户现场帮了大忙。有一次现场临时换了一个型号的扫码枪，我做的也就是把新驱动DLL拷贝过去、改一下配置文件，十几分钟就搞定了。要是以前，从改代码到发布，至少半天起步。

这个套路还有一个衍生价值：团队分工可以更清晰。驱动开发的人只面对SDK和接口文档，主程序的人只依赖抽象接口，不关心具体实现。两个模块甚至可以并行开发，最后通过接口联调。

3.3 用特性做协议指令分发

上位机项目免不了和各种控制器通讯。通讯协议里最常见的格式是“帧头 + 命令字 + 数据体 + 校验”，主程序根据命令字决定执行什么逻辑。传统写法是写一长串switch-case，协议指令一多，这个函数会膨胀成一个几千行的巨无霸，看着就头大。

用反射加特性可以把这段逻辑完全拆开。每个命令字对应一个方法，方法上标注命令字编号，初始化时扫描建立映射关系，收到报文时反射调用即可。

public class FrameDispatcher { private readonly Dictionary<byte, Action<byte[]>> _handlers = new(); public void RegisterHandlers(object handlerObj) { var methods = handlerObj.GetType().GetMethods(); foreach (var method in methods) { var attr = method.GetCustomAttribute<CommandHandlerAttribute>(); if (attr != null) { var handler = (Action<byte[]>)method.CreateDelegate(typeof(Action<byte[]>), handlerObj); _handlers[attr.Command] = handler; } } } public void Dispatch(byte command, byte[] payload) { if (_handlers.TryGetValue(command, out var handler)) { handler(payload); } } }

注意上面我用的是CreateDelegate而不是Invoke。RegisterHandlers只在程序启动时执行一次，但Dispatch是每条报文都会执行的高频路径，用委托可以避免每次的反射调用开销。这个细节很重要，后面讲性能时再展开。

Modbus、FINS UDP、TCP自定义协议都可以套用这套结构。指令处理器按业务模块拆成多个类，每个类负责一组相关指令，代码可读性和可维护性会好很多。

3.4 扫码枪触发、数值变化检测与反射

热词里有“扫码枪触发事件”和“检测变量数值变化”，这两个实际场景也可以用反射来优雅地处理，但思路略有不同。

扫码枪触发事件，典型做法是订阅扫码器的数据到达事件。当你用反射加载了一个动态驱动的扫码枪对象时，你没法在编译期写好事件订阅代码，因为编译期你甚至不知道它的类型。这时候可以用EventInfo来动态挂接事件：

EventInfo scanEvent = type.GetEvent("OnScanned"); if (scanEvent != null) { var handler = new Action<string>(data => { MessageBox.Show($"扫描到条码：{data}"); }); var delegateInstance = Delegate.CreateDelegate(scanEvent.EventHandlerType, handler.Target, handler.Method); scanEvent.AddEventHandler(scannerInstance, delegateInstance); }

不过这里我要建议一句，和第三方设备通讯的层面，与其用EventInfo到处反射，不如在驱动封装的时候就把底层事件统一收敛成你自己的标准事件，比如IScanner接口里定义更简单的DataReceived事件。这样主程序就能用普通的事件订阅方式处理，不需要到处反射。

反射更适合做框架层的事，不适合散落在业务代码里。驱动层把差异消化掉，业务层用强类型调用，这才是最舒服的形态。

至于检测变量数值变化，我见过很多用反射实现的通用属性变更通知方案。比如一个配置类，用特性标注需要监控的属性，然后用反射给这些属性加上变更检测逻辑。但说实话，这种需求我用得更多的还是INotifyPropertyChanged或者数据绑定框架，反射只用来做一个通用的包装层。比如动态读取某个PLC寄存器地址的值，映射到对象的属性上，再通过反射在值变化时触发自定义回调。这种场景下反射解决的问题不是“怎么监听值变化”，而是“程序编译期根本不知道你要监听哪些属性”。

所以反射在这里扮演的是“桥接器”的角色，把字符串配置、外部数据和代码里的对象动态绑到一起。这种模式在配置驱动的UI、报表系统、设备参数管理里非常实用。

3.5 配置驱动的属性映射与自动赋值

做上位机的人应该都有这种经历：设备参数一大堆，从配置文件或数据库读进来之后要填到几十个文本框里。手写赋值代码既枯燥又容易漏。

我用反射做了一个简单的自动映射工具：读取配置项名称，按照约定在对象上查找同名属性，然后赋值。前提是对象属性和配置项名称能对得上。

public static T MapConfigToObject<T>(Dictionary<string, object> config) where T : new() { var instance = new T(); var properties = typeof(T).GetProperties(); foreach (var prop in properties) { if (config.TryGetValue(prop.Name, out var value)) { var targetValue = Convert.ChangeType(value, prop.PropertyType); prop.SetValue(instance, targetValue); } } return instance; }

类似地，还能写一个反向的：把对象的所有属性读出到字典，用于生成日志或保存配置。这样一来，新增一个参数，只需要在对象模型里加一个属性，配置文件和数据映射完全不用改动。这个模式我经常用来处理数据库和实体之间的简单转换，复杂的还是建议用ORM框架。

4. 性能优化：反射慢，但你可以让它几乎不慢

4.1 慢是有原因的

C#社区一提到反射，第一反应就是“慢”。诚然，反射调用比直接调用慢不少，原因有几个层面。首先是类型查找和成员查找，涉及到元数据解析和字符串比对，这一步比较耗时。其次是Invoke的参数处理，所有参数都要装箱成object数组，调用完成后再拆箱，值类型在这来回折腾的过程中会产生额外的分配。再次是安全检查和权限验证，CLR在反射调用时要做一层额外的校验。

但这个“慢”一定要分场景看。有些场景是程序初始化时执行一次的，慢个几十毫秒完全无感。真正需要担心的是高频调用路径上，比如每条指令都用反射Invoke去处理，那性能消耗就会积累起来。

4.2 缓存是第一好用的优化

最简单的优化，就是别每次都去GetMethod、GetProperty、GetCustomAttribute。这些元数据查询操作本身就比较重，而它们的结果在程序运行过程中通常是不会变的。把查询结果缓存起来，高频路径立刻变快很多。

我一般用一个静态的ConcurrentDictionary来做缓存，键是类型或方法名称，值是对应的Type、MethodInfo或PropertyInfo。

private static readonly ConcurrentDictionary<string, PropertyInfo> _propertyCache = new(); public static PropertyInfo GetCachedProperty(Type type, string propertyName) { string key = $"{type.FullName}.{propertyName}"; return _propertyCache.GetOrAdd(key, _ => type.GetProperty(propertyName)); }

写这个缓存的时候要注意线程安全，上位机项目里多个线程同时访问是常态。ConcurrentDictionary能保证原子性的GetOrAdd，直接拿来用是最稳妥的。

还有一点，缓存的粒度尽量细一点，不要缓存一个Type对象就万事大吉。比如MethodInfo本身也可以缓存，甚至在知道实例类型的前提下，把Delegate创建好缓存起来，后面直接用委托调用，这才是性能最优的做法。

4.3 CreateDelegate：把MethodInfo变成强类型委托

对高频调用的方法，把MethodInfo转成委托是一个性价比极高的优化手段。委托调用和普通方法调用的性能几乎在同一量级，完全甩开Invoke。

前面协议分发器的例子用过这个思路，这里再看完整写法：

MethodInfo method = typeof(Convert).GetMethod("ToInt32", new[] { typeof(string) }); Func<string, int> converter = (Func<string, int>)method.CreateDelegate(typeof(Func<string, int>)); int result = converter("12345");

CreateDelegate要求委托签名和方法签名严格匹配，包括参数顺序、类型、返回类型。如果方法有实例参数，需要用闭包或把实例作为委托参数传进去。比如一个实例方法，想用Action 来调用，就提前把实例绑定好。

C# 11之后有了MethodInfo.CreateDelegate，之前也有Delegate.CreateDelegate，两者本质上差不多，根据项目框架版本选择即可。

实际项目中我不会让业务代码直接依赖MethodInfo去创建委托，一般会在插件框架内部做一层封装，初始化阶段统一把各个Handler方法转成委托并放入分发字典，业务代码只看到委托调用。

4.4 表达式树方案：动态生成高性能调用

如果Delegate.CreateDelegate用不了，比如签名不固定、需要动态拼参数的情况，表达式树是另一个常用方案。表达式树可以把反射调用描述成一段代码结构，再编译成强类型委托。

using System.Linq.Expressions; var param = Expression.Parameter(typeof(string), "value"); MethodInfo method = typeof(Convert).GetMethod("ToInt32", new[] { typeof(string) }); var call = Expression.Call(method, param); var lambda = Expression.Lambda<Func<string, int>>(call, param); var compiled = lambda.Compile(); int num = compiled("42");

表达式树的优势是灵活：参数数量、类型都可以动态构造，只要构建规则一致，编译一次后就能复用。比如做一个通用值转换器，支持任意类型之间的转换，就可以用表达式树动态生成转换委托并缓存起来。

代价在于表达式树的构建和编译本身就比直接反射Invoke前期开销更大，所以它适合“构建一次、调用N次”的场景。代码里如果只是偶尔一两次调用，完全没必要上表达式树。

4.5 Emit和源码生成器：再快一步的代价

再往下走，就是IL.Emit和源码生成器的领域了。Emit可以通过动态生成IL代码，直接构建出和手写代码几乎无差别的调用逻辑，性能最接近原生，但开发难度和调试成本也很高。我只有在封装一些通用序列化、映射框架时才会考虑用Emit，业务项目里几乎不碰。

现代.NET还有个更优雅的方案是源码生成器，也就是Source Generator。它在编译期就生成好强类型调用代码，运行时完全不需要反射。像System.Text.Json的源生成模式就是这种思路。但源码生成器要求目标类型在编译期已知，对纯插件化、运行期动态加载DLL的场景并不适用。

所以选型建议是这样的：动态插件加载和运行期类型发现用反射，高频调用路径用缓存加委托，复杂的动态代码生成用表达式树，能在编译期定下来的强类型操作优先考虑源码生成器。反射不是不可替代，只是在它该出现的地方，它是最平衡的选择。

5. 常见问题与排查技巧实录

5.1 BindingFlags没写对，是90%“找不到”问题的根源

反射调用最容易出的异常就是MissingMethodException、MissingFieldException、MissingPropertyException。大部分情况下，排查到最后都是BindingFlags的问题。

GetMethod、GetProperty、GetField这些方法默认只查找公共的、实例级别的成员。如果你要查静态成员，必须加上BindingFlags.Static；要查非公共成员，必须加上BindingFlags.NonPublic | BindingFlags.Instance。想要在继承链上查找，还要加上BindingFlags.FlattenHierarchy或BindingFlags.Public | BindingFlags.Instance本身默认可以找到公共实例成员。

我自己的写法习惯是，只要发现“找不到目标”就先问自己几个问题：目标成员是Public吗？是Static还是Instance？在父类还是子类？有没有重载？然后试着带上对应的BindingFlags组合：

MethodInfo method = type.GetMethod("Execute", BindingFlags.Public | BindingFlags.NonPublic | BindingFlags.Instance | BindingFlags.Static);

需要我特别提醒的是：用BindingFlags.Public | BindingFlags.NonPublic这两个组合在一起用的时候，会匹配所有公共和非公共成员，但必须同时指定Instance或Static之一，否则在一些框架版本上还是找不到，因为默认的搜索行为不会自动包含两者。

5.2 非公共成员与安全性问题

访问非公共成员是个双刃剑。Invoke私有方法有时候确实能解决临时需求，但也容易出问题。比如混淆器会修改类型和成员的名称，编译器的内联优化也可能会影响方法的可见性。还有一个很现实的问题是，私有成员是内部实现的一部分，代码升级后随时可能改名、删掉或调整签名，你的反射代码就会碎得一地。

我见过有人用反射去改一个控件内部的私有字段来实现某些“黑科技”效果，当时跑得好好的，等第三方控件升级后程序直接崩了。所以真心建议：能公开接口就公开接口，能避免访问私有成员就尽量避免。反射不是用来突破访问控制的，而是用来做动态发现的。

另外在.NET Core和.NET 5+里，尝试触发一些特殊的安全校验也可能会抛出SecurityException或MethodAccessException，跨平台部署到Linux上时行为还不完全一样，这类问题排查成本很高。

5.3 混淆、AOT与剪裁：部署时的三个坑

给客户交付的工业软件，很多都会做混淆来保护知识产权。但混淆器会把类型名、方法名改成乱码，如果你的反射代码是按字符串名字查找的，那就直接G了。这里有个思路可以参考：尽量用接口判断或特性标记来代替字符串查找。比如判断一个类型是不是ICamera的实现，靠的是IsAssignableFrom、接口匹配，和类型名无关。用特性的话，即使类名被改了，只要特性还在，反射依然能找到。这类策略在插件化架构里尤其重要，我后来新写的加载器都是“优先接口，其次特性，最后才用名字”。

再说剪裁和AOT。发布.NET应用经常开启裁剪来缩小体积，但裁剪器会把反射用不到的类型移除，运行期就找不到了。解决方式有几种：用DynamicDependency特性声明需要的类型，用TrimmerRootAssembly指定程序集保留，或者干脆在裁剪配置里排除对反射依赖大的程序集。最稳妥的还是发布之前做一个完整的反射场景测试，别等到客户现场才暴露问题。

我踩过一次坑：写了一个配置文件解析器，用反射把配置节映射到对象属性上，结果发布为单文件后，部分配置解析失灵。排查了很久，发现是单文件发布的行为导致了程序集加载方式变化，某些类型没有被正确加载。后来调整为将动态加载的程序集存放在单独目录并使用LoadFrom，同时声明必要的依赖，问题才解决。

5.4 跨框架差异：.NET Framework与.NET 6+

在不同版本的运行环境里，反射API有一些细节差异，代码跨框架移植时要特别小心。.NET Framework里某些反射操作需要代码访问安全机制，而.NET Core/.NET 5+里很多安全策略已经移除了。还有一些API被标记为过时，比如Assembly.GetExecutingAssembly在部分场景下的行为，或者在不同部署形态下返回位置不同。

我自己常用的经验是在代码里通过TargetFramework来做条件分支，确保在多种环境部署时，反射代码尽量都走统一的写法。另外就是善用#if预处理指令处理框架差异代码，尽量少用“我猜这里应该没问题”的态度。

工控项目里，老设备上位机经常跑的是.NET Framework 4.x，新设备可能直接上.NET 8，一套代码要让两边都跑起来，这些框架差异就得提前规划。如果业务代码封装得足够好，只有框架层会接触到这些差异，至少能省掉很多调兼容性问题的时间。

5.5 典型问题速查表

这里额外说一个实用的小技巧。调试反射代码的时候，不要光看异常提示，要把InnerException一层层挖到底，很多时候真正的错误原因藏在三层以下。另外，把类型名、方法名、参数类型列表打出来，用日志记录一下，排查问题会比凭空猜测快很多。

6. 我在实际操作中总结的几条心得

反射这个东西，听起来很“底层”，但我觉得它更像是一个架构工具。用了它，程序的结构可以变得更灵活、更符合开闭原则：对扩展开放，对修改封闭。但正因为灵活，它也很容易变成一把没有准星的枪，在各处乱射会让代码变得极难追查。

我个人的体会是，反射代码最好集中收口在框架层、加载器、分发器这类基础设施里，不要散落在业务逻辑中。所有反射调用尽量走统一的封装，对外暴露强类型接口。这样就算踩坑，维护成本也只在封装层，不会污染整个代码库。

另外，保守地使用反射。我对团队有个不成文的约定：如果能在编译期解决问题，就不要引入反射；如果反射只是启动阶段用一次，可以用；如果处在高频路径上，必须配合缓存和委托优化；如果连委托都用不了，再考虑表达式树或源码生成器。

最后再说一个小技巧。给反射用的驱动类、处理器类，一定要设计好“可诊断性”。我习惯在插件基类里增加一个Describe方法，返回这类插件的名称、版本、支持的特性。这样程序启动后用反射加载插件，再到处打印一遍，整个系统里有哪些动态模块，一目了然，排查现场问题的时候帮助很大。

反射不是万能的，但掌握好它，C#的编程能力会往上走一个台阶。尤其是做上位机、机器视觉、设备通讯的朋友，面对各种品牌SDK、各种协议、各种现场变化，反射这手牌，值得你稳稳接住。