vscode的c#调试器不支持直接“附加到进程”列表，必须手写launch.json的attach配置，目标进程需启用调试端口并提供匹配的.pdb符号文件。
VSCode 无法直接“挂载进程”，必须用 vsdbg 配合 attach 模式
VSCode 的 C# 调试器（基于 vsdbg）不支持像 Visual Studio 那样点选“附加到进程”就弹出列表。它只支持通过配置 launch.json 显式声明 attach 行为，且目标进程必须已启用调试端口并暴露符号信息。
常见错误现象是点击“附加到进程”后列表为空、或选中进程后报 Failed to attach to process —— 这不是 VSCode 界面问题，而是目标进程根本没启动调试服务。
- 控制台应用默认不监听调试端口，需手动加参数启动：
dotnet run --configuration Debug --no-build -- --environment Development（仅对 ASP.NET Core 有效） - 真正通用的做法是：先用
dotnet exec --runtimeconfig MyApp.runtimeconfig.json --depsfile MyApp.deps.json bin/Debug/net8.0/MyApp.dll启动，并确保bin/Debug/net8.0/MyApp.pdb存在且路径可读 - 然后在
launch.json中配置type: "coreclr"+request: "attach"，指定processId或pipeTransport
attach 模式下 launch.json 必须手动写，不能靠“自动生成”
VSCode 的 Debug: Open launch.json 命令只会生成 request: "launch" 配置，对 attach 场景完全无效。你必须手写一个合法的 attach 配置块，否则 F5 会直接报错 Cannot resolve debug type 'coreclr' 或 Missing required property 'processId'。
关键字段含义：
-
processId：必须是整数 PID，不能填进程名；可用ps aux | grep MyApp（Linux/macOS）或tasklist /fi "imagename eq MyApp.exe"（Windows）查到 -
pipeTransport：用于跨容器或远程场景，pipeCwd必须指向含.dll和.pdb的目录，debuggerPath要设为/home/vsdbg/vsdbg（Linux 容器内）或C:\vsdbg\vsdbg.exe（Windows 远程） -
justMyCode设为false才能进入 .NET 运行时内部方法（如System.Collections.Generic.List`1.Add），但会显著拖慢调试响应
示例最小可用 attach 配置：
{
"version": "0.2.0",
"configurations": [
{
"name": "Attach to MyApp",
"type": "coreclr",
"request": "attach",
"processId": 12345,
"justMyCode": true
}
]
}
进程必须带 PDB 符号文件，且路径不能被重定向或压缩
vsdbg 在 attach 时不会重新编译或生成符号，它只按硬编码路径加载 .pdb。如果 MyApp.dll 是从 NuGet 包加载的、或被 ILMerge 合并过、或部署时删了 .pdb，attach 会静默失败——断点全灰，变量显示 <optimized out></optimized>。
- 确认
.pdb存在：ls -l bin/Debug/net8.0/MyApp.*应同时列出.dll和.pdb - 检查 PDB 关联是否正确：用
dotnet symbol --list bin/Debug/net8.0/MyApp.dll（需先dotnet tool install -g dotnet-symbol） - 避免使用
dotnet publish --self-contained后 attach：self-contained 会把运行时和依赖打包进单个目录，但.pdb默认不随发布输出，需显式加<copysymbolstooutputdirectory>true</copysymbolstooutputdirectory>到.csproj
底层调试依赖 vsdbg 二进制，不是 OmniSharp
很多人以为 C# Dev Kit 或 OmniSharp 负责 attach 调试，其实它们只管代码补全和项目解析；真正执行 attach 的是独立进程 vsdbg，它由 dotnet CLI 下载并缓存在 ~/.vsdbg（macOS/Linux）或 %USERPROFILE%\.vsdbg（Windows）。
容易踩的坑：
-
vsdbg版本必须与项目TargetFramework匹配：net8.0 项目不能用 net6.0 的 vsdbg，否则 attach 后立即断开 - macOS 上若用 Rosetta 运行 x64
vsdbg调试 ARM64 进程，会卡死无响应；必须确保dotnet --list-sdks输出的 SDK 架构与目标进程一致 - Linux 容器内 attach 时，
vsdbg需要ptrace权限，Docker 启动需加--cap-add=SYS_PTRACE，否则报Operation not permitted
最常被忽略的是：attach 成功 ≠ 调试可用。即使进程列表里看到名字、F5 不报错，若符号路径错、架构不匹配、或 justMyCode 开关不当，断点依然不会命中——得看 Output 面板里 Debug 和 vsdbg 两个通道的日志才能定位真实原因。
