.NET代码混淆核心是延缓破解而非绝对防护，推荐方案：新项目用.NET Native AOT+IL Trimming，老项目用ConfuserEx，企业级交付选Dotfuscator或SmartAssembly，并同步删除PDB、服务端校验、配置加密等基础防护。
对.NET程序（尤其是C#编写的桌面应用或类库）进行代码混淆，核心目标是增加反编译难度、保护业务逻辑和敏感字符串，但不能完全阻止逆向——它属于“延缓破解”而非“绝对防护”。以下为实用、可落地的混淆方案，聚焦主流工具与关键配置。
使用官方推荐：.NET Native AOT + IL Trimming（适用于.NET 6+）
这是微软当前主推的轻量级保护方式，尤其适合发布独立部署的应用：
- 启用AOT编译后，C#代码会被提前编译为原生机器码（x64/ARM64），IL代码大幅减少甚至消失，反编译器（如dnSpy）几乎无法还原原始逻辑；
- 配合PublishTrimmed=true和TrimMode=partial，可移除未使用的框架API和元数据，进一步压缩体积并削弱反射攻击面；
- 需注意：AOT不支持动态代码（eval、Reflection.Emit、大部分序列化器如Newtonsoft.Json默认模式），需提前适配或改用System.Text.Json并标注[JsonSerializable]。
专业混淆：ConfuserEx（免费开源，适合.NET Framework/.NET Core 3.1）
ConfuserEx仍是中小项目最常用的混淆工具，配置灵活、效果直观：
- 下载最新版（推荐 GitHub 上的 mkaring/ConfuserEx 分支，修复了新版.NET兼容问题）；
- 通过confuser.crproj配置文件定义规则，重点开启：anti-debug（干扰调试器）、ctrl-flow（控制流扁平化）、constants（字符串加密）、rename（标识符重命名）；
- 慎用anti-tamper：它会注入校验逻辑，但易被绕过且可能触发杀软误报；建议仅在关键模块启用，并搭配自定义校验逻辑（如比对程序集哈希）；
- 混淆后务必测试：检查日志输出、异常堆栈是否仍可读（可保留debug符号用于内部调试，发布包中删除.pdb）。
商业增强：SmartAssembly 或 Dotfuscator（适合企业级交付）
若需更高强度保护（如防内存dump、反调试深度集成、许可证绑定），可考虑这两款工具：
- SmartAssembly 支持运行时水印（记录调用者环境）、方法级加密、崩溃报告混淆，界面友好，适合WinForms/WPF项目；
- Dotfuscator（Prisync出品，已整合进Visual Studio企业版）与MSBuild深度集成，支持条件混淆（如仅混淆Release配置）、资源加密、以及针对.NET 5+的IL重写优化；
- 两者均提供试用版，建议先用Demo混淆核心DLL，用dnSpy验证反编译结果是否丢失变量名、流程跳转是否混乱、字符串是否不可见。
必须同步做的基础防护（常被忽略）
混淆只是链条一环，脱离这些措施效果大打折扣：
- 发布前删除所有.pdb文件，禁用DebuggableAttribute（在AssemblyInfo.cs中移除或设为false）；
- 敏感逻辑（如License校验、API密钥）不要硬编码，改用服务端验证 + 临时Token机制；客户端只做基础签名校验；
- 用InternalsVisibleTo替代public暴露内部类型，限制单元测试以外的程序集访问；
- 对关键配置文件（如appsettings.json）启用AES加密存储，密钥由硬件ID或系统信息派生，不在代码中明文出现。
基本上就这些。混淆不是银弹，而是分层防御里的一层。优先保障核心逻辑走服务端、关键数据不落地、再叠加合适强度的混淆，才能真正提升攻击成本。工具选型上，新项目优先试AOT，老项目平稳过渡用ConfuserEx，有预算且要交付给客户就上Dotfuscator。
