npm ci在GitHub Action报peer依赖冲突VSCode终端无报错原因

该差异由npm版本补丁、环境配置、基础系统依赖解析逻辑的细微差别共同导致，核心诱因如下：

• npm 8.5.0 与 8.5.5 版本的peer依赖校验逻辑存在补丁级差异
  npm 8.x早期迭代阶段的peer冲突检测存在多处漏判bug，8.5.2、8.5.5两个补丁版本先后修复了嵌套依赖peer范围校验、可选peer依赖标记识别的问题：8.5.0版本不会阻断部分非根目录直接声明的依赖peer冲突，而8.5.5版本补全了全依赖树的peer冲突扫描逻辑，会将之前版本漏判的冲突直接抛出，阻断安装流程。
• 本地环境存在隐式npm配置覆盖了默认校验规则
  本地开发环境大概率存在全局或用户级.npmrc配置，设置了legacy-peer-deps=true或strict-peer-deps=false，执行npm ci时会默认读取该配置，跳过peer冲突阻断逻辑；而GitHub Action使用的容器环境是全新初始化的，无任何自定义npm配置，会严格执行默认的peer冲突阻断规则。可在本地执行npm config get legacy-peer-deps命令验证该配置项的实际值。
• Alpine基础镜像的依赖解析逻辑与常规环境存在差异
  GitHub Action使用的node:16.14-alpine镜像基于musl libc实现，和本地macOS、Windows、glibc版本Linux的二进制依赖解析逻辑不同：部分带原生绑定的依赖在Alpine环境下会自动回退到适配musl的备选版本，备选版本的peer依赖范围和常规环境拉取的版本不一致，会额外触发常规环境不存在的peer冲突。
• 本地lockfile或缓存与CI环境不一致
  如果本地仓库的package-lock.json和GitHub Action拉取的提交对应lockfile内容不完全匹配（比如本地存在未提交的lockfile改动、之前执行npm install更新了嵌套依赖版本但未提交），或是本地存在node_modules缓存绕过了部分校验逻辑，也会导致npm ci的执行结果出现差异。

复现验证方式：在GitHub Action流程中添加npm config list步骤打印全量npm配置，同时在本地使用Docker启动同版本node:16.14-alpine容器，挂载仓库代码后执行npm ci，即可复现和CI环境完全一致的报错。

内容的提问来源于stack exchange，提问作者Papidev