结论是：fs.readFile('./xxx') 报 ENOENT 并非文件不存在，而是路径基于 process.cwd() 而非脚本位置；应使用 path.join(__dirname, 'xxx') 构造绝对路径，确保跨平台兼容且不受启动目录影响。
直接说结论： 能读写，但fs.readFile('./xxx')这类相对路径大概率会报 Error: ENOENT: no such file or directory —— 不是 Node 或 VSCode 坏了，而是路径解析逻辑和你想象的不一样。
为什么 ./config.json 总是找不到？
Node.js 里所有以 ./、../ 开头的路径，都基于 process.cwd()（当前工作目录），不是你 JS 文件所在位置。VSCode 终端默认打开在工作区根目录，而你的脚本可能在 src/ 下，这时 ./config.json 就去根目录找，不是 src/config.json。
- 你在终端里执行
cd src && node app.js成功，换到上层目录再跑就失败，就是这个原因 - 右键文件 → “在集成终端中打开”，VSCode 启动终端的位置取决于你点的是文件、文件夹还是空白处，
process.cwd()会变 - 加这两行调试能立刻看清差异：
console.log('cwd:', process.cwd()); console.log('__dirname:', __dirname);
正确构造文件路径的唯一可靠方式
用 path.join(__dirname, 'data.json')，而不是拼字符串或硬写 ./。
Rydberg Agent Node
下载
使用一条命令部署ProbeChain Rydberg测试网代理节点。自动注册为Agent(NodeType=1)，免gas，支持macOS/Linux/Windows。触发词：/r
-
__dirname永远指向当前 JS 文件所在的绝对目录，不受启动位置影响 -
path.join()自动处理/和\，规范化路径（比如去掉多余斜杠、处理..） - 别写
__dirname + '/data.txt'—— Windows 下会出错；也别用path.resolve('./data.txt')，它还是基于process.cwd() - 读子目录文件：写成
path.join(__dirname, 'assets', 'logo.png')，中间不用管分隔符
常见 fs 操作写法与坑点
fs.readFile、fs.writeFile 等异步方法，错误永远是回调第一个参数，且必须判断：
-
fs.readFile(path, 'utf8', (err, data) => { if (err) throw err; /* 正常逻辑 */ })—— 忘判err，程序崩得无声无息 - 写文件时路径不存在（比如
logs/error.log，但logs/目录还没建），fs.writeFile会直接报错，得先用fs.mkdirSync(path.dirname(logPath), { recursive: true }) - 追加内容用
fs.appendFile，不是fs.writeFile；后者会覆盖，前者才真正“追加” - 同步方法如
fs.readFileSync适合配置文件等小文件，大文件阻塞主线程，别在服务响应中用
VSCode 终端里 node 命令都找不到？先看环境
这不是文件路径问题，是 shell 环境没加载 Node 路径 —— 特别是用了 nvm 的 macOS/Linux 用户，或者 PowerShell 受策略限制的 Windows 用户。
- macOS/Linux：检查
~/.zshrc是否有 nvm 初始化代码；VSCode 终端默认是非登录 Shell，不读配置文件；改设置terminal.integrated.profiles.zsh.args加["-l"]，然后**完全重启 VSCode** - Windows：PowerShell 默认禁止执行本地脚本，运行
Set-ExecutionPolicy RemoteSigned -Scope CurrentUser临时放开；更稳做法是把默认终端换成 Command Prompt - 改完配置只关终端不管用，必须退出整个 VSCode 进程，否则环境变量不会重载
路径问题的本质不是“怎么写对”，而是“谁来决定起点”。只要记住 ./ 属于终端，__dirname 才属于文件本身，大部分 ENOENT 就能当场定位。真正容易被忽略的，是跨平台路径拼接和 shell 环境初始化这两个环节 —— 它们不出错时你感觉不到，一出错就全链路瘫痪。
