VSCode调试控制台可访问调用栈中任意层作用域的变量（含外层函数、模块级变量、闭包捕获值、this属性），但不支持未初始化var变量、已回收对象及TS private成员；[unavailable]多因V8优化所致。
调试控制台能访问哪些作用域的变量
VSCode调试控制台在断点暂停时，表达式求值的作用域不是当前函数体那么简单——它基于整个调用栈（Call Stack）构建一个“可访问变量集合”。只要变量出现在当前调用栈任意一层的作用域中（包括闭包、外层函数、模块顶层），且未被编译器优化掉，就能直接读取或修改。
常见误区是以为只能访问console.log所在行声明的变量。实际上，比如你在嵌套的handleClick里打断点，却能直接输入config.apiTimeout——只要config是在上层函数或模块作用域定义的，且没被Tree-shaking或const死绑定封锁。
- 支持：外层函数变量、模块级
const/let、闭包捕获的参数、this上下文属性 - 不支持：被
var声明但未初始化的变量（会报ReferenceError）、已被垃圾回收的临时对象、TS中private成员（除非在类方法内断点） - 注意：
[unavailable]提示通常意味着V8引擎做了优化（如函数内联），可在tsconfig.json中加"compilerOptions": {"disableOptimization": true}临时缓解
为什么user.name能读到，但tempData报错
报错本质是作用域链断裂，不是语法问题。典型场景有三类：
- 变量声明在
if/for块级作用域内，而断点在块外：比如if (loading) { const tempData = fetch(); }，断点设在if之后，tempData就不可见 - 变量名被遮蔽（shadowing）：外层有
const data = 1，内层又const data = 2，控制台输入data只会返回内层值，想访问外层得用debugger面板里的Scopes逐层展开确认 - 异步回调中变量未提升：箭头函数里用
let声明的变量，在setTimeout回调断点处可能显示[unavailable]，此时改用var或提前声明到外层更可靠
console.log和直接输入表达式的区别
两者执行环境相同，但行为逻辑不同：
- 直接输入
items.filter(i => i.active)：返回过滤后数组，结果直接显示在控制台，可点击展开查看每个元素 - 输入
console.log(items.filter(i => i.active))：输出结果到“调试控制台”下方的普通日志区，同时返回undefined（因为console.log本身无返回值） - 关键差异：
console.log能处理循环引用、Map/Set等复杂结构，而裸表达式对Map.keys()这类迭代器返回MapIterator对象，需手动转数组：[...myMap.keys()]
跨作用域求值时最容易忽略的坑
真正卡住人的往往不是技术限制，而是调试状态本身的隐蔽性：
- 断点位置决定作用域起点：在
async函数里打断点，await之后的代码实际运行在微任务队列，此时this或arguments可能已丢失，优先查Scopes面板里的Closure而非Local - TS类型擦除不影响运行时访问：即使
interface User { name: string }没生成JS，你仍能访问user.name——控制台操作的是JS运行时对象，不是TS类型系统 - 修改变量后必须单步或继续执行才能生效：比如改了
isMounted = false，但UI没重绘？因为React的setState批处理还没触发，需要按F10走完当前帧
跨作用域求值本身不难，难的是时刻意识到“当前断点在哪一层、变量从哪来、修改后何时可见”。每次不确定时，先看Call Stack面板，再点开Scopes里的每一项展开确认——比猜快得多。
