logpoint 需调试会话启动才生效，依赖正确 sourcemap、调试配置及作用域变量存在；仅支持安全表达式求值，不执行声明或函数调用；适用于非中断日志输出，与条件断点协同提升调试效率。
Logpoint 怎么加才真正生效
Logpoint 不是加了就立刻输出日志，它依赖调试器已启动且能正确映射源码。如果你点了橙色菱形却没看到任何输出，大概率不是 Logpoint 失效，而是根本没进调试会话。
- 必须先按
Ctrl+Shift+D打开「Run and Debug」侧边栏，再点击绿色三角形「Start Debugging」——直接运行脚本（比如按Ctrl+F5）不会触发 Logpoint - Node.js 项目要确认
launch.json中type是"node"，且program指向真实入口文件（如"${workspaceFolder}/src/index.ts"），否则断点图标会变为空心圆（unverified breakpoint） - TypeScript 项目务必开启 sourceMap：
tsconfig.json里有"sourceMap": true，launch.json中也要配"sourceMaps": true - 前端项目用 Chrome 调试时，得先装「Debugger for Chrome」或新版「Microsoft Edge Tools」插件，并确保页面是通过调试器启动的，而不是手动打开
localhost:3000
Logpoint 里写变量为什么报错或显示 undefined
Logpoint 的花括号插值（如 {user.id}）不是模板字符串，而是由调试器在当前作用域实时求值的 JavaScript 表达式。它不支持解构、声明、函数调用，也不能访问被优化掉的局部变量。
- 别写
{const name = user?.name || 'guest'; name}—— 声明语句非法，VS Code 会提示Invalid expression - 别写
{getUserInfo()}—— 函数调用可能有副作用，调试器会禁止执行 - 循环中访问
{arr[i]}要确保i和arr当前确实存在且未被闭包/优化移除；若变量名含点号或特殊字符，用方括号访问更稳，比如{user['full-name']} - 空值安全推荐用逻辑运算符：
{user && user.profile && user.profile.avatar}或可选链{user?.profile?.avatar}（Node.js ≥14 / Chrome ≥89 支持）
Logpoint 和 console.log 到底差在哪
表面都是打日志，但 Logpoint 是调试器注入的运行时探针，和代码本身零耦合；而 console.log 是运行时语句，改了就得提交、可能被误留、影响格式、破坏纯函数逻辑。
- Logpoint 输出默认带文件名 + 行号（如
index.ts:42），无需手动拼接，也不怕忘记删 - 表达式求值发生在调试器上下文，能访问闭包内变量，但不能修改它们（比如
{i++}会报错） - 输出目标固定为「Debug Console」，不会污染浏览器控制台或终端 stdout，适合多环境共存调试
- 右键 Logpoint 可快速禁用（
Disable Breakpoint），比注释掉console.log更干净，也避免 git diff 里出现调试痕迹
什么时候该用 Logpoint，什么时候该换条件断点
Logpoint 适合“看”，条件断点适合“停”。混用才是常态，但顺序错了反而拖慢节奏。
- 高频循环里别用条件断点查
i === 999——等它停下来你已经失去上下文；换成 Logpoint：第 {i} 次：{data[i]?.status}，一眼扫出异常模式 - 想确认某个 API 是否被调用，但又不想中断响应流程？Logpoint 输出
POST /api/user: {JSON.stringify(params)}，比埋console.log安全得多 - Logpoint 发现某次调用参数异常（如
id: null），立刻在同一行右键 →Edit Breakpoint→ 改成条件断点：id === null，直接停住看堆栈 - 注意：同一行可以同时存在普通断点（红实心圆）和 Logpoint（橙菱形），图标不同，互不干扰
最常被忽略的一点：Logpoint 的表达式求值性能开销虽小，但在每毫秒执行数百次的动画帧或 WebSocket 心跳里，密集使用仍可能拖慢调试器响应。真遇到卡顿，优先关掉非关键 Logpoint，而不是怀疑代码本身。
