dotnet publish 不混淆代码，因其仅输出可反编译的il中间语言，混淆需额外工具介入；confuserex等工具需手动配置引用、排除反射类型及资源；混淆后须验证日志、符号重命名和运行时功能。
为什么直接用 dotnet publish 不会混淆代码
因为 .NET 6+ 默认发布的是可反编译的 IL 中间语言，dotnet publish 本身不带混淆能力，哪怕加了 --configuration Release 或 --self-contained true，生成的 .dll 和 .exe 仍能被 dnSpy、ILSpy 一键还原出近乎原始的 C# 代码。这不是“没优化”，是设计如此——.NET 的 JIT 编译依赖清晰的元数据，混淆必须由额外工具在编译后介入。
用 ConfuserEx 混淆时常见报错和绕过方法
ConfuserEx 是目前对 .NET Framework / .NET 5+（需配置）兼容性较好、规则灵活的开源混淆器，但容易卡在几个地方：
- 报错
"Could not resolve type reference"：说明它找不到你项目引用的某个第三方库（比如Newtonsoft.Json.dll），需在confuser-project.crproj的<reference></reference>节点里显式添加路径，不能只靠输出目录自动扫描 - 混淆后程序启动崩溃，错误含
"Method not found"或"Could not load type"：大概率是混淆了被反射调用的类/方法（如JsonConvert.DeserializeObject<t></t>里的T类型），得在规则里用<rule pattern="true"><protection id="rename"><exclude></exclude></protection></rule>排除对应命名空间或类名 - 混淆 WPF 应用时报
"Cannot locate resource"：XAML 编译生成的 BAML 资源名也被重命名了，必须关闭resource保护项，或改用Costura.Fody先合并资源再混淆
Dotfuscator 社区版限制与替代方案
Visual Studio 自带的 Dotfuscator Community Edition 实际上只支持 .NET Framework 项目，对 net6.0、net8.0 项目会静默跳过混淆，且不支持控制流混淆、字符串加密等关键功能。如果你用的是 SDK 风格项目（<targetframework>net8.0</targetframework>），它基本不可用。
可行替代路径：
- 改用
Obfuscar（开源，CLI 工具）：支持 .NET Core+，配置简单，但仅提供基础重命名和控制流扁平化，不加密字符串 - 用
ILPack+ConfuserEx组合：先用ILPack把所有依赖打包进单个.dll，再交给ConfuserEx处理，避免多 DLL 引用解析失败 - 商业方案如
Eazfuscator.NET（已停更）或SmartAssembly：后者对现代 .NET 支持较好，但价格高、命令行集成麻烦
混淆后必须手动验证的三件事
混淆不是“一按就完事”，漏掉验证等于白做：
- 检查日志输出里有没有
"Skipped"或"Warning: unable to process"行——这些往往意味着某类型没被混淆，但你并不知道它是否被外部调用 - 用
ildasm打开输出的.dll，搜索关键业务类名或方法名，确认它们已变成a、b__1这类无意义符号；同时确认Program.Main和入口点仍在，否则无法启动 - 真实运行一次，重点测：配置文件加载（
IConfiguration）、JSON 序列化（System.Text.Json）、DI 容器注册（services.AddScoped<itest testimpl>()</itest>）——这些地方一旦混淆出错，异常堆栈极难定位
混淆的本质是破坏静态分析路径，不是让代码“变安全”。只要程序要运行，IL 就得能被 JIT 读取，攻击者总能从内存 dump 或运行时 hook 中拿到明文逻辑。真正该花力气的地方，是把密钥、算法、授权校验放到服务端，而不是指望本地代码混淆拦住所有人。
