VS调试功能远超基础断点：支持条件、命中次数、函数断点；推荐用即时/监视窗口查值；关闭“仅我的代码”可查看真实异常堆栈；异步调试应关注任务窗口与并行堆栈，避免依赖线程ID。
断点不是只能打在代码行上
很多人习惯只在 if 或 for 行加断点，但 VS 的断点功能远不止于此。条件断点、命中次数断点、函数断点能跳过大量无关执行路径。
- 右键已设断点 → 选择「条件」可填入
user.Id == 123，避免在测试数据中反复手动 F5 - 「命中次数」适合排查循环末尾异常：设为「当命中次数是 99」，直接停在倒数第二次迭代后
- 函数断点（Debug → New Breakpoint → Break at Function）支持输入
System.Text.Json.JsonSerializer.Serialize，无需打开源码文件就能拦截序列化入口
快速查看变量值别只靠鼠标悬停
悬停只显示浅层字段，且无法筛选或持久化。调试时真正高效的是「即时窗口」和「监视窗口」。
-
Immediate Window（Ctrl+Alt+I）里直接输入items.Where(x => x.Status == "error").Count()，结果立刻返回，还能调用方法 - 「监视 1」窗口里添加表达式
response?.Headers?["X-Request-ID"]，即使response为 null 也不报错——VS 调试器支持空安全导航 - 对集合变量右键 → 「调试 → 快速查看」，弹出的窗口支持搜索、排序、导出为 CSV，比展开树形结构快得多
“仅我的代码”开启后反而看不到关键堆栈
默认启用的 Enable Just My Code 会折叠系统/第三方调用帧，有时导致你找不到异常真实来源。
- 遇到
NullReferenceException却只看到System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification这类模糊帧？关掉它（Tools → Options → Debugging → General → 取消勾选Enable Just My Code） - 关闭后堆栈变长，但你能看到真正触发异常的那一行第三方库代码（比如
Newtonsoft.Json.JsonConvert.DeserializeObject内部某处） - 注意：关闭后首次启动调试会稍慢，且 NuGet 包若没带 PDB，仍可能显示为
[External Code]
调试异步代码时别被线程 ID 搞晕
async/await 切换线程后，「线程窗口」里看到的 ID 经常跳变，但这不代表上下文丢失。
- 关注「任务窗口」（Debug → Windows → Tasks），它按逻辑任务分组，显示
Status、Method、Duration，比线程窗口更反映实际执行流 - 在
await行设断点，F11 进入后若跳到另一线程，检查「并行堆栈」窗口（Debug → Windows → Parallel Stacks）→ 切换到「Tasks」视图，能看到当前 await 链上所有挂起任务 - 不要依赖
Thread.CurrentThread.ManagedThreadId判断是否“还在同一线程”，.NET 6+ 默认使用ThreadPool，ID 重用极频繁；改用ExecutionContext.LogicalGetData("trace-id")做跨 await 追踪更可靠
var tcs = new TaskCompletionSource<string>();
// 在 await tcs.Task 前设置：
ExecutionContext.SetData("trace-id", Guid.NewGuid().ToString());
// 后续任意 await 后仍可通过 LogicalGetData 获取该值
调试异步时最易忽略的是：断点位置与实际调度时机的错位。比如在 await Task.Delay(1000) 后设断点，VS 可能因优化跳过该行——务必确认「调试 → 选项 → Debugging → General」中未启用 Suppress JIT optimization on module load（否则 Release 模式下断点可能失效）。 
