Node.js项目升级至Node 16后yarn install遇AWS CodeArtifact 401未授权问题排查

核心原因推测 #

虽然分支未修改CodeArtifact相关配置，但Node.js从12升级到16后，配套的npm/yarn工具链版本、AWS SDK兼容性、环境变量读取逻辑可能发生了变化，这些隐性差异会影响包拉取时的认证流程。

具体排查步骤 #

• 核对yarn版本差异
  执行yarn --version对比两个分支的yarn版本：Node.js 12通常默认搭配yarn 1.x，而Node.js 16可能引入yarn 2+（berry），两者对.npmrc的解析规则、_authToken的读取逻辑完全不同。比如yarn berry会优先使用项目内的.yarnrc.yml而非.npmrc，如果分支升级Node时隐式切换了yarn版本，就会导致认证失效。

• 验证生成的.npmrc有效性
  直接查看脚本生成的.npmrc内容，确认registry和_authToken格式正确。然后用curl手动测试token权限：

  curl -H "Authorization: Bearer <你的_authToken>" <registry url>/infinity-logger/-/infinity-logger-0.13.1.tgz
  

  如果curl返回401，说明token本身无效，需要检查脚本生成token时使用的AWS凭证是否有拉取该包的权限；如果curl能成功下载，说明问题出在yarn对.npmrc的解析上。

• 排查环境变量与全局配置干扰
  执行env | grep -E "(NPM|YARN)"对比两个分支的环境变量，看是否存在NPM_CONFIG_REGISTRY、YARN_REGISTRY等变量覆盖了.npmrc的配置。另外，检查用户目录下的~/.npmrc或~/.yarnrc，Node版本切换后可能加载了不同的全局配置文件。

• 对比yarn.lock的包源配置
  搜索两个分支yarn.lock中infinity-logger的条目，确认包的registry地址是否指向正确的CodeArtifact仓库。如果Node16分支的lock文件中该包的来源被意外修改（比如依赖安装时自动切换了registry），也会导致认证失败。

• 检查AWS凭证的加载逻辑
  脚本生成CodeArtifact token时依赖AWS凭证，Node.js 16下AWS SDK的凭证加载顺序可能与Node12不同。分别在两个分支执行：

  aws codeartifact get-authorization-token --domain <你的domain> --domain-owner <owner>
  

  对比返回的token是否一致，同时确认当前使用的AWS profile是否有权限拉取infinity-logger包。

为什么不同分支表现不同？ #

两个分支的核心差异是Node.js版本，这会引发一系列连锁变化：

• 配套的npm/yarn版本不同，对.npmrc的解析、认证流程的实现逻辑有差异；
• Node.js 16对环境变量、文件读取的优先级进行了调整，可能导致脚本生成的.npmrc未被正确加载；
• AWS SDK在Node16下的凭证加载规则变化，导致生成的token权限或有效期不符合要求。

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