一、反射机制的前世今生
反射就像是程序界的"X光机"，它能让我们在运行时动态地查看和操作类型信息。想象一下，你手里有个黑盒子（程序集），不知道里面装了什么，但通过反射就能像拆礼物一样一层层打开它。
在C#中，System.Reflection命名空间提供了全套工具。比如你想知道一个类有哪些方法，可以这样：
// 技术栈：.NET 6
Type type = typeof(MyClass);
MethodInfo[] methods = type.GetMethods(); // 获取所有公共方法
foreach (var method in methods)
{
Console.WriteLine($"方法名：{method.Name}, 返回类型：{method.ReturnType}");
}
class MyClass
{
public void DoWork() { }
public int Calculate(int x) => x * 2;
}
但这里有个隐患：如果两个程序集包含同名类型，直接使用Type.GetType("ClassName")可能会加载到错误的类型。就像在超市里喊"老王"，可能有五个大叔同时回头。
二、类型冲突的典型场景
当动态加载多个版本的程序集时，冲突就像办公室里的同名同事一样常见。例如：
// 加载两个不同版本的程序集
Assembly libV1 = Assembly.LoadFrom("MyLibV1.dll");
Assembly libV2 = Assembly.LoadFrom("MyLibV2.dll");
// 尝试获取类型（危险操作！）
Type problematicType = Type.GetType("MyNamespace.DataModel");
// 可能加载到V1或V2中的类型，取决于加载顺序
更可怕的是，即使使用完全限定名（包含程序集名称），如果两个程序集强名称相同但内容不同，CLR可能认为它们是同一个程序集。这就像两本同名的书被错误地放在同一个书架上。
三、解决方案：隔离与精确控制
3.1 使用加载上下文隔离
.NET提供了AssemblyLoadContext这个"隔离舱"：
// 创建独立的加载上下文
var alc = new AssemblyLoadContext("MyIsolationContext", true);
// 在该上下文中加载程序集
Assembly isolatedAssembly = alc.LoadFromAssemblyPath("MyLibV2.dll");
// 精确获取类型（推荐做法）
Type safeType = isolatedAssembly.GetType("MyNamespace.DataModel");
这相当于给每个程序集分配独立的房间，避免他们在走廊里撞见。
3.2 程序集强名称与版本控制
给程序集穿上"防撞服"：
<!-- 项目文件中的强名称配置 -->
<PropertyGroup>
<AssemblyName>MyLib</AssemblyName>
<AssemblyVersion>2.0.1.0</AssemblyVersion>
<AssemblyPublicKey>...</AssemblyPublicKey>
</PropertyGroup>
然后在代码中精确指定：
AssemblyName asmName = new AssemblyName
{
Name = "MyLib",
Version = new Version("2.0.1.0")
};
Assembly safeLoaded = Assembly.Load(asmName);
3.3 类型解析策略
实现自定义解析逻辑，就像交通警察指挥车辆：
// 注册类型解析事件
AssemblyLoadContext.Default.Resolving += (context, assemblyName) =>
{
if(assemblyName.Name == "ConflictLib")
{
return Assembly.LoadFrom(@"C:\SafePath\ConflictLib_v2.dll");
}
return null;
};
四、实战：插件系统设计
让我们用反射构建一个安全的插件系统：
public class PluginHost
{
private readonly Dictionary<string, AssemblyLoadContext> _contexts = new();
public void LoadPlugin(string pluginPath)
{
// 为每个插件创建独立上下文
var alc = new AssemblyLoadContext(Guid.NewGuid().ToString(), true);
// 加载主程序集
Assembly pluginAssembly = alc.LoadFromAssemblyPath(pluginPath);
// 获取插件入口类型（使用完全限定名）
Type entryType = pluginAssembly.GetType("MyPlugin.EntryPoint");
// 存储上下文引用
_contexts[pluginPath] = alc;
}
public void UnloadPlugin(string pluginPath)
{
if(_contexts.TryGetValue(pluginPath, out var alc))
{
alc.Unload(); // 关键！释放资源
_contexts.Remove(pluginPath);
}
}
}
注意事项：
- 卸载上下文需要.NET Core 3.0+
- 避免跨上下文传递类型实例
- 监控内存泄漏（卸载后检查GC行为）
五、性能与安全的平衡艺术
反射虽强大，但过度使用就像用显微镜切菜——能行但效率低。建议：
- 缓存反射结果：
// 使用字典缓存MethodInfo
private static ConcurrentDictionary<string, MethodInfo> _methodCache = new();
- 优先使用泛型约束而非纯反射：
public void Process<T>() where T : IPlugin
{
// 编译器会进行类型检查
}
- 考虑用表达式树替代高频反射：
// 编译为高效代码
var param = Expression.Parameter(typeof(MyClass));
var call = Expression.Call(param, "DoWork", Type.EmptyTypes);
var lambda = Expression.Lambda<Action<MyClass>>(call, param);
Action<MyClass> compiled = lambda.Compile();
六、总结与最佳实践
经过这些年的项目实战，我总结出反射使用的"三要三不要"：
要：
- 要明确程序集加载边界
- 要处理版本依赖关系
- 要监控加载上下文生命周期
不要：
- 不要假设类型唯一性
- 不要跨上下文混合使用对象
- 不要忽视卸载机制
最后记住，反射是瑞士军刀，但不是所有问题都需要它解决。当你能用接口实现多态时，就别劳驾反射了。
评论