我碰到过类似的企业内网防火墙坑，你这个情况的核心矛盾点其实是：npm在处理git+http://格式的依赖时，会自动忽略你指定的HTTP协议，偷偷改用HTTPS去拉取仓库——哪怕你写的是明明白白的http，这就是为什么直接git clone http能成功，但npm i git+http却报SSL证书错误的原因。

下面是几个亲测有效的解决方案，按优先级推荐：

1. 用Git URL替换强制走HTTP（最安全） #

通过Git的全局配置，把所有指向BitBucket的HTTPS请求自动替换成HTTP，这样npm内部触发的Git请求都会乖乖走HTTP，不会碰SSL证书：

git config --global url."http://bitbucket.org/".insteadOf "https://bitbucket.org/"

如果只针对这个特定仓库，也可以设置局部规则：

git config url."http://bitbucket.org/geowerkstatt-hamburg/masterportalapi.git".insteadOf "https://bitbucket.org/geowerkstatt-hamburg/masterportalapi.git"

2. 修改package.json的依赖写法 #

直接在package.json里把依赖写成带完整分支/Tag的HTTP格式，避免npm自动转换协议：

"dependencies": {
  "masterportalapi": "git+http://bitbucket.org/geowerkstatt-hamburg/masterportalapi.git#main"
}

这里的#main替换成你实际需要拉取的分支名、Tag或者Commit哈希，明确指定版本能减少npm解析时的协议切换行为。

3. 临时禁用npm的SSL校验（谨慎使用） #

如果上面的方法都不生效，可以临时关闭npm的严格SSL校验，但这个是全局设置，用完记得改回来：

# 关闭校验
npm config set strict-ssl false
# 安装依赖
npm install
# 恢复校验
npm config set strict-ssl true

企业环境下不建议长期开启这个，会带来安全风险。

4. 关闭Git的SSL验证（针对性设置） #

有时候企业防火墙会篡改Git的配置，你可以针对当前项目关闭SSL验证：

# 进入项目根目录
cd your-project-folder
# 关闭当前项目的Git SSL验证
git config http.sslVerify false

如果需要全局生效就加--global参数，但同样不推荐全局长期关闭。

补充说明 #

为什么直接git clone http://xxx能成功？因为Git会严格按照你指定的协议发起请求，不会自动切换；但npm在处理git+http格式的依赖时，内部有一套协议转换逻辑，针对BitBucket、GitHub这类托管平台，它会默认尝试用HTTPS去拉取，这才导致了看似矛盾的SSL错误。

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