做.NET程序保护时，字符串通常是最容易先暴露业务意图的一层。Agile.NET官方文档把字符串保护放在独立的String Obfuscation功能里，目标就是把程序集string heap里的字面量隐藏起来，减少像授权提示、接口地址、连接信息这类明文直接暴露的情况；同时，官方也把它归在分层保护的一部分，建议和代码加密、虚拟化、重命名等能力配合使用，而不是只开一个选项就指望把所有风险都压住。

　　一、Agile.NET字符串混淆怎么用

　　字符串混淆真正有用，不在于把所有字符串一股脑全加密，而在于先把保护范围、兼容性和后续排查口径定清。Agile.NET官方说明里已经写明，字符串保护针对的是literal strings，也就是存放在string heap里的字面量；如果你一开始连哪些字符串会被处理都没分清，后面很容易出现开了保护却感觉效果不明显的情况。

　　1、先在工程里开启字符串保护

　　Agile.NET官方文档给出的启用方式比较直接，在工程配置中进入String Obfuscation页签，再启用隐藏敏感数据的相关选项即可。它的定位不是修改业务逻辑，而是把源代码里的字面量字符串转成受保护存储，在运行时按需解开使用，所以这一步适合作为保护配置里的第一层，而不是最后才补。

　　2、先筛敏感字符串再决定范围

　　从官方对String Encryption的介绍看，最典型的保护对象就是会暴露程序意图的敏感文本，例如授权相关提示、固定接口标识、错误提示关键词和连接信息。实际落地时，更稳的做法是先把许可证、授权、服务地址、关键规则提示语这类内容优先纳入保护，再逐步扩大范围，而不是一开始把所有显示文本全部混在一起处理。

　　3、const字符串要先改声明方式

　　这一点很容易被忽略。Agile.NET官方文档明确写到，它只能处理literal string values，不会处理const strings；如果确实希望这类内容也进入字符串保护范围，需要把const string改成static readonly string。很多项目明明开了字符串混淆，却发现部分关键文本仍然是明文，原因往往就卡在这里。

　　4、和重命名排除规则一起看

　　Agile.NET还支持通过System.Reflection.ObfuscationAttribute控制哪些类型和成员参与混淆。官方文档说明，默认会对程序集内部的private、internal、protected internal这类成员做混淆控制，同时可以用Exclude和ApplyToMembers调整范围。也就是说，字符串保护本身是一层，成员和类型是否继续参与其他混淆又是一层，这两套口径最好一起核对，避免保护范围和代码可维护性相互打架。

　　二、Agile.NET字符串解密点如何定位

　　这一部分最容易被误解成具体逆向步骤，但在工程管理里，更稳妥的理解应该是先区分对象，再决定能不能进入验证流程。对于第三方程序或未经授权样本，不应去做具体解密定位；如果对象是自有程序集，重点也不是研究如何还原保护，而是验证字符串保护是不是按预期生效、哪些位置仍然存在明文暴露。Agile.NET官方文档本身只说明字符串会在需要时于内存中解开使用，并没有把这部分作为外部调试能力开放。

　　1、先分清是不是自有程序集

　　如果对象不是自有程序，这个问题就不应继续往“定位解密点”方向展开，因为那已经超出正常保护配置和自测范围。对自有程序集来说，更合理的目标是确认敏感字符串是否还会在静态反编译结果里直接暴露，以及运行后是否仍会通过日志、异常提示或配置文件泄露出去。Agile.NET的官方定位始终是代码保护，而不是提供逆向分析接口。

　　2、用静态结果先做第一轮验证

　　自有程序最实用的做法，是先拿保护前和保护后的构建做只读比对，看敏感字面量是否仍在程序集里直接可见。因为官方已经说明，字符串保护的目标就是把string heap里的字面量转成受保护存储，所以第一轮验证最该看的不是运行期技巧，而是静态结果里这些关键词还在不在。

　　3、再用业务回归确认运行是否正常

　　字符串保护不是只看“藏没藏住”，还要看运行有没有被带坏。更稳的做法是重点回归登录、授权、配置读取、远程调用、异常处理和日志输出这些强依赖字符串的路径，确认保护启用后业务仍然正常。因为Agile.NET本身是分层保护方案，字符串混淆只是其中一层，真正上线前必须把兼容性作为单独检查项。

　　4、敏感信息不要只靠混淆兜底

　　如果字符串里本身放的是连接口令、账号密码或其他高敏感配置，就不要把混淆当成唯一保护手段。微软官方文档对.NET配置安全的建议很明确，像connectionStrings这类配置可以使用受保护配置机制加密，ASP.NET和ADO.NET也都明确提供了配置节加密的做法；对于现代.NET应用，官方还提醒不要把secrets直接写进配置文件。也就是说，Agile.NET更适合保护程序集里的实现细节，而真正的高敏感配置仍应回到配置加密、环境变量、密钥库这类机制上。

　　三、Agile.NET字符串保护为什么总是效果不稳

　　很多项目觉得字符串保护开了和没开差别不大，通常不是工具没能力，而是保护边界和工程口径没有先定住。只要把边界理顺，字符串保护的效果会稳定很多。

　　1、声明方式不统一

　　最常见的问题就是项目里一部分敏感文本写成literal string，一部分写成const string。Agile.NET官方已经说明const不在字符串混淆的处理范围里，所以同一套代码只要声明方式不统一，结果就一定会出现有的被保护、有的还明文可见。

　　2、把字符串保护当成全能方案

　　Agile.NET官方文档和产品说明都把字符串保护放在分层方案里，旁边还有代码加密、虚拟化、控制流混淆、重命名这些能力。要是把所有防护目标都压到字符串混淆一个选项上，最后往往会发现它能解决的是“明文暴露”问题，却解决不了整体逻辑暴露和调用关系暴露。

　　3、保护范围和排除规则互相冲突

　　项目里一旦同时用了声明式排除、成员例外和多层保护配置，就很容易出现某些类被保护、某些成员被豁免、某些字符串又没有进入目标范围的情况。官方对ObfuscationAttribute的说明已经把Exclude和ApplyToMembers的优先级写得很清楚，所以正式使用前最好把排除规则单独审一遍，不要边保护边猜。

　　4、上线前没有做两轮验证

　　真正稳妥的做法，是一轮看静态暴露有没有减少，一轮看运行兼容有没有受影响。前一轮确认字符串是否还直接暴露，后一轮确认授权、配置、日志和异常链路是否正常。把这两轮固定下来，字符串保护才不会每次都靠人工感觉判断。

　　总结

　　Agile.NET字符串混淆怎么用，关键不是把开关点上就结束，而是先把敏感字符串范围、const改造和排除规则一起定下来。Agile.NET字符串解密点如何定位，这个问题如果对象不是自有程序集，就不应进入具体定位；如果对象是自有程序，更合理的做法是把它转成保护有效性验证，先看静态明文是否消失，再看运行期业务是否正常。这样做下来，字符串保护才更像一套稳定的工程方案，而不是一次性的界面配置。