本质不是vscode问题，而是用户对缓存路径无写权限；需定位npm或vscode缓存目录（如~/.npm、%appdata%\code\cache），验证属主与权限，重设路径至用户可写位置（如~/.npm-cache或%localappdata%\npm-cache）并清理旧缓存，同时避开onedrive、wsl挂载盘等高风险路径。
VSCode本地缓存权限不足，本质不是VSCode的问题，而是当前用户对缓存路径没有写权限——必须定位具体缓存目录并重置属主或迁移路径，否则每次启动、安装插件、运行语言服务都会失败。
确认 npm 缓存路径是否被 root 或系统账户锁定
npm 的 cache 目录若属主是 root（Linux/macOS）或 SYSTEM（Windows），npm install 就会报 EPERM 或 EACCES，连带 VSCode 的 JS/TS 语言服务、ESLint 插件也会卡住。
- 先查位置：
npm config get cache（常见输出如/Users/xxx/.npm或C:\Users\xxx\AppData\Roaming\npm-cache） - Linux/macOS 验证权限：
ls -ld $(npm config get cache)，若第三列不是你的用户名，就是它 - Windows 验证：右键该文件夹 → “属性” → “安全” → 看当前用户是否有“修改”权限
- 别修
node_modules或AppData根目录——只动cache子目录本身
重设 npm 缓存到用户可写路径（推荐方案）
把缓存挪到明确归属你自己的路径，避开 OneDrive、Program Files、/usr/local 等高风险区域，是最稳定的做法。
- Windows 执行：
npm config set cache "%USERPROFILE%\AppData\Local\npm-cache"，再手动删掉旧缓存（如%APPDATA%\npm-cache） - macOS/Linux 执行：
npm config set cache ~/.npm-cache，然后mkdir -p ~/.npm-cache && chown -R $USER: ~/.npm-cache - 验证生效：
npm config get cache必须返回新路径；再跑一次npm install lodash --save-dev，确认不再报错 - 注意：Node.js 安装路径含空格或中文（如
C:\Program Files\nodejs）也会让npm cache verify静默失败，建议用where node（Win）或which node（macOS/Linux）检查
VSCode 自身缓存目录权限失控的典型表现
不是 npm，但 VSCode 启动慢、白屏、插件灰显、语言服务反复崩溃——大概率是 Cache、CachedData 或 workspaceStorage 这三个目录被 sudo code 污染过，导致普通用户无法覆盖写入。
- Linux/macOS 检查：
ls -ld ~/.config/Code/{Cache,CachedData,User/workspaceStorage}，若属主是root，就需修复 - Windows 检查：
Get-Acl "$env:APPDATA\Code\Cache"（PowerShell），看“组或用户名”里是否有你的账户且含“写入” - 不建议全局
chmod -R 777——风险太高；应只修正对应目录：sudo chown -R $USER: ~/.config/Code/Cache（macOS/Linux） - 更彻底的做法：关掉所有 VSCode 进程（包括
Code Helper和远程进程），再删这三个目录（Cache、GPUCache、CachedData），重启后自动重建
OneDrive / WSL / 挂载盘导致的静默权限失效
缓存目录若落在 OneDrive、iCloud Drive、/mnt/c（WSL）、或网络挂载点上，操作系统可能在底层拦截写操作，错误不报或只显示“permission denied”，实际是同步锁或元数据缺失所致。
- VSCode 设置中搜索
files.defaultLanguage或editor.formatOnSave，临时关闭可疑功能，排除插件触发写入 - WSL 用户重点检查：
mount | grep /mnt/c，若输出不含metadata，则需编辑/etc/wsl.conf加入options="metadata,uid=1000,gid=1000"，再执行wsl --shutdown重启 - Windows 用户直接把项目和缓存移出 OneDrive：改用
D:\projects\或%USERPROFILE%\dev\，比调权限更可靠 - 别信“清空临时目录就能好”——如果路径本身受同步机制保护，删
%TEMP%只是掩耳盗铃
真正容易被忽略的是缓存路径的归属权与挂载策略的耦合：一个 chown 解决不了 /mnt/c 的元数据缺失，一次 npm config set 也绕不开 OneDrive 的文件锁。动作必须匹配问题层级，否则修了三天还是报 EACCES。
