插件报 eacces 或 enoent 多因 node.js 进程读写临时目录失败，主因是路径硬编码、权限缺失或沙盒拦截；应使用 os.tmpdir() 获取跨平台临时路径，并用 fs.accesssync 验证可写性。
插件安装或运行时报 EACCES 或 ENOENT，十有八九不是网络或市场问题，而是 Node.js 进程在 VSCode 内部读写临时目录失败 —— 路径硬编码、权限缺失、沙盒拦截这三类原因占了 90% 以上。
为什么 fs.readFile('/tmp/config.json') 在插件里总报错
插件代码若直接写死 /tmp 或 %TEMP%，基本等于放弃跨平台兼容性。macOS 的 /tmp 会被系统自动清理（7 天），Windows 的 %TEMP% 可能被 OneDrive 重定向到受保护路径，而 Linux 下的 /tmp 若由 systemd-tmpfiles 管理，还可能带 noexec 标志。
- 用
os.tmpdir()替代硬编码路径，它会返回当前平台真实的、Node.js 认可的临时目录 - 在插件激活逻辑开头加一句
fs.accessSync(os.tmpdir(), fs.constants.W_OK)，捕获异常并给出明确提示（比如 “临时目录不可写，请检查权限或杀软拦截”） - 别依赖
process.env.TEMP或process.env.TMPDIR—— VSCode 启动时可能没继承这些变量，尤其在 non-login shell 下
VSCode 终端里 fs.writeFileSync 报 EACCES 怎么定位
这不是 Node 版本或插件代码 bug，是进程实际拿到的写入权被系统策略卡住了。先确认是不是终端本身权限上下文异常：
- 在 VSCode 集成终端执行
umask，对比系统终端（如 iTerm / Terminal.app / PowerShell）输出；若不同（比如 VSCode 里是0022，系统里是0002），说明 login shell 没生效 - 临时验证：在终端里手动执行
umask 0002，再跑写文件测试；若成功，问题锁定在 shell 初始化流程 - 长期修复：把
umask 0002加进~/.zshrc或~/.bash_profile，并确保 VSCode 是从 Dock/开始菜单启动（非code命令行调起），否则不会加载 profile
Windows 上插件访问 %TEMP% 被拒的典型表现
错误信息常含 Access is denied 或 The system cannot find the path specified，但 echo %TEMP% 又能正常输出 —— 这说明路径存在，只是当前用户无权访问该位置。
- 查真实路径：
echo %TEMP%（CMD）或$env:TEMP（PowerShell），然后看输出是否落在%USERPROFILE%\AppData\Local\Packages\或 OneDrive 同步目录内 - 检查 Windows 安全中心 → “应用控制” → “勒索软件防护”，某些企业策略会静默阻止 VSCode 写入这些路径
- 绕过方案（仅限调试）：在插件入口加
process.env.TEMP = path.join(os.homedir(), 'temp');，再fs.mkdirSync(process.env.TEMP, { recursive: true })，强制走用户主目录下可控路径
插件里用 fs.unlink 清临时文件却失效？注意生命周期
macOS APFS 下 fs.unlink 不保证立即释放磁盘或解除文件句柄，尤其当其他进程（如另一个插件实例、终端里的 tail -f）还在读该文件时，unlink 只是标记删除，文件内容仍驻留直到所有句柄关闭。
- 别假设
unlink后文件就“消失”了，后续同名writeFile可能因残留句柄导致行为异常 - 更稳妥的做法是：用
fs.open(..., 'wx')创建唯一命名临时文件（避免竞态），操作完立刻close()，再unlink - 跨进程共享临时文件时，优先考虑用
os.tmpdir()+crypto.randomUUID()构造路径，而不是靠fs.existsSync轮询判断
临时目录权限问题最麻烦的点在于：它不报具体路径，只抛通用错误；而 VSCode 插件又常在后台静默运行，连日志都不打。动手前务必先用 os.tmpdir() 和 fs.accessSync 把真实路径和权限状态打出来，别猜。
