一、现象

一个前端项目的 .npmrc 明明用了有问题的写法（authToken 行用空格而非等号，
见《前端私有依赖包认证失败问题排查》的缺陷2），但开发者在本地「直接 npm install」
却成功了，没有报任何认证错误。

这让人困惑：既然配置有毛病，为什么能装上？

二、关键线索

对该项目的核对结果：

• .npmrc 的 authToken 行是空格写法：...:_authToken ${ARTIFACTORY_TOKEN}
• 它确实依赖私有包 @scope/private-ui-lib
• 按理，空格写法会让 token 为空 → 匿名请求 → 私有包返回 404

但实测中它却装成功了。唯一能解释的变量就是 npm 本地缓存。

三、验证：缓存命中决定成败

实验设计（控制单一变量 = 缓存）

# 场景1:清空缓存,用空格写法安装
rm -rf <npm缓存>/_cacache
# 空格 .npmrc + 安装
=> 结果:E404 失败

# 场景2:先用正确方式(等号)安装一次,让私有包进入缓存(预热)
# 等号 .npmrc + 安装
=> 成功,私有包被缓存

# 场景3:换回空格写法 + 删除 node_modules(但保留缓存) + 再次安装
# 空格 .npmrc + 安装(缓存已有该包)
=> 结果:成功!私有包装上了

同样的空格写法：清缓存后 E404 失败，缓存命中后却成功。唯一变量就是缓存。

为什么缓存命中就不报错

npm 安装某个包时，如果本地缓存里已经有这个包的压缩包，就直接从缓存取，
不发网络请求。既然不发请求，自然不需要认证——于是「空格写法导致 token 为空」
这个缺陷根本不会被触发。

那这个项目的缓存里为什么会有这个私有包？因为开发者之前装过另一个也依赖同一个
私有包同一版本的项目，那次把包下载并缓存了下来。

四、同样的机制也发生在 Docker 构建里

Docker 把 npm config set ... && npm ci 这一串当作一个镜像层（layer）。
只要 package.json/package-lock.json/.npmrc 没变，这一层就命中缓存、不重新执行。
CI 构建日志里能看到类似 #7 ... CACHED 的标记——说明那一步根本没真跑。

结果就是：很多项目第一次构建时碰巧成功（或当时还能匿名访问），之后一直吃缓存，
有缺陷的安装步骤从未真正重跑，缺陷也就一直没暴露。直到某天缓存失效（改了依赖、
触发 CACHEBUST、换了构建机、清了缓存），安装真正重跑，缺陷才瞬间爆发。

五、结论与教训

• 「能装成功」不等于「配置正确」。缓存会掩盖认证缺陷，制造「一切正常」的假象。
• 本地缓存命中、Docker 层缓存命中，是同一类陷阱的两种表现。
• 排查这类问题时，必须每轮物理清空缓存（rm -rf _cacache），并在干净目录里测，
  否则结论不可信。
• 真正的判断标准：在干净缓存 + 正确运行环境下能否安装成功。

六、通俗解释（大白话版）

还是会员制仓库的比喻。门口有个寄存柜（缓存），放着别人取过、暂存的箱子。

你的会员卡其实是坏的（格式写错，等于没带卡）。但你今天要的那个箱子，昨天别人取过、
正好还在寄存柜里——你直接从寄存柜拿走就行，根本没走到「出示会员卡」那一步。
所以你以为「我的卡没问题啊，能取到货」。

可一旦寄存柜被清空（管理员打扫、或你换了个没有寄存柜的新仓库），你再去取，就必须
出示会员卡了——这时坏卡立刻露馅，你被拦在门外。

教训：别用「这次取到货了」来证明「我的卡是好的」。要在寄存柜是空的情况下
试一次，才知道卡到底行不行。软件里也一样——验证配置是否正确，必须先把缓存清干净。