Bookmarks插件不能替代断点，但能补位断点失效场景：如断点误删、调试中断、WASM等不支持断点环境、源码重构导致断点失效；需配合标签、上下文备注及持久化设置提升实用性。
Bookmarks插件不能替代断点，但能补位断点失效场景
VSCode 的 Bookmarks 插件本身不介入调试流程，也不读取或控制断点状态。它只记录“某行有标记”，和 debugger 语句、断点开关、条件断点完全无关。真正需要断点逻辑（比如条件触发、变量求值、暂停执行）时，必须用原生调试功能。但 Bookmarks 在这些情况下能救急：
• 断点被误删或未命中（比如异步回调里加不了断点）
• 调试会话中断后想快速回到上次关注的几行代码
• 某些语言/运行时（如 WASM、某些 CLI 工具链）不支持断点，只能靠人工锚定位置
• 日志里看到某行出问题，但源码已重构，原断点失效，而书签仍可手动跳转到大致区域
如何用 Bookmarks 标记「疑似断点位置」并带上下文
单纯按 Ctrl+Alt+K 加个蓝色图标意义有限。要让书签在调试中真正有用，得立刻附加可检索的上下文：
• 执行 Bookmarks: Toggle Labeled（不是普通 toggle），输入类似 [BREAK] auth timeout handler 或 [LOG] fetch retry logic
• 避免用模糊描述如“这里有问题”，优先包含关键词：函数名、模块名、错误码、HTTP 状态码等
• 如果该行附近有关键变量，可在备注里写 [BREAK] userStore.init() — check tokenExpiry
• 备注会被收录进 Bookmarks: List 的搜索索引，输 tokenExpiry 就能直接过滤出来
跨文件跳转时书签丢失或错位的三个硬限制
书签不是“智能锚点”，它只存文件路径 + 行号，没有任何 AST 或语义感知能力：
• 删除或移动整行 → 书签消失（不是变灰，是彻底移除）
• 文件重排（比如格式化、自动 import 排序）→ 行号偏移，书签指向空行或注释，而非原逻辑位置
• 多根工作区下，每个子文件夹独立存储书签；若你从根目录打开项目，但实际在子包里打书签，切换到另一子包再查列表，可能看不到之前标的项
• 补救办法只有启用持久化：在当前工作区的 .vscode/settings.json 中加一行 "bookmarks.persistAll": true，否则关 VSCode 就丢
和断点日志配合使用的最小可行流
当你要追踪某段逻辑的执行路径又不想打断运行时，Bookmarks 可作为断点日志的“视觉索引”：
• 先在目标行设书签并加备注，例如 [LOG] apiClient.post() — log response time
• 然后右键该行行号 → “添加断点” → “编辑断点” → 输入 console.log('⏱️', new Date().toISOString(), 'response time:', response.time)
• 调试跑起来后，日志刷屏，你只需在控制台 Ctrl+F 搜 ⏱️，找到对应日志，再按 Ctrl+Alt+L 呼出书签列表，搜 apiClient.post 就能秒回源码位置
• 注意：不要依赖书签自动高亮日志行——它做不到；它的价值是把日志里的抽象时间戳，映射回具体代码行
