watch面板中直接写mymap会卡死，因其触发v8内部api全量遍历map；应改用mymap.size、array.from(mymap.entries()).slice(0,3)等可控方式，禁用json.stringify(mymap)；修改需在debug console执行，watch仅支持只读表达式求值。
Watch 面板里直接写 myMap 会卡死，别这么干
VSCode 默认对 Map 和 Set 执行完整展开：不仅遍历所有键值对，还会尝试读取内部迭代器状态、哈希桶结构甚至未使用的内存槽位。一旦条目数超过 500，UI 线程就可能阻塞 2 秒以上，面板变灰或点击 ▶️ 无响应就是典型信号。
根本原因不是“Map 太大”，而是调试器在每次断点暂停时都试图生成一个可序列化的快照——而原生 Map 没有标准的 toJSON，它靠 V8 内部 API 逐项提取，开销是线性的，但嵌套后会指数放大。
- 用
myMap.size替代myMap，这是最轻量、最稳定的监控方式 - 需要看部分数据？写
Array.from(myMap.entries()).slice(0, 3)，明确控制展开范围 - 绝对不要写
JSON.stringify(myMap)——它会触发Map.prototype.toJSON，结果仍是全量遍历
想监听 Map 内部变化，得靠 onChange 这类库，Watch 面板做不到
Watch 面板本质是“只读快照求值”，它不会订阅 Map.set() 或 Set.add() 的调用，只在断点暂停那一刻取一次值。你改了 myMap 十次，只要没停在断点，Watch 就不会刷新，更不会告诉你哪次改了什么。
真要捕获运行时变更，必须用运行时代理：
- 安装
on-change：npm install on-change - 包装你的 Map：
const watchedMap = onChange(new Map(), (path, value, prev) => console.log(path, 'changed')) - 之后所有
watchedMap.set()、watchedMap.delete()都会触发回调
注意：onChange 对 Map 和 Set 有专用克隆逻辑（比如 CloneMap 类），能识别其迭代协议，普通 Proxy + Reflect 实现无法覆盖这些行为。
Python 场景下监视 dict 和 set 要换思路
Python 扩展（如官方 Python 扩展）对 dict 和 set 的处理比 JS 更激进：默认直接展开全部内容，且不提供 size 这类快捷属性访问入口。你写 my_dict，它就真去调 list(my_dict.items())。
安全做法是绕过自动展开：
- 用
len(my_dict)或len(my_set)替代原始变量名 - 查键存在性写
my_dict.get('key', 'default')，避免KeyError导致整个 Watch 项失效 - 若需看前几项，用
list(my_dict.items())[:2]，别用my_dict.items()——后者返回的是不可序列化迭代器，Watch 会显示dict_items object且无法展开
另外，确保 launch.json 启用了 "variablePresentation": "simple"，否则即使你写了 len(...)，调试器仍可能对嵌套结构做递归展开。
Watch 和 Debug Console 的分工必须分清
很多人试图在 Watch 里写 myMap.set('x', 1) 来“一边监视一边修改”，这完全无效——Watch 是只读表达式求值，赋值语句被忽略，也不会报错，只会一直显示 undefined。
正确姿势：
- Watch 里只放查询类表达式：
myMap.size、mySet.has('test')、Array.from(myMap.keys()) - 要修改？切到 Debug Console，输入
myMap.set('x', 1)回车，然后刷新 Variables 面板看效果 - 要验证修改是否生效？再在 Watch 里加一条
myMap.get('x')，它会在下次断点时自动更新
最容易被忽略的一点：Watch 表达式永远绑定当前断点所在的栈帧。你在函数 A 里设断点，Watch 中写的 myMap 必须是 A 的局部变量或闭包中可访问的；如果它是在函数 B 里创建的，又没被返回或挂到全局，Watch 就只能显示 Cannot evaluate。
