张苏丽去年在客户现场遇到一次相当尴尬的故障：项目交付前最后一天，需要把代码推到客户的 GitLab 仓库做归档，结果 git push 卡了几分钟直接超时，换了几台电脑都一样。当时第一反应是网络问题，排查了半天才发现，仓库的远程地址是 git@gitlab.xxx.com:team/project.git 这种 SSH 形式，而客户办公网对所有出站的 22 端口有限制，Git 的 SSH 连接根本出不去。后来我执行了一条 git remote set-url origin https://gitlab.xxx.com/team/project.git，再配上个人访问令牌（PAT）做认证，一分钟内就推上去了。
这个场景其实就是今天想聊的话题：Git 远程地址在 SSH 和 HTTPS 之间切换，尤其是切到 HTTPS 之后怎么用 PAT 完成认证。它不像 git add、git commit 那样每天都会用到，但只要你换过网络环境、接过新单位的仓库、或者帮别人处理过 git push 失败，几乎都会撞上这个问题。这篇文章我尽量把原理讲清楚，再把操作步骤和踩过的坑一次说完。
1. SSH 和 HTTPS 两种远程协议，到底差在哪
1.1 本质区别：传输通道和认证方式
很多同学对 SSH 和 HTTPS 的认知停留在"一个要配密钥，一个要输密码"，其实这只是一个表象。两者的核心差异在于：
SSH 走的是 22 端口，使用公钥加密机制完成身份认证。客户端本地保存私钥，服务器端保存公钥，连接时通过签名和质询完成双向验证。因为整个过程没有密码在网络上传输，所以安全级别天然更高，适合长期、频繁的代码操作。
HTTPS 走的是 443 端口，本质上是 HTTP 协议加了一层 TLS 加密。Git 用它做远程操作时，认证靠的是"用户名 + 密码（或令牌）"。TLS 保证了传输过程加密，所以密码不会明文暴露在网络链路上。
这里有个容易被忽视的点：很多办公网络、云厂商的安全组策略默认会放行 443 端口，但 22 端口常常被限制，因为 22 端口是黑客扫描的重灾区。所以你会发现，在公司能正常访问网页（HTTPS），但 git clone git@... 就是连不上，原因多半就是 22 端口不通。
打个比方：SSH 像持门禁卡走员工通道，HTTPS 像走访客通道。员工通道安静高效，但是门禁系统只对特定人群开放；访客通道虽然每次要登记（输密码/token），但只要你拿到访客凭据，任何时间都能进来。
1.2 什么时候需要切换
切换不是没事找事，通常遇以下几种情况，你就该考虑动了：
| 场景 | 推荐协议 | 原因 |
|---|---|---|
| 家庭网络/服务器部署 | SSH | 脚本化和自动化方便，无需重复认证 |
| 办公网/客户现场等受限网络 | HTTPS | 443 端口基本畅通，不容易被网络策略卡脖子 |
| 多平台多账号管理 | HTTPS + PAT | 避免维护多套 SSH 密钥对，token 粒度更细 |
| CI/CD 自动化 | HTTPS + Token/Secret | 流水线中明文密码不友好，token 可单独授权、可撤销 |
| 二步验证开启后的本地 pc | HTTPS + PAT | 普通密码无法用于 Git 操作，必须用令牌 |
我自己用得最多的场景，就是"开发机在公司内网，需要访问 GitHub 拉公共依赖"。公司网络不限制 GitHub 的 HTTPS 访问，但如果用 SSH，则经常超时。这时候临时把 origin 改成 HTTPS 地址，用完再切回来，比反复调整网络配置省事太多。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 动手切换前，先摸清当前远程地址配置
2.1 查看当前远程仓库地址
切换之前，先确认自己仓库现在的远程地址是什么状态。命令很简单：
bash复制git remote -v
输出通常长这样：
code复制origin git@github.com:user/repo.git (fetch)
origin git@github.com:user/repo.git (push)
或者：
code复制origin https://github.com/user/repo.git (fetch)
origin https://github.com/user/repo.git (push)
`