Logpoint 是调试器在断点位置只打印不暂停的轻量日志指令，本质由调试协议注入，不执行JS运行时逻辑；而 console.log 是运行时语句，会执行表达式、产生副作用且影响性能。
Logpoint 是什么，和 console.log 有什么本质区别
Logpoint 是调试器在断点位置“只打印、不暂停”的能力，本质是调试器注入的轻量日志指令，不是 JavaScript 运行时执行的 console.log。它不修改源码、不污染构建产物、不触发重载，也不会因忘记删除而上线。
-
console.log是运行时行为：会执行表达式、可能有副作用（比如调用getData()）、影响性能，且必须手动增删 - Logpoint 是调试器行为：仅在 VSCode 的 Debug Adapter 层解析并输出，表达式在调试上下文中求值，但程序线程不中断、不跳栈、不卡帧
- 它依赖调试协议支持（Node.js 用
node --inspect，Chrome DevTools 协议兼容），不是所有 runtime 都默认开启
VSCode 中设置 Logpoint 的三种可靠方式
VSCode 的 Logpoint 不是靠右键菜单“Add Logpoint”就一定能生效——它背后依赖调试配置和底层协议是否启用日志断点能力。
- 在代码行号左侧灰色区域右键 → Add Log Point，输入表达式（如
user.id, user.name），回车确认；这是最常用路径，但前提是当前调试会话已启动且支持 Logpoint - 如果右键没出现该选项，检查
.vscode/launch.json中的configurations是否含"console": "integratedTerminal"或"trace": true——这些不是必须，但缺失"skipFiles": []可能导致 Logpoint 被跳过 - 终极兜底：直接在行号左侧单击，出现红点后按 Alt + Click（Windows/Linux）或 Option + Click（macOS），红点变橙色即为 Logpoint；这是快捷键触发，绕过 UI 权限判断，成功率最高
Logpoint 表达式里哪些写法会出问题
Logpoint 看似能写任意 JS 表达式，但实际受限于调试器对作用域、异步、this 绑定的解析能力，不是所有 console.log 替代写法都安全。
- ✅ 支持：简单变量
count、对象属性res.data.length、模板字符串插值<code>status: ${status} - ❌ 不支持：
await fetch('/api')（调试器不执行异步）、this.method()（this上下文常为空或指向 global）、process.env.NODE_ENV（环境变量不在调试作用域内） - ⚠️ 危险但不易察觉：
arr.push(item)—— 表达式会被求值，这会真实修改数组，Logpoint 不是只读快照 - 调试器对解构支持弱，
{ name } = user会报错；改用user.name更稳妥
为什么有时 Logpoint 没输出，或输出 undefined
这不是你写错了，大概率是调试器没拿到当前作用域，或者代码被优化掉了。
- 常见原因：源码开启了
sourceMap但映射不准，Logpoint 打在了 transpiled 后的代码行上，而调试器找不到原始变量名；验证方法：停在一个普通断点，看调试面板 Variables 里能否展开user - Node.js 场景下，如果用了
ts-node或esbuild-node，需确认启动命令带--enable-source-maps，否则 Logpoint 无法关联变量 - Chrome 调试前端时，若用了
webpack的devtool: 'eval'，Logpoint 基本失效——换'source-map'或'inline-source-map' - 输出
undefined很可能是变量名拼错，或该行执行时变量尚未声明（比如let x = 1下一行打 Logpoint 查x，但还没执行到赋值）；此时不如把 Logpoint 往下移一行
Logpoint 的边界不在功能多强，而在“它不接管执行权”——只要涉及副作用、异步、动态作用域，就得退回到 console.log 或真断点。别指望它替代所有日志场景，但对快速验证中间状态，它确实少一次保存、少一次重启、少一个遗漏的 console。
