监视面板仅显示断点暂停时的当前值，不记录赋值过程；需通过断点单步执行配合监视表达式（如locals()、vars(obj)）实时观察变量变化，并注意条件断点与监视结果不同步的问题。
监视面板本身不记录赋值过程，只显示当前值
VSCode 的 监视 面板不是变量“历史记录器”，它不会自动捕获某变量在哪一行被赋值、值如何逐步变化。它只在每次断点暂停时，对输入的表达式做一次求值并显示结果。如果你看到 total 从 0 变成 2 再变成 8，那是因为你在不同断点位置手动刷新了执行，而不是监视面板“记住”了过程。
想看清赋值过程，必须配合断点单步执行
真正能还原赋值链条的方式，是把断点打在变量被修改的关键行，并逐行推进：
- 在
total += item * 2这类语句前、中、后各设一个断点（实际只需在该行设断点，再用F10单步跳过或F11单步进入） - 在“监视”面板里提前添加
total和item，每次暂停时值会自动更新 - 注意：如果变量在循环内被反复赋值，但你只在循环外设了一个断点，就只能看到最后一次结果——必须让程序停在每次赋值发生的时刻
嵌套/动态赋值场景下，locals() 比单个变量更可靠
当函数参数名被混淆（如 _0x4a2f）或变量通过 setattr、字典键写入等方式动态生成时，靠名字硬加进监视面板可能失效。这时可直接监视作用域快照：
- 在函数入口断点处，往监视面板加
locals()—— 它会以字典形式展开所有当前局部变量 - 若需看某个字段是否被写入，可用
'target_key' in locals()或locals().get('target_key') - 对对象属性不确定时，别只输
obj.name，改用vars(obj)或obj.__dict__，避免被 property 方法遮蔽真实状态
容易忽略的陷阱：条件断点 + 监视表达式不同步
你设了个条件断点 count > 5，又在监视面板里加了 count，但发现 count 显示的是 3——这不是 bug，而是因为条件断点只在满足时暂停，而监视表达式是在暂停那一刻才求值。也就是说：
- 条件断点触发时，
count必然 > 5；你看到的 3 是上一次暂停（比如刚进函数时）留下的缓存值 - VSCode 不会自动清空监视列表的历史结果，得手动删掉重加，或重启调试会话
- 更稳妥的做法：在条件断点所在行，右键 → “编辑断点” → 勾选“仅在满足条件时打印消息”，然后配合调试控制台里敲
count实时验证
调试器不保存中间态，它只给你一个“快照”。要拼出完整赋值过程，得靠你控制暂停节奏，而不是指望工具自动回放。
