不能直接反编译dll得到原始c#源码，只能还原接近的等效代码；dnspyex是最常用gui工具，支持实时调试和在线编辑，但需未强签名；ildasm/ilasm可精准修改il但门槛高；dotnet-dump适用于运行时分析；混淆dll难以还原变量名与控制流。
不能直接“反编译”DLL得到原始C#源码，只能还原接近的、可读的等效代码；还原质量取决于是否带调试符号、是否混淆、目标框架版本。
用 dnSpy 打开 DLL 看代码最常用
这是目前最轻量、响应快、支持实时调试的 GUI 工具，适合快速查看逻辑。它底层用的是 ICSharpCode.Decompiler，对 .NET Framework 和大部分 .NET Core/.NET 5+ 程序集兼容性好。
- 下载地址是 GitHub 上的
dnSpyEx（原版已停更，dnSpyEx持续维护） - 直接拖拽 DLL 进去就能展开命名空间和类——但若看到全是
IL_0001:开头的指令，说明没嵌入 PDB 或被剥离了调试信息 - 右键方法 → “Edit Method (C#)” 可以在线修改再重新编译，但仅限未强签名的程序集
- 如果打开后显示“Cannot resolve type”或大量
<privateimplementationdetails></privateimplementationdetails>，大概率是用了 IL 合并或混淆（比如ConfuserEx）
ildasm 和 ilasm 是看/改 IL 的底层组合
Windows SDK 自带的 ildasm.exe 能把 DLL 拆成人类可读的 IL 汇编（.il 文件），配合 ilasm.exe 可重新组装——这是真正“可控”的反编译路径，但门槛高、易出错。
-
ildasm MyLib.dll /output=MyLib.il：导出 IL，注意加/source参数才能保留行号信息（需原始 PDB） - 修改 .il 文件后，用
ilasm MyLib.il /output=MyLib_patched.dll重建，但会丢失强签名，运行时若校验失败就直接抛System.IO.FileLoadException - 不推荐新手改 IL：一个
.maxstack写错或局部变量类型不匹配，就会导致VerifyException或 JIT 失败 - 适合场景：绕过简单 license 检查、修复已知 bug、分析异常处理结构
用 dotnet-dump + clrstack 查运行时方法体（非静态反编译）
当 DLL 已加载进进程、且你想看它实际执行的是哪段逻辑（比如热更新后行为变了），静态反编译可能失效，这时得抓运行时快照。
- 先用
dotnet-dump collect -p <pid></pid>抓 dump，再用dotnet-dump analyze <dumpfile></dumpfile> - 执行
clrstack -a查当前调用栈里的方法参数和局部变量值；配合dumpil <methoddesc></methoddesc>可看到 JIT 后的真实 IL - 这个方式不依赖 PDB，但要求进程是 .NET Core 3.0+ 或 .NET 5+，且没禁用调试代理
- 注意：JIT 编译后的 IL 可能和原始 DLL 不一致（比如内联优化、空分支裁剪）
混淆过的 DLL 几乎无法还原出有意义的变量名和控制流；哪怕用 de4dot 脱壳，也常卡在字符串加密或控制流扁平化上。别指望一键“恢复源码”，重点应放在理解接口契约和数据流向——比如先看 Assembly.GetExportedTypes() 输出了哪些公开类，再逐个 inspect 它们的 public 方法签名。
