ENOENT 和 EACCES 不是同一种故障。前者优先查路径是否存在，后者优先查访问权限；同一份安装日志里还可能同时出现警告和真正导致失败的错误。

Windows 安装依赖：先找缺失的路径

2018 年一次 Ionic/Cordova 安装出现两类信息：

npm WARN checkPermissions Missing write access to ...
npm ERR! enoent ENOENT: no such file or directory, access ...

当时重新执行安装后恢复，但这不足以证明所有 ENOENT 都是下载不全。路径还可能由解包、安装脚本或构建步骤生成，也可能因为工作目录不对而被错误引用。

先找到最早的实质失败，再看 syscall 与 path：缺的是源码目录、缓存文件，还是安装脚本要启动的可执行文件？以 Windows PowerShell 为例，可在替换为报错路径后只读检查：

Get-Location
Test-Path -LiteralPath 'C:\example\project\missing-path'
Get-Item -LiteralPath 'C:\example\project'

确认缺失对象应由哪一步产生，再修正那一步并重新安装。保留锁文件与失败日志，不先清空全部缓存或随意换一组依赖版本。

macOS 打包：配置文件也有自己的所有者

另一次错误发生在：

EACCES: permission denied, open
'/Users/xxx/.config/configstore/insight-cordova.json'

这是用户配置路径，不一定是项目目录权限。将下面示例路径换成报错中的实际路径，逐级检查；不要公开配置文件内容，其中可能含标识或凭据。

id
ls -ld /Users/xxx/.config
ls -ld /Users/xxx/.config/configstore
ls -l /Users/xxx/.config/configstore/insight-cordova.json

要核对运行身份、文件所有者、读写权限及父目录的可访问性。如果确认是此前以错误身份创建的文件，应由有权限的操作者仅修正那个明确目标，避免递归修改整个用户目录，更不要用 chmod 777 或把全部打包命令改成 sudo。

用错误名称，不靠 errno 数字跨平台猜测

Node.js 系统错误文档 区分了缺少路径与权限拒绝。不同系统的数字错误码可能不同，记录 code、syscall、脱敏 path、运行版本和首个失败步骤更有用。

处理后以普通用户重试原操作，确认不再出现同一路径错误，并继续观察下一步日志。安装成功、能打包和产物能运行仍是不同的验证点。