Agile.NET做过保护后，反射相关功能突然失效，最常见的表象是Type.GetType找不到类型、GetMethod返回空、Activator.CreateInstance报错，或插件扫描阶段直接崩。根因往往不在反射本身，而在保护阶段改变了元数据名称与字符串内容，导致运行期仍用原名去定位成员，最终出现调用路径断裂。

　　一、Agile.NET保护后反射调用失效为何会发生

　　反射失效并不等同于程序整体被破坏，更多是个别成员名称或资源名称被改写后，调用方仍按旧规则查找造成的。排查时应先把失效点按调用链拆开，确认是重命名命中、字符串被处理，还是跨程序集引用未纳入统一改名范围。

　　1、成员被重命名但反射仍按原名查找

　　当代码用字符串写死方法名、属性名、事件名时，保护阶段的Symbol Renaming会改变这些元数据名称，反射调用点却不会自动同步，结果就是GetMethod或GetProperty直接找不到目标成员。

　　2、启用了跨程序集重命名但引用程序集未全部纳入

　　开启Cross Assembly Obfuscation后，Agile.NET会把公共成员也纳入改名，并要求把软件组成的相关程序集都加入工程，否则某些外部引用无法统一改写，反射或插件扫描就可能在边界处断掉。

　　3、字符串保护影响到反射所依赖的类型名与成员名字符串

　　不少程序会把完整类型名、工厂键、命令名放在字符串常量里，再通过反射解析与调用，若开启String Obfuscation或命令行的SecureStrings，字符串在运行期取值路径改变或被延迟解密，容易出现找不到类型或匹配不到成员的现象。

　　4、使用了映射不一致的构建产物导致同一成员在不同版本被改成不同名字

　　补丁版本若未复用上一版的Obfuscation Map，重命名结果可能变化，反射若依赖持久化数据、缓存清单、旧配置文件中的成员名，就会在新版本里失配，表现为部分用户升级后才报错。

　　5、Agile.NET的智能排除没有覆盖到自定义反射用法

　　Agile.NET会基于常见模式做smart rules并自动排除一部分可能影响反射的成员，但如果项目里有自定义扫描框架、脚本引擎、IOC容器或插件体系，调用方式不典型时就可能漏判，需要人工补充排除清单。

　　6、序列化与框架约定对名称稳定性有硬要求

　　例如某些可序列化对象、老数据反序列化、或依赖成员名约定的框架，会对名称稳定性非常敏感，一旦改名就会产生兼容性问题，因此很多工具会默认避开这类类型，或要求开发者主动声明不应改名。

　　二、Agile.NET反射成员保留规则应怎样设定

　　设定保留规则的目标是保留反射链路所需的名称稳定性，同时尽量不牺牲其他保护层。实际落地通常分两条线并行推进，一条在Agile.NET里做重命名排除，另一条在代码层用声明式属性把必须保留的成员固定下来。

　　1、先建立反射依赖清单，明确哪些名称必须稳定

　　从代码与配置两侧同时梳理，重点抓三类：Type.GetType或Assembly.GetType用到的完整类型名，GetMethod与GetProperty用到的成员名，依赖特性与字符串键的注册项如插件标识、路由名、命令名。清单写清楚命名空间、类型名、成员名与调用方位置，后续才能精确排除，避免把整个程序集都放开导致保护效果下降。

　　2、在Agile.NET里优先做Renaming级别的定点排除

　　打开Agile.NET工程后进入【Renaming】页，先按正常方式勾选需要保护的程序集与重命名方案，然后点击页面提示的排除入口文本【I want to specifically exclude members from the obfuscation】，在排除列表里把清单中的类型与成员逐条加入，优先把反射入口类、插件入口类、以及通过字符串定位的成员设置为不参与重命名。

　　3、谨慎开启跨程序集重命名并确保程序集集合完整

　　若确实需要隐藏公共成员名，在【Renaming】页勾选【I want to hide public members of my code using cross assembly obfuscation】前，先确认产品运行链路涉及的所有程序集都已添加进Agile.NET工程，即便其中部分程序集暂时不做其他保护，也要保证重命名能跨程序集一致生效，避免出现一边被改名一边仍按旧名引用的断裂。

　　4、对必须保留的代码元素使用声明式ObfuscationAttribute固化规则

　　对于明确不能被改名的类型或成员，可在源码中标注System.Reflection.ObfuscationAttribute，Agile.NET文档说明该属性的Exclude默认值为True且可控制是否参与混淆，并支持ApplyToMembers控制是否作用于成员；实践中可用它把反射目标固定下来，并通过更细粒度的标注避免整类整包全部放开。

　　5、针对字符串驱动反射的模块单独处理字符串保护范围

　　若反射依赖的类型名与成员名来自字符串常量或资源文件，建议先在工程里把这部分字符串来源集中，随后在Agile.NET的保护配置中降低该模块的String Obfuscation强度，或把关键字符串所在程序集先做验证性禁用，再逐步开启以定位是哪一项导致失配。

　　6、把排除规则与版本映射一起纳入构建流程避免回归

　　当排除清单稳定后，在每次发布都复用同一份Obfuscation Map，确保同一符号在不同版本的改名保持一致，尤其是存在增量发布、热更新、或用户侧缓存反射键的场景，这一步能显著减少升级后反射失效的偶发问题。

　　三、Agile.NET发布回归与映射文件如何维护

　　规则设好后仍需要一套可重复的回归动作，把问题拦在交付前，同时把现场异常的定位成本压下去。

　　1、建立最小可复现用例覆盖三类反射路径

　　至少覆盖按字符串取Type、按字符串取成员、以及插件扫描式枚举三类路径，每次保护后先跑这组用例，确认返回值不为空且能完成Invoke或实例化，再进入完整回归，避免在大规模测试里才发现反射链路断裂。

　　2、把Map文件作为交付物的一部分进行版本化保存

　　Agile.NET会生成XML格式的映射文件用于符号对应与异常定位，建议按版本号与构建号归档保存，并与发布包一一对应，既用于增量版本复用映射，也用于定位客户侧堆栈信息。

　　3、现场异常需要还原堆栈时使用内置解码入口

　　在Agile.NET主界面点击【decode stack trace】打开解码窗口，选择该版本对应的map文件，把客户提供的stack trace粘贴到obfuscated stack trace区域，再点击【decode】得到decoded stack trace，随后回到排除清单与映射复用设置上做针对性修复。

　　4、需要接入流水线时用命令行统一执行参数与工程文件

　　若团队使用持续集成，可使用AgileDotNet.Console并通过Project参数读取同一份工程配置，确保本地与流水线的保护选项一致，同时把输出目录与映射文件归档路径固定下来，减少因人工改配置导致的反射回归。

　　总结

　　Agile.NET保护后反射失效，核心原因通常是重命名与字符串处理改变了运行期查找所依赖的名称与键值，跨程序集重命名与映射不复用会进一步放大不一致。处理思路应以反射依赖清单为起点，在【Renaming】中做定点排除，同时用System.Reflection.ObfuscationAttribute把必须稳定的成员固化，再配合映射文件复用与最小回归用例，把反射链路从偶发问题变成可控配置项。