先看是哪一个请求失败

报错位置主要检查对象
获取包信息或压缩包超时registry、代理、DNS 与 TLS
私有包 401 / 403目标 registry、scope 与认证权限
Git URL 依赖失败Git 或 SSH 自己的网络配置
安装脚本另行下载失败脚本访问的域名及所用工具
npm run dev 后 localhost 打不开开发进程是否启动、监听地址、端口与应用错误

npm run dev 只是执行项目脚本，本地页面失败不必然和外网有关。先看终端里的真实错误及监听地址。不要把每个 npm 问题都归因于线路，更不要用换镜像来处理 TypeScript 编译错误或端口占用。下面参数按 npm 11 官方文档核对，其他主版本先查看对应说明。

第一步：记录配置来源，只在本地查看敏感值

在发生问题的项目目录运行
node --version
npm --version
npm config get registry
npm config get userconfig
npm config get globalconfig
npm config get proxy
npm config get https-proxy

最后两个值可能带认证信息，不要原样发到群里。项目 .npmrc、用户配置、全局配置、环境变量与命令参数可能同时存在；同一命令在不同目录有不同结果时，优先检查项目文件。私有 scope 的 registry 也可能与默认 registry 不同。

第二步：用公开包信息做单次代理对照

端口换成实际 HTTP / mixed 端口；这些命令不会安装包
npm ping --registry=https://registry.npmjs.org/
npm view npm version --registry=https://registry.npmjs.org/ --https-proxy=http://127.0.0.1:7890

第一条使用当前有效的代理配置，并不自动代表直连；第二条给这次 HTTPS 请求明确指定代理。若要做真正直连对照，还需清楚现有环境变量、TUN 和路由器是否接管。返回版本信息证明这个公开 registry 请求成功，不证明项目所有依赖和安装脚本都能联网。

固定 registry 是为了比较同一目标，不要求你永久从公司私有源切回公共源。公司包仍按组织指定的 scope 与认证配置访问，不能把私有 token 复制给另一个镜像站。

第三步：对症修复，不把证书校验关掉

  1. 如果仅显式代理成功，可先保持单次参数，再决定是否写入用户或项目作用域。写之前记录原值和来源，避免覆盖团队配置。
  2. 若是证书错误，检查系统时间、服务端证书链和 npm 使用的 CA 配置。受管理环境的 CA 应由管理员提供；不要设置 strict-ssl=false。
  3. 若 registry 查询成功但安装失败，阅读失败 URL：Git、二进制下载器和其他脚本可能没有使用 npm 的代理，需要分别核对。
  4. 若是 401 / 403，查账户权限和 scope 认证；代理可达并不会给账号增加私有包权限。

需要持久配置时，明确如何恢复

仅在确认要修改用户配置时执行；退出测试后按原值恢复
npm config set https-proxy http://127.0.0.1:7890 --location=user
# 只有原来没有这个用户级设置时，才用删除恢复
npm config delete https-proxy --location=user

如果原来已有值，应恢复那个值，而不是直接删除。修改后重开终端，从原项目目录检查实际配置。不要删除整个 .npmrc；它可能还有 registry、scope 和认证设置。

验收原项目

回到真正失败的安装流程，确认具体依赖下载成功，再单独验证开发服务器。保留锁文件，不为网络故障随意删除 package-lock.json；除非有明确缓存损坏证据，也无需执行强制清空缓存。分享日志前隐藏 token、账号、私有仓库和代理认证 URL。