并行监视窗口需在调试暂停时按Ctrl+Alt+Shift+P或通过「调试→窗口→并行监视」打开，支持四列独立表达式求值，按线程或任务分组显示，仅限调试态使用。
并行监视窗口在哪打开
并行监视窗口不是默认开启的调试工具，必须在调试过程中手动调出。它只在断点命中、程序暂停时可用，运行中或设计态无法访问。
- 调试状态下按
Ctrl+Alt+Shift+P快捷键（注意是 Shift+P，不是 D） - 或通过菜单栏：「调试」→「窗口」→「并行监视」→ 选择「并行监视 1」到「并行监视 4」中的任意一个
- 首次打开后，窗口会停靠在 IDE 底部或侧边，可拖拽调整位置；关闭后下次仍会记住布局
怎么添加变量或表达式到并行监视
并行监视窗口本质是多列显示的“动态表达式求值器”，每列独立刷新，适合对比多个线程/任务的数据状态。
- 在任一列的空白行双击，输入变量名（如
list）、属性（如task.Status）、LINQ 表达式（如items.Where(x => x > 5)） - 支持跨线程访问：即使某个变量只在特定线程中声明（如
localValue），只要当前行处于该线程上下文，就能正确求值 - 不能直接写语句（如
Console.WriteLine(...)），只接受返回值的表达式 - 若表达式求值失败，对应单元格显示
为什么某些变量在并行监视里显示为
这不是界面 bug，而是 CLR 调试器对变量生命周期和 JIT 优化的真实反馈。
- Release 模式下未禁用优化（
Optimize code勾选）会导致局部变量被内联或提前释放，调试时不可见 - 变量超出作用域：比如在
for循环块内声明的i，循环结束后该符号在调试信息中不再有效 - 异步方法中，
await后续代码可能运行在不同线程/上下文，原始栈帧已销毁，原局部变量无法追溯 - 解决办法：调试时用 Debug 配置；必要时在关键位置插入
System.Diagnostics.Debugger.Log(0, "", "here");防止优化；或改用Debug.Assert()强制保留上下文
并行监视和普通监视窗口的区别
两者底层都调用同一套表达式求值引擎，但行为逻辑完全不同。
- 普通监视窗口（Watch）是单列、线程绑定的：你加的每个表达式都在当前活动线程上下文中求值，切换线程后需手动刷新
- 并行监视默认按线程分列：每列顶部显示线程 ID（如
[Thread 1234]），自动跟踪各线程当前堆栈，无需手动切换上下文 - 并行监视支持“任务视图”：右键列标题 → 「切换到任务视图」，可按
Task实例分组，比纯线程视角更贴合 async/await 场景 - 性能影响轻微：每列独立轮询，但仅在调试暂停时触发，不影响运行时性能
class Program
{
static async Task Main(string[] args)
{
var t1 = Task.Run(() => { Thread.Sleep(100); return 42; });
var t2 = Task.Run(() => { Thread.Sleep(150); return "done"; });
// 在这行设断点，然后打开并行监视，分别添加：
// 列1: t1.Status
// 列2: t2.Result ← 注意：这里会阻塞当前线程，慎用！
// 列3: Thread.CurrentThread.ManagedThreadId
await Task.WhenAll(t1, t2);
}
}
实际调试中，t2.Result 这类会触发阻塞的操作，在并行监视里可能卡住当前列刷新，甚至导致 UI 假死——这是最容易忽略的副作用。
