program必须指向AOT生成的.exe而非.dll，type需设为"clr"并确保安装C#扩展v2.0+，同时构建时启用--generate-debug-symbols保留.pdb文件。
launch.json 中 program 路径必须指向 AOT 输出的 .exe，而非 .dll
VS Code 默认调试配置（coreclr 类型）假设目标是 JIT 模式下的托管程序集（.dll），但 AOT 编译后生成的是原生可执行文件（如 MyApp.exe 或 MyApp），直接运行 .dll 会报错或静默失败。
- 错误现象：
Could not find or load file 'MyApp.dll'或启动后立即退出无日志 - 正确做法：在
launch.json的program字段中明确指定 AOT 构建产物路径，例如："program": "${workspaceFolder}/bin/Release/net8.0/win-x64/publish/MyApp.exe" - 注意：
--self-contained和--publish-aot生成的目录结构里不含 .dll 入口，不要复用 JIT 的bin/Debug/net8.0/MyApp.dll路径
必须启用 --generate-debug-symbols 并保留 .pdb 文件
AOT 编译默认剥离调试符号，导致 VS Code 断点不命中、调用堆栈显示为 Unknown location。仅靠源码映射（Source Link）无法补救，因为 AOT 不生成 PDB 对应的 IL 信息。
- 构建时加参数：
dotnet publish -c Release -r win-x64 --self-contained true --publish-aot --generate-debug-symbols - 验证产物：检查发布目录下是否存在
MyApp.pdb（Windows）或MyApp.dwarf（Linux/macOS） - VS Code 调试器依赖 PDB 文件定位源码行号；缺失时即使断点设上，也不会触发停顿
type 必须从 coreclr 切换为 clr
coreclr 调试器后端专为 JIT 托管环境设计，无法解析 AOT 生成的原生二进制+PDB 组合。VS Code 1.85+ 内置的 clr 类型调试器才支持 AOT 场景。
- 错误配置：
"type": "coreclr"→ 断点灰色不可用，控制台无调试器连接日志 - 正确配置：
"type": "clr"，且需确保已安装最新版 C# 扩展（v2.0+） - 额外兼容项：若使用 .NET 9+，建议同时设置
"console": "externalTerminal"，避免集成终端对原生进程 stdin/stdout 的拦截异常
Linux/macOS 下需确认调试符号格式与调试器匹配
LLDB 在不同平台对调试信息的解析能力差异大。Linux 上 AOT 默认生成 DWARF 格式，但 VS Code 的 clr 调试器可能仍尝试读取 PDB —— 导致符号加载失败。
- Linux：用
file MyApp确认是否含 DWARF；若无，添加--debug-type=portable强制生成跨平台调试符号 - macOS：注意 SIP（系统完整性保护）可能阻止调试器附加，需临时禁用或签名
MyApp（codesign --force --deep --sign - MyApp） - 通用验证法：在调试前运行
dotnet symbol --verbose MyApp.pdb确认符号可被正确读取
AOT 调试不是“开箱即用”，关键在于构建产物、调试器类型、符号格式三者严格对齐。漏掉任一环，VS Code 都只会安静地跳过断点——没有报错，也没有提示。
