在Agile.NET里做代码虚拟化，最容易走偏的地方，不是不会勾选功能，而是把“适合虚拟化的方法”和“应该覆盖多大范围”混成一件事。SecureTeam官方文档把这两层分得很清楚。虚拟化本质上是把选中的MSIL方法转换成只被内部虚拟机理解的虚拟指令，而且是按方法级来选，不是默认把整套程序集一起虚拟化；同时，官方又专门给了方法选择建议、性能提示和不适用场景。这意味着真正稳的做法，不是先求覆盖面最大，而是先挑对方法，再控制范围。

　　一、Agile.NET代码虚拟化怎么选方法

　　选方法时，先不要看“这个函数重不重要”这么笼统，而要看它是不是高价值、低频率、又不容易因为虚拟化带来明显性能拖慢。官方在Code Virtualization文档里已经把优先级写得很直接，适合优先考虑的，是带有较高知识产权价值、容易被逆向或直接关系到访问控制的那类方法。

　　1、先选高价值方法

　　官方建议优先虚拟化这几类方法，也就是初始化或分阶段放行的方法、负责许可校验的方法、承载核心算法的方法，以及包含数据库连接、密码或基础设施信息的方法。换句话说，真正应该先上的，不是普通业务胶水代码，而是被逆向后最有价值、最容易被利用的那一层。

　　2、再看是不是低频调用

　　Agile.NET官方在性能说明里明确提醒，保护后变慢，最常见原因是把包含复杂计算迭代的方法拿去虚拟化了。因此更稳的经验不是“核心算法一定全部虚拟化”，而是先看它是不是高频热点。如果某个方法会被大量循环调用，直接虚拟化往往会把性能代价放大。

　　3、重算法不要先虚拟化本体，优先虚拟化入口

　　官方给出的直接建议是，若你想控制某个计算密集型方法的访问，可以优先保护它外层的gateway methods，也就是调用它、但本身不重计算的入口方法。这个思路很实用，因为它既能把关键访问点藏起来，又比直接把重计算主体塞进虚拟机更容易控制性能损耗。

　　4、先排掉不适用的方法

　　按当前公开手册，Agile.NET把几类场景列为不能应用代码虚拟化，包括generic methods、定义在struct内的实例方法、接受ref或out参数的方法、调用这类方法的方法，以及内部调用了Assembly.GetExecutingAssembly、MethodBase.GetCurrentMethod、Assembly.GetCallingAssembly的方法。真正选方法时，先把这些场景排掉，会比后面保护失败再回头返工更稳。

　　5、最后再到【Code Virtualization】里逐个选方法

　　官方操作路径本身也说明了它更适合精确选点，而不是大面积全开。标准做法是在【Code Virtualization】页签里勾选虚拟化单个方法，然后点击【Select Methods...】进入方法选择窗口，再把目标方法挑出来。这个入口本身就说明，Agile.NET的虚拟化策略更偏向方法级精细控制。

　　二、Agile.NET虚拟化范围怎么划

　　虚拟化范围怎么划，核心不在于“多大面积最安全”，而在于“哪一圈代码最值得进虚拟机”。从官方文档给出的选型原则看，范围划分更适合从少量高价值方法开始，而不是按模块整片铺开。因为一旦范围过宽，性能、兼容性和后续排错成本都会一起抬高。

　　1、先按功能边界划，不按文件数量划

　　更稳的切法通常是按功能边界来挑，例如许可校验链路、功能解锁链路、核心业务判定链路、关键算法入口这几类，而不是简单按某个类文件有多少方法去圈范围。官方推荐的虚拟化对象，本身就集中在许可、初始化、核心算法和敏感信息处理这几条线上，所以范围也更适合沿这些边界来收。

　　2、范围先小后大，不要第一次就全模块覆盖

　　Agile.NET文档没有鼓励全局大面积虚拟化，反而一直在强调方法选择和性能权衡。更实用的做法通常是先保护最敏感的几组入口方法，验证兼容性和性能，再决定是否往外扩。这样做的好处是，一旦出现启动、调用或性能异常，排查范围更小。这个判断是根据官方方法级选择模式和性能建议得出的。

　　3、把热点路径划到范围外

　　如果某段代码本身就在高频循环、批量计算或大吞吐路径上，那它通常不适合直接进入第一批虚拟化范围。官方已经明确指出，复杂计算迭代场景是性能下降的主要来源，因此划范围时，热点路径更适合先留在范围外，把保护重点放到它们的入口、开关和校验逻辑上。

　　4、反射敏感和特殊签名方法单独排除

　　范围划定时，不能只看业务价值，还要看技术限制。按官方当前公开手册，涉及特定反射调用、generic、struct实例方法以及ref或out参数链路的方法，本身就不适合放进虚拟化范围。所以划范围时，最好先按这类技术约束做一轮过滤，再谈保护强度。

　　5、一般混淆范围和虚拟化范围不要混着管

　　SecureTeam的Declarative Obfuscation文档说明，Agile.NET支持通过`System.Reflection.ObfuscationAttribute`去控制类和成员是否参与一般混淆，而且可以用`Exclude`和`ApplyToMembers`去控制类型与成员级别的处理范围。更稳的做法，是把“普通混淆范围”和“虚拟化方法范围”分开管理：前者可以靠属性做总体约束，后者仍然在【Code Virtualization】里按方法精确选择。

　　三、Agile.NET虚拟化策略怎么收口

　　真正把虚拟化做稳，重点不是一次选得多，而是让保护收益、兼容性和性能代价三者平衡。Agile.NET官方文档其实已经给出了一个很清楚的收口思路，也就是优先保护高价值但不重计算的方法，把热点和不适用方法排除，再用方法级选择逐步扩展，而不是把虚拟化当成全局开关。

　　1、第一批只保核心入口

　　第一次上虚拟化时，更稳的方式通常是只覆盖少量核心入口，例如授权校验、功能启用、核心算法入口和关键初始化判断。这样既符合官方推荐的保护对象，也能把第一次上线的风险控制在较小范围内。

　　2、第二批再补敏感信息处理

　　如果第一批已经验证通过，再往外扩时，更适合补那些处理连接信息、密码、企业基础设施信息和关键安全判断的方法，而不是立刻把整段业务流程一起拖进来。因为官方把这些代码列为高价值对象，但它们往往又不像大循环算法那样容易触发明显性能问题。

　　3、性能异常优先回退到gateway方案

　　如果上线后发现性能下降，不要先怀疑整个产品不适合虚拟化。更优先的调整方向，通常是把重计算主体从虚拟化范围里移出来，仅保留它外层的gateway method。这个回退路径就是官方明确给出的性能折中方案。

　　4、最终形成一套固定筛选规则

　　更长期可用的做法，不是每次凭经验挑方法，而是固定一套选择标准，例如高价值、低频调用、非反射敏感、非ref或out、非generic、非热路径优先。这样后面新版本继续扩大或调整虚拟化范围时，就不会反复从零判断。这个做法虽然是实施建议，但完全顺着官方的方法选择、限制和性能原则展开。

　　总结

　　Agile.NET代码虚拟化怎么选方法，关键是优先挑授权校验、初始化控制、核心算法入口和敏感信息处理这类高价值方法，同时避开重计算热点和官方列出的不适用场景。Agile.NET虚拟化范围怎么划，关键则是按功能边界从小范围方法级保护开始，把普通混淆范围和虚拟化范围分开管理，再逐步扩展。等这两步都走顺以后，虚拟化就不会变成“全开更安全”的粗放做法，而会更接近一套可控、可调、可维护的保护策略。