.NET 5+ 必须用 Microsoft.DiaSymReader（配合 Microsoft.DiaSymReader.Native），禁用已废弃的 System.Diagnostics.SymbolStore；Portable PDB 需显式指定 SymReaderType.PortablePdb，且需处理路径映射或 SourceLink 才能准确定位源码。
用 Microsoft.DiaSymReader 读取 PDB 文件最稳
直接上结论：.NET 5+ 项目必须用 Microsoft.DiaSymReader（特别是 Microsoft.DiaSymReader.Native 的跨平台支持），别碰老的 System.Diagnostics.SymbolStore —— 它在 .NET Core 以后就彻底不维护了，连 NuGet 包都标记为“deprecated”。
常见错误现象是调用 SymbolStore 相关类时抛出 PlatformNotSupportedException 或 FileNotFoundException，尤其在 Linux/macOS 上直接失败。
- 只支持 Windows 的旧方案：
ISymUnmanagedReader、SymbolStore类型，已废弃 - 推荐方案：安装
Microsoft.DiaSymReader+Microsoft.DiaSymReader.Native，后者提供原生 PDB 解析器（.pdb是微软私有格式，托管层无法纯靠 C# 解析） - 注意版本对齐：
Microsoft.DiaSymReader 4.8.0+才完整支持 Portable PDB（.NET Core 默认生成的格式），低于这个版本可能读不到源码行号或局部变量名
Portable PDB 和 Windows PDB 解析方式不同
你拿到的 .pdb 文件大概率是 Portable PDB（文本格式，实际是 ECMA-335 元数据嵌入或独立文件），不是传统 Windows PDB（二进制，需 dbghelp.dll）。这两者不能混用解析逻辑。
错误现象：用 DiaSymReader 打开一个 .NET 6 编译出的 app.pdb 却返回空方法列表，或者 GetSequencePoints() 始终返回零条 —— 很可能是没指定正确的 SymReaderType。
- Portable PDB：用
SymReaderType.PortablePdb（默认值，但显式指定更安全） - Windows PDB：用
SymReaderType.WindowsPdb，仅限 .NET Framework 项目或手动启用DebugType=full生成的旧式 PDB - 判断方法：用
dotnet --info看 SDK 版本；再查编译参数，若含<DebugType>portable</DebugType>（默认），就是 Portable PDB
IDiaSession 不是必需的，别被 COM 接口吓住
网上很多示例硬拉 IDiaSession、IDiaSymbol 这类 COM 接口，那是面向 Windows PDB 的老路子，需要注册 COM 组件、处理线程套间（STA）、还要引用 Microsoft.VisualStudio.Debugger.Interop —— 在 .NET 6+ 里纯属绕远路，还容易在容器或 CI 环境崩掉。
正确做法是走 IDiaDataSource.OpenSession() → session.GetSymbolsByAddr() 这条链，但前提是先用 Microsoft.DiaSymReader 封装好的托管入口：
var reader = SymReaderFactory.CreateReader(
pdbPath,
new Guid(), // module version GUID，可从 PE 头或 <code>.dll</code> 的 <code>AssemblyMetadata</code> 属性中读
SymReaderType.PortablePdb);
var method = reader.GetMethod(token); // token 来自 MethodDef RVA 或元数据 token
var points = method.GetSequencePoints(); // 这才是你要的源码映射-
token不是随便传的整数，得从目标程序集的元数据中提取（比如用Mono.Cecil或System.Reflection.Metadata读MethodDefinitionHandle） - 如果只要行号映射，不用符号名，
GetSequencePoints()返回的SequencePoint数组里含StartLine、EndLine、Document字段 - 文档路径（
Document.Url）可能是绝对路径，也可能是相对路径，取决于编译时PathMap设置
调试符号和源码路径不匹配是最大坑点
即使 PDB 能成功加载、方法也能遍历出来，SequencePoint.Document.Url 指向的源文件却打不开——这是最常卡住人的地方。原因不是解析错，而是构建环境和运行环境的路径不一致。
典型场景：CI 构建机器上的源码路径是 /home/builder/project/src/Program.cs，但你在本地打开的是 C:\dev\project\src\Program.cs，PDB 里存的就是前者。
- 解决办法一：编译时加
<PathMap>/home/builder/=C:\dev\</PathMap>（MSBuild 属性），让 PDB 把路径重写成你本地能认的 - 解决办法二：运行时用
SourceServer或SourceLink，PDB 里存的是 Git URL 和 commit hash，解析器自动下载对应源码（需网络+Git 工具） - 验证是否生效：用
dotnet symbol命令行工具 dump PDB，看Documentssection 输出的路径是否合理
没有路径映射，Document.Url 就只是个摆设。这点比解析逻辑本身更关键，也更容易被忽略。
