科技 · 实用指南
npm 出现 EACCES 权限拒绝？先读失败路径，再考虑 sudo、chown 或前缀修改
缓存、项目、全局前缀与容器错误外观相同，却属于不同所有者。任何修改前先保留准确路径并判定范围。
EACCES 只说明某次文件系统操作被拒绝，并不表示 npm、缓存、当前项目或全局安装前缀全部损坏。
决定性线索是准确的 `npm ERR! path`、syscall 和执行命令的账号。修改所有权、权限、缓存、前缀或用户之前，先保留这三项。
本指南把故障分成用户缓存、本地项目、全局前缀、容器或 CI 挂载四类，并给出只读证据卡与下一步负责所有者。
一个错误码覆盖四种不同权限范围
`~/.npm` 下的路径指向用户缓存；当前项目内的 `node_modules` 指向项目树；位于 `npm config get prefix` 结果下的路径通常属于全局安装；`/workspace`、`/app`、挂载卷或异常 HOME 则可能是容器、CI、远程工作区或服务账号不匹配。
四个分支的所有者与修复方式不同。改全局前缀不会让 `/var/test/node_modules` 可写；递归修改缓存也无法修复只读挂载；用 sudo 重跑还可能产生新的 root 所有文件。
修改前先保存只读证据卡
复制完整 EACCES 片段，至少保留 code、syscall、path、cwd、Node/npm 版本和原命令。再记录 `npm config get cache`、`npm config get prefix`、`npm prefix`、`npm root -g`、当前账号与工作目录。这些命令只解释范围，不执行修复。
macOS/Linux 用 `ls -ld` 或 `namei -l` 查看失败路径及父目录；容器还要记录 `id`、`pwd`、HOME 与挂载定义。Windows 用 `Get-Acl`。工单中不要粘贴 registry token 或 `.npmrc` 内容。
失败路径位于 npm 缓存时，先核所有权与运行环境
若路径在 `npm config get cache` 返回目录下，项目本身可能完全可写。比较缓存目录、父目录所有权、当前 UID，以及是否曾用 sudo 或容器向同一 HOME 写入。`npm cache verify` 是完整性检查，清空缓存不是权限诊断。
不要盲目执行 npm 打印的 chown 命令。Termux 案例证明，“root 所有缓存”提示本身也可能不符合真实运行环境。只有确认缓存确实归错账号后，才由 HOME 的所有者审核小范围修复。
失败路径位于项目时，修项目边界，而不是 npm 全局设置
若 `mkdir` 失败在 `/var/test/node_modules`、仓库或挂载工作区，说明当前账号不能写本地安装位置。前缀修改与重装版本管理器都不会改变该目录。应识别项目所有者、组策略、ACL、挂载模式和最初创建目录的账号。
不要无审核使用 `chmod -R 777`、`chmod a+w` 或对共享树递归 chown。优先把仓库恢复给预期账号/组，或让构建以挂载工作区的真实所有者运行。
失败路径位于全局前缀时，使用 npm 支持的路线
npm 官方对全局安装 EACCES 推荐使用 Node 版本管理器，或把 npm prefix 改到用户自有目录；偶尔运行命令还可考虑 `npx`。这些路线避免生成 root/user 混合所有权。
执行前确认失败路径确实位于全局前缀。受管设备的系统 Node 目录可能刻意由管理员控制；此时应申请批准的运行环境，而不是绕过策略。
容器与 CI 要对齐 UID、HOME 和挂载
容器和 CI 中，数值 UID/GID 比用户名更可靠。主机绑定挂载可能属于另一个 UID；HOME 可能指向只读或共享缓存；更早的 root 步骤也可能同时污染 `node_modules` 与缓存。
持久修复通常是对齐执行 UID 与工作区所有者、给作业独立缓存或调整挂载策略。未经卷所有者批准，不要从临时容器内递归 chown 主机卷。
选择最小的经审核动作并保留交接
交接应列出失败路径、syscall、当前账号、缓存、本地/全局前缀、项目所有者和环境类型，并归类为缓存、项目、全局或容器/CI。
若路径超出预期项目或 HOME、共享树所有权不一致、挂载只读、运行环境受管、账号未知，或建议会扩大权限，就停止。EACCES 的正确结束是预期账号完成预期操作，而不是用更强账号掩盖错误。
