localhost能访问而127.0.0.1无法访问，是因wsl中node默认绑定ipv6回环地址::，未监听ipv4的127.0.0.1；验证可通过netstat查看是否显示:::80，解决方法是显式绑定.listen(80, '127.0.0.1')或使用'0.0.0.0'。
WSL 中 Node 监听 127.0.0.1 失败，但 localhost 可用
这是 IPv4/IPv6 回环解析不一致导致的典型现象。WSL 默认启用 IPv6，而 Node 的 listen(80) 若未显式指定 host，默认绑定到 ::（IPv6 回环），此时 Windows 主机访问 127.0.0.1 会失败，但 localhost 因 DNS 解析可能命中 IPv6 地址而成功。
验证方法：在 WSL 终端运行 netstat -tuln | grep :80，若看到 :::80 而非 127.0.0.1:80，就确认是这个问题。
- 最稳妥写法是显式绑定 IPv4：
.listen(80, '127.0.0.1') - 如需同时支持 IPv4 和 IPv6，改用
.listen(80, '0.0.0.0')（注意：这会暴露给局域网，仅限开发环境） - 避免依赖
localhost字符串——它在不同系统解析顺序不同，不是可靠 host 参数
VSCode 内置终端里 node 命令找不到，但 WSL 终端里正常
根本原因不是 PATH 没配好，而是 VSCode 启动时没走 WSL 的 shell 初始化流程。从 Windows 快捷方式或开始菜单启动 VSCode，它继承的是 Windows 环境变量，完全看不到 WSL 里的 node。
必须在 WSL 终端中执行 code . 打开项目，VSCode 才会加载 ~/.bashrc 或 ~/.zshrc，从而把 nvm 或 nvs 注入的路径带进来。
使用一条命令部署ProbeChain Rydberg测试网代理节点。自动注册为Agent(NodeType=1)，免gas，支持macOS/Linux/Windows。触发词：/r
- 已打开 VSCode？先关掉所有窗口，执行
wsl --shutdown，再进项目目录运行code . - 验证是否生效：在 VSCode 内置终端里运行
which node，输出应为/home/xxx/.nvm/versions/node/...这类 WSL 路径 - 如果
which node为空，检查~/.bashrc末尾是否有. "$NVM_DIR/nvm.sh"或类似初始化语句
监听 80 端口报 “Permission denied”，又不想总用 sudo
Linux 下 1024 以下端口需要 root 权限，但直接给 node 二进制加 setuid 是高危操作——等于让所有 JS 脚本以 root 运行，极易被利用。
更安全的做法是避开特权端口，而不是降级安全模型：
- 开发阶段一律用 3000、5000、8080 等非特权端口，配合反向代理（如 nginx）或浏览器扩展模拟 Hosts 映射
- 若必须测试 80 端口，用
sudo setcap 'cap_net_bind_service=+ep' /home/xxx/.nvm/versions/node/vXX.XX.X/bin/node（仅对特定 node 二进制授权，比 setuid 安全） - Vue CLI、Create React App 等脚手架默认端口冲突时会自动 fallback 到 1024+，这不是 bug，是设计行为
调试时断点不命中，“Cannot launch program” 报错
这和代码语法无关，是 VSCode 调试器找不到可执行入口或运行时参数不匹配。常见于 ESM 项目没启用对应 flag，或 program 指向了不存在的文件。
- ESM 项目（含
import）必须在launch.json的runtimeArgs中加：["--experimental-specifier-resolution=node"] -
program字段必须指向一个真实存在的、能被node直接执行的 JS 文件，比如"${workspaceFolder}/index.js"，不能是.ts或未编译源码 - 别在
launch.json里写"runtimeExecutable": "nodemon"——调试器只认原生node，要用tasks.json配合preLaunchTask
真正容易被忽略的是：WSL 中的 Node 环境和 Windows 本地环境完全隔离，任何“看起来一样”的配置（比如全局安装的包、环境变量、端口权限）都可能因启动路径不同而失效。每次怀疑环境问题，先问自己一句：这个命令是不是真正在 WSL shell 里执行的？
