Node.js读取GBK文件显示\u4f60\u597d是因为默认按UTF-8解码，正确做法是显式指定encoding为'gbk'，如fs.readFileSync('file.txt', 'gbk')或fs.readFile('file.txt', {encoding: 'gbk'})。
Node读取GBK文件时中文变\u4f60\u597d怎么办
Node.js 默认按 UTF-8 解码文件，遇到磁盘上实际是 GBK 编码的 fs.readFile 或 require 的文件（比如旧版 Windows 记事本保存的 .json、.txt），就会把每个中文解析成两个错误字节，最终显示为 \u4f60\u597d 或直接报错 Invalid UTF-8 sequence。这不是 VSCode 显示问题，是 Node 运行时真实读错了。
- 先确认文件真实编码：在 VSCode 右下角点编码 →
Reopen with Encoding→ 试GBK，能正常显示就坐实了 - 不要改
fs.readFile路径或加 BOM——BOM 会触发 Node 报Unexpected token \ufeff - 正确做法是显式指定编码：
fs.readFileSync('data.txt', 'gbk')（注意是字符串'gbk'，不是'GBK'或'cp936'） - 如果用
fs.readFile回调或 Promise 版本，同样传{ encoding: 'gbk' }，不能只写'gbk' -
require('./config.json')这类静态引入无法指定编码，必须提前转存为 UTF-8（VSCode 点右下角 →Save with Encoding→UTF-8）
require() 加载含中文路径的模块失败
Windows 下 Node require() 对非 ASCII 路径支持极差，尤其当项目路径含中文且文件系统是 GBK 时，require('子目录/配置.js') 直接抛 Error: Cannot find module。这不是编码设置问题，是 Node 底层 API 在 Windows 上对宽字符路径处理不一致导致的。
OC SSH Tunnel Node Recovery
下载
诊断并恢复通过 SSH 隧道连接的 OpenClaw 节点。用于解决配对必需错误、隧道冲突、远程端点错误以及 SSH 目标配置错误等问题。
- VSCode 设置
"files.encoding": "utf8"完全无效——路径字符串本身没被解码，是系统 API 拒绝识别 - 临时解法：把项目移到纯英文路径，比如
C:\project\，这是最稳的 - 长期方案：升级到 Node.js 18.17+ 或 20.9+，它们对 Windows 中文路径的支持有实质性修复
- 若必须用旧 Node，可用
path.resolve(__dirname, '子目录/配置.js')+fs.readFileSync(..., 'utf8')+vm.compileFunction动态执行，但绕过require会丢失 sourcemap 和缓存机制
子进程 exec/execFile 输出中文乱码
用 child_process.exec('node script.js') 或 execFile 调外部脚本时，即使脚本本身是 UTF-8，输出到 Node 主进程仍是乱码，表现为 stdout 里中文变成 或空格。这是因为子进程继承了父进程的 stdio 编码，默认不是 UTF-8。
- 必须显式设
encoding选项：exec(cmd, { encoding: 'utf8' })—— 这个encoding控制的是 Node 如何解码子进程 stdout 的字节流 - 如果子进程本身输出的是 GBK（比如调了个
xxx.exe），那得写{ encoding: 'gbk' }，否则照样崩 -
spawn更底层，stdout.setEncoding('gbk')也得配对，不能只靠 options.encoding - 注意：这个
encoding和fs的encoding含义一致，都是告诉 Node “这堆字节该按什么规则转成字符串”，不是“让子进程改输出编码”
为什么 process.env.NODE_OPTIONS=--experimental-strip-types 不解决乱码
有人误以为加 NODE_OPTIONS 就能全局统一编码，比如设 --no-warnings --max-old-space-size=4096 之外再加 --experimental-strip-types，结果发现对乱码毫无作用。因为 Node 的文件 I/O 编码策略是 per-call 的，不走全局开关。
-
process.env.NODE_OPTIONS只影响 V8 引擎启动参数，不干预fs、child_process等模块的默认编码行为 - 没有
--default-encoding=utf8这种 flag，官方明确拒绝添加（见 Node.js issue #32902） - 真正影响
fs默认行为的只有传参：不传encoding就是utf8，传了就用你给的；不存在“全局 fallback 编码” - 想一劳永逸？只能封装一层工具函数，比如
readGBK(path)内部固定调fs.readFileSync(path, 'gbk')，别指望 runtime 自动猜
fs 模块从不自动探测文件编码，它只认你传的 encoding 字符串或默认 utf8。VSCode 里看着正常的文件，只要没被 Save with Encoding → UTF-8 真正覆写，Node 运行时就永远读不对。 
