其实关键并不是 npminstall 的这个提交，可能、应该、也许出发点是好的
https://github.com/cnpm/npminstall/pull/256

但在全局引入这种污染行为，是在 cnpmcore 的这个提交
https://github.com/cnpm/cnpmcore/commit/a309edfa2e4a34d2a96fe36ffadea13e60f453ba

也就是在这个提交之后，bug-fersion 扩散到了整个镜像源

觉得没有问题的，多半应该也是不会看命令行 warning ，装不了删删 lock 对不对啊，那也就无所谓了嘛对不对啊

反正之前 bun 的 pr 里 cnpm 相关讨论看下来，维护者对这种操作还挺自豪的

所以，cnpm 是顺便给国内开发者用的这个定义应该是不会错的，这就不是个正经源

部署还是封装成 docker 整个扔上去算了

这种时候就需要赛博大善人出马了。  dockerhub 和 npm 都可以用 cf worker

我建议是设置下.npmrc ，下载你需要的包上传到内网的包管理服务器，例如 gitea 的包管理或者 Nexus,然后替换你本地的引入

可以理解 op 的状况，本地开发还好，CI 很多情况下是不能用代理的，就算能用代理  下载速度也是没法跟用国内镜像源相比

希望 op 测试出好用的镜像源后能跟大家分享一下

只能换新的镜像源了

大开眼界

之前国内的 docker 仓库也会存在这些问题

让公司在外网做一个 npm 私服穿墙，然后内网私服连外网私服， 🐶

很久没用过国内镜像了。
pip npm composer go 通通走代理。
速度比国内镜像还快,也各种奇葩的网络小问题。

ps: 公司电脑内网服务器:
export http_proxy=http://192.168.50.30:7890
export https_proxy=http://192.168.50.30:7890

外网服务器没辙,装代理客户端麻烦。