npm init -y 是最常用但易埋坑的初始化方式，它默认缺失 "type": "module"、有效 scripts 和规范 name 字段，需手动补全以支持 es module、调试和发布。
VSCode 能直接运行 Node.js 代码，但“高效”不取决于插件多寡，而在于初始化方式是否匹配你的实际开发节奏——用 npm init -y 快，但丢掉关键配置；手写 package.json 精，但容易漏字段；用 npx create-node-app（或类似脚手架）省事，却可能引入冗余依赖。
npm init -y 是最常用但最容易埋坑的初始化方式
它生成的 package.json 默认不含 "type": "module"、"scripts" 里只有 "test"、没设 "main" 入口，导致后续 import/export 报错、调试器找不到入口、npm start 直接失败。
- 如果项目要支持 ES Module，必须手动加
"type": "module"字段，否则import会报Cannot use import statement outside a module - 建议立刻补上常用 script：
"start": "node index.js"、"dev": "node --watch index.js"（Node 20.6+ 原生支持--watch，不用装 nodemon） -
npm init -y生成的name字段含下划线或大写字母，会导致 npm publish 失败，建议同步改成小写短横线格式（如"my-api"）
调试前必须确认 launch.json 的 program 字段指向真实入口文件
VSCode 自动创建的 .vscode/launch.json 默认用 "program": "${file}"，看起来方便，但实际极易出错：当你在 utils/helper.js 里打断点并点击「运行」，调试器就试图把 helper.js 当作主程序执行——没有 require 或 import 链，自然报 Cannot launch program because corresponding JavaScript cannot be found。
使用一条命令部署ProbeChain Rydberg测试网代理节点。自动注册为Agent(NodeType=1)，免gas，支持macOS/Linux/Windows。触发词：/r
- 生产级做法是固定入口：
"program": "${workspaceFolder}/index.js"或"program": "${workspaceFolder}/src/index.js" - 如果项目用 TypeScript，别直接调试
.ts文件，确保launch.json中"preLaunchTask": "tsc: build"已配好，且"outFiles"指向编译后目录（如["${workspaceFolder}/dist/**/*.js"]） - Windows 用户注意路径分隔符：VSCode 内部统一用
/，哪怕你本地是，硬写\反而触发转义错误
code-runner 插件跑 Node 脚本时，默认不加载 .env 和 ignore node_modules
它本质是调用 node xxx.js，但没走 npm script 流程，所以 process.env 里没有 .env 变量，也读不到 package.json 里定义的 exports 或 exports["."] 映射，更不会按 node_modules/.bin 查找本地 bin。
- 想让 code-runner 加载环境变量，得改
code-runner.executorMap中的javascript项为：node -r dotenv/config $fileName dotenv_config_path=$workspaceRoot/.env - 若脚本依赖本地安装的 CLI 工具（如
prisma），别用 code-runner —— 改用终端执行npx prisma migrate dev，或在package.json里定义 script 后用 VSCode 的「运行脚本」功能 - 它默认输出编码是系统 locale，Windows 中文环境下易乱码，加
-r utf-8参数仅对 Node 19+ 有效；Node 18 及更早版本需改系统区域设置或换用终端
真正卡住人的从来不是“怎么配”，而是“配完以为好了，结果某天某个场景突然崩”。比如你用了 --watch，却忘了它不监听 node_modules 里的变化；比如你写了 exports 字段，却用 code-runner 直接跑子模块——这些细节不在文档首页，但每天都在真实发生。
