VSCode调试器默认截断字符串显示为"xxx..."，因调试上下文中的util.inspect()硬性限制maxStringLength（通常128～256字符），需在入口文件顶部设置util.inspect.defaultOptions.maxStringLength = null或足够大的数值来完整显示。
为什么调试器里字符串总被显示成 "xxx..."？
VSCode 调试器（Debug Console / Variables 面板）默认对字符串做长度截断，不是终端或日志问题，而是 util.inspect() 在调试上下文中的硬性限制。Node.js 本身通过 maxStringLength 控制单个字符串最大显示字符数，默认值是 10000，但 VSCode 的调试器会进一步收紧——实测通常在 128～256 字符就加省略号，尤其在 Watch 或 Variables 面板中更明显。
如何让调试器完整显示长字符串？
必须改 util.inspect.defaultOptions.maxStringLength，且需在调试会话启动前生效。仅靠 console.log() 设置无效，因为调试器用的是独立的 inspect 上下文。
Zenlink - Node SDK for ZenHeart
下载
ZenHeart zenlink 与 zenlink-mcp 为 OpenClaw，涵盖安装、MCP 注册、钩子接线、入站轮询及升级维护。
- 在入口文件（如
index.js）顶部加：
const util = require('util');
util.inspect.defaultOptions.maxStringLength = null; // 或设为足够大的数，如 100000
- 如果用
launch.json启动，确保该代码在program指向的文件最开头执行； - 若用
Attach模式，需提前在目标进程里运行这段代码（例如通过node --require ./inspect-setup.js app.js）； - 不推荐全局修改
util.inspect.defaultOptions其他字段（如depth），可能干扰对象展开逻辑。
Watch 面板里字符串还是被截？检查表达式写法
Watch 表达式里直接写 someLongString 仍可能被截，因为 Watch 也走同一套 inspect 逻辑。绕过方式是显式调用 toString() 或强制转为无截断格式：
-
someLongString + ''—— 触发隐式转换，有时能避开早期截断； -
someLongString.substring(0, 5000)—— 主动控制长度，避免无限长拖慢 UI； -
Buffer.from(someLongString).toString('hex')—— 若需十六进制校验，比原字符串更紧凑； - 避免在 Watch 中写
JSON.stringify(obj)处理深层嵌套对象，它本身也有递归深度限制，且可能触发额外截断。
内存和性能代价不能忽略
设 maxStringLength = null 后，调试器会尝试渲染完整字符串——这对几 MB 的日志片段或 base64 内容是灾难性的：UI 卡死、VSCode 响应变慢、甚至触发 Electron 渲染进程 OOM。
- 日常调试建议设为
50000而非null，平衡可读性与稳定性； - 真正需要看超长内容时，别依赖 Watch 面板，改用
Debug Console执行fs.writeFileSync('debug.txt', someLongString)导出到文件； - ESM 项目要注意：若入口是
.mjs或含"type": "module"，require('util')会报错，得改用动态import('util')并 await； - 这个限制只影响调试器显示，不影响实际变量值或程序行为——字符串本身没被删减，只是“不给你全画出来”。
