VSCode无内置Node.js沙箱，文件访问权限取决于系统级约束；需通过cwd、UID/GID、OS权限或外部工具（如sandbox-exec、firejail）实现隔离，且无法完全阻止子进程绕过JS层检查。
VSCode 本身不提供 Node.js 沙箱或文件读写隔离机制，所谓“安全环境”必须靠系统级约束或运行时参数手动实现，不是开个设置就能启用的功能。
Node.js 默认没有沙箱，fs 模块能访问整个文件系统
只要脚本里写了 require('fs') 或用了 readFileSync，它就能读写你当前用户有权限的任意路径——包括家目录、项目外的配置文件、甚至 /etc/hosts（Linux/macOS 下若用户权限够高）。这不是 VSCode 的漏洞，是 Node.js 运行时的设计事实。
- VSCode 的集成终端、
code-runner、调试器（vscode-js-debug）都直接调用系统node可执行文件，不加任何默认隔离 - 没有“沙箱模式”开关；
node --no-warnings或--trace-warnings这类参数也不限制文件操作 - 真正起作用的只有：进程启动时的
cwd（工作目录）、用户 UID/GID、以及操作系统级权限（如 macOS 的 Full Disk Access、Windows 的 UAC）
用 node --experimental-repl-await 不解决安全问题，但可辅助限制范围
有人误以为开启实验性 REPL 参数能带来隔离，其实它只影响交互式命令执行方式，和文件系统访问控制完全无关。真正能缩小风险面的操作是：
dmap-jsapi-skill
下载
DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
- 在终端中先
cd到一个干净子目录（如./sandbox），再运行code .启动 VSCode —— 这样所有相对路径操作默认锚定在此目录内 - 调试时在
launch.json中显式指定"cwd": "${workspaceFolder}/sandbox"，强制 Node.js 进程从该路径启动 - 避免使用绝对路径字符串拼接（如
path.join('/home/user/', userInput)），改用path.resolve(cwd, userInput)并校验结果是否仍在预期根目录下
需要真隔离？只能靠外部工具链
如果你的场景确实要求禁止跨目录读写（比如跑不可信代码、教学演示、CI 中预览脚本），VSCode 无法单独完成，必须组合外部机制：
- macOS：用
sandbox-exec包裹 node 命令，例如：sandbox-exec -f ./sandbox.sb node script.js，其中sandbox.sb是定义文件路径白名单的 plist 规则文件 - Linux：用
firejail --private=.启动终端，再在该终端里开 VSCode，这样node进程只能看到当前目录及子目录 - Windows：无轻量级等效方案；可考虑 WSL2 +
chroot或 Docker Desktop 配合docker run -v $(pwd):/work -w /work node:alpine node script.js - 注意：
code-runner插件不支持传入这些外壳命令，必须改用终端手动运行，或重写其executorMap为完整 shell 命令（含firejail或sandbox-exec）
最易被忽略的一点：即使你做了上述所有限制，只要脚本里调用 child_process.execSync('ls /') ，它仍可能绕过 JS 层路径检查——真正的边界在操作系统进程权限，不在 VSCode 或 Node.js 配置里。
