火星后继者先问一个问题：你电脑上同时配了几个 git 平台的账号？我见过太多同事，本地配了 GitHub、公司 GitLab、Gitee 三套账号，平时用着没事，一到换电脑、换公司域名，或者某次手滑改了配置，就彻底乱套。最典型的症状是：昨天还在往 GitHub 推代码，今天连公司的 GitLab 都访问不了，Git 提示 Authentication failed；或者更气人的——两边都能访问，但提交记录里的作者邮箱，串成了另一个平台的邮箱。这些现象背后，其实是一套被大多数人忽略的机制在起作用：git 凭据管理。
这篇内容想把“多平台凭据共存”这件事彻底讲透。不管你是用 HTTPS 还是 SSH，不管你在 Windows、macOS 还是 Linux 上开发，读完你都能配出一套互不干扰的凭据环境，并且知道出了问题该去哪里查、怎么修。适配人群很明确：被多账号、多平台、重复输入密码折腾过的开发者，尤其是需要在个人项目和公司项目之间频繁切换的人。下面我们直接从底层机制说起。
1. 先看懂git凭据存取机制：helper、key与冲突根源
1.1 git为什么不直接记住密码：凭据helper的完整工作流程
要搞清楚多平台凭据冲突，先得明白 git 到底怎么处理认证。很多人有个误解，以为 git 本身负责身份认证，其实不是。git 只是把“用户名和密码/令牌”转交给远端服务器，真正验证身份的是服务器那边。git 要做的，是负责凭据的“存取”。
具体流程是这样的：
- 你执行 git push 或 git clone，git 向远端服务器发起带认证的请求。
- 服务器返回 401/403 或要求认证，git 开始寻找凭据。
- git 调用配置好的 credential helper，问它“有没有这个地址对应的凭据”。
- helper 有，就返回给 git；没有，就弹出输入框让你手动输。
- 认证成功后，git 把完整的凭据交给 helper 保存，下次直接从 helper 里取。
这整个过程，helper 干了最核心的两件事：找凭据、存凭据。不同的 helper 区别在于凭据存在哪、存多久、安不安全。最常见的三个 helper 分别是 store、cache 和 manager。
- store：把凭据明文写进
~/.git-credentials文件，一行一条。好处是配置简单，坏处是毫无安全性可言，文件一旦泄露，所有账号全部裸奔。 - cache：把凭据缓存在内存里，默认 15 分钟过期。适合临时使用，重启就没了。
- manager（macOS 上叫 osxkeychain，Windows 上是 Git Credential Manager）：把凭据加密存进系统级安全存储，比如 Windows 凭据管理器、macOS 钥匙串、Linux 的 libsecret。这种最安全，也是我推荐大家的默认选择。
理解这个流程，你就知道排查的第一站永远是“git 到底在用哪个 helper、凭据存在哪”。
1.2 凭据的key是什么，多平台凭据为什么会互相覆盖
git 在调用 helper 存取凭据时，会传过去一个 context，里面主要包含三个信息：protocol（https 还是 ssh）、host（github.com、gitlab.company.com 这种）、username（有些场景可能为空）。helper 用这些信息拼出一个 key，凭据就挂在这个 key 下面。
多平台凭据冲突的本质，全藏在这三个字段里：
- 不同 host 的凭据，天然不会覆盖。github.com 和 gitee.com 是不同 host，在 helper 眼里是两个完全独立的 key，各存各的，不冲突。
- 同一个 host 下多个账号，才是冲突高发区。比如你和同事共用一个 GitLab 实例，一个 host 下有 alice 和 bob 两个账号，git 默认并不知道当前仓库该用哪个账号，谁最后认证成功，谁就把前一个人的凭据顶掉。
- 一旦 remote URL 里没写用户名，git 拿到的 username 为空，那么不同账号在 helper 眼里可能就是同一个 key，直接互相覆盖。
举个例子。你有一个仓库用的 remote 是 https://github.com/alice/repo.git，另一个是 https://github.com/bob/another.git。如果两个 URL 都不带用户名，git 请求凭据时 username 大概率是空值，helper 就只保存一份与 github.com 对应的凭据。你切到 bob 的仓库时，helper 返回的可能是 alice 的 token，认证失败，或者你重新登录后，又把 alice 那份覆盖了。
所以“多平台凭据共存”的真正难点，不是让 git 记住密码，而是让 git 在任意场景下都能拿到正确的（protocol, host, username, password）组合，并且取用的时候能选对。
1.3 HTTPS和SSH两条路线怎么选，能不能混用
git 的 remote 协议基本就两种：HTTPS 和 SSH。它们各自的凭据管理机制完全不同，这是所有方案选型的地基。我经常用一张表来对照：
| 路线 | 认证凭据 | 凭据存储方式 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|---|---|
| HTTPS | 用户名 + 个人访问令牌（Token） | 靠 credential helper 管理 | 443 端口一般不会被防火墙拦，适配企业代理 | 首次需要认证，Token 会过期需要续期 | 公司内网、需要走 HTTP 代理的环境 |
| SSH | SSH 密钥对 | 私钥存本地文件，公钥放服务器 | 配置好后无需反复认证，长期稳定 | 需要 22 端口可达，首次配置复杂度稍高 | 个人长期开发机、开源项目贡献 |
有一个很重要的结论：HTTPS 和 SSH 并不互斥。同一台机器上，可以一部分仓库走 HTTPS、一部分走 SSH，两套凭据互不干扰。我自己长期以来的组合就是 GitHub 走 SSH、公司 GitLab 走 HTTPS，偶尔 Gitee 也走 HTTPS。两套体系对应的配置文件不同、存储位置不同，所以它们天然能共存。
但如果你有一种“所有平台都走 HTTPS”或“所有平台都走 SSH”的执念，也没问题，只要把每种路线下面的细节处理好就行。接下来两章，我分别把 HTTPS 和 SSH 两条路线展开讲。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. HTTPS路线：让每个平台各用各的凭据
2.1 第一步：检查并修正credential.helper，别让store拖后腿
HTTPS 场景下几乎所有凭据问题，第一站都是检查 credential.helper 到底配了什么。很多人在网上随手抄过 git config --global credential.helper store，或者在 IDE 里被弹窗提示“记住密码”后默默点过确定，helper 就悄悄变成 store 了。store 不是不能用，是在多平台场景下隐患极大：明文存储不说，多个 host 的凭据全写在同一个文件里，一旦 key 拼错，很容易互相覆盖。
先看看你机器上现存的配置：
bash复制git config --global --list | grep credential
正常情况应该看到 helper 指向一个安全存储助手。Windows 上 Git for Windows 默认是 manager，macOS 上是 osxkeychain，Linux 要根据发行版而定。如果看到 store 或者 cache，建议立刻改成安全型的 manager：
bash复制git config --global credential.helper manager
Linux 上如果没有装 git-credential-manager，可以用系统自带的 libsecret 之类的 helper；实在不行用 cache 临时兜底也强过 store。这一步做完，后续所有 HTTPS 凭据都会进系统安全存储，既不容易被意外读取，也不会出现“一个文件里好几串钥匙互相打架”的问题。
2.2 第二步：remote URL带用户名，从源头区分账号
在 HTTPS 方案里，想要同一台机器上多账号共存，最稳定可靠的手段就是在 remote URL 里显式带上用户名。这一招能解决我在 1.2 里说的 username 为空问题。
假设你原本的 remote 是这样的：
bash复制git remote -v
origin https://github.com/alice/myproject.git (fetch)
origin https://github.com/alice/myproject.git (push)
把它改成带用户名形式：
bash复制git remote set-url origin https://alice@github.com/alice/myproject.git
这样改完，git 在向 helper 索要凭据时，username 字段会是 alice，而不是空。即使你同时使用多个 GitHub 账号，helper 也能把 alice 和 bob 的凭据区分开。
另一个仓库可以同样处理：
bash复制git remote set-url origin https://bob@github.com/bob/another.git
两个仓库的 URL 里用户名不同，在 helper 眼里就是两个完全独立的 key，谁也不会覆盖谁。这是我目前已知的 HTTPS 多账号共存最简单、最不容易出错的姿势。缺点是你的 remote URL 会变长一点，但对于“能稳定区分凭据”这个目标来说，完全值得。
2.3 第三步：用token完成首次认证，并验证凭据保存位置
现在主流代码平台基本都禁止用裸密码走 HTTPS，统一要求 Personal Access Token。GitHub 在 Settings -> Developer settings -> Personal access tokens 里创建，勾选 repo、workflow 等必要权限；GitLab 在 Preferences -> Access Tokens；Gitee 在设置 -> 安全设置 -> 私人令牌。
拿到 token 之后，对带用户名的仓库执行一次 push。弹出来的登录窗口里，用户名填平台账号名，密码框粘贴 token 本身，不是填账号密码。很多新手在这卡住，搞不清楚密码框到底该填什么；记住一条铁律：HTTPS 下密码框永远填 token，填账号密码基本都是认证失败。
认证通过后，凭据会被写入系统安全存储。Windows 上你可以打开“控制面板 -> 凭据管理器”，看到类似 git:https://github.com 的条目，里面保存着你刚才的凭据。macOS 则在“钥匙串访问”里搜 git。看到对应条目，就说明 helper 已经开始正常工作了，以后这个仓库 push/pull 都不需要再输一次。
需要注意的是 token 有有效期，一般在几周到一年之间。过期后 git 会再次弹出认证框，重新去平台后台生成一个新 token，替换掉旧凭据即可，不需要改动任何仓库配置。
2.4 HTTPS场景的避坑配置：按host分helper、按需开useHttpPath
HTTPS 路线的几个进阶配置，很多人不知道，但确实能解决很多奇怪问题。
第一，按 host 指定 helper。Git 支持给不同 host 单独配置 credential.helper。比如 GitHub 用 manager 做长期安全存储，公司 GitLab 因为安全策略不让存凭据，就可以给它单独配 cache：
bash复制git config --global credential.https://github.com.helper manager
git config --global credential.https://gitlab.company.com.helper cache
这样每个 host 走自己独立的 helper 逻辑，互不干扰。
第二，用 credential.https://github.com.username 指定用户名。如果你不想改 remote URL，可以在全局配置里给特定 host 指定用户名：
bash复制git config --global credential.https://github.com.username alice
这样 git 在请求 github.com 的凭据时，username 会直接用 alice，效果和 URL 带用户名类似。
第三，按需开启 credential.useHttpPath。如果同一个 host（比如同一个 GitLab 实例）上，不同项目由不同账号维护，可以局部开启这个配置，让凭据与仓库完整路径绑定，而不是只绑定 host。代价是每个仓库首次都要重新认证一次，所以建议只在你真正需要的仓库里开，不要全局开。
3. SSH路线：一套config管理所有平台的key
3.1 默认SSH配置在多平台场景一定会翻车
SSH 和 HTTPS 的凭据机制完全不一样。SSH 是客户端用私钥签名，服务器用公钥验证。你把公钥添加到 GitHub、GitLab、Gitee，客户端连过去时，服务器验证签名通过，就认为你是那个账号。
听上去很简单，但多平台场景有个大坑：ssh 连接所有 host 时，默认只尝试 ~/.ssh/id_rsa 或者 ~/.ssh/id_ed25519 这一把默认 key。当你同时使用 GitHub、公司 GitLab、Gitee 三个平台，每个平台都需要一把不同的公钥时，ssh 根本不知道“连 github.com 该用哪把、连 gitlab.company.com 该用哪把”。
结果就是经典的 Permission denied (publickey)。这个问题和 HTTPS 凭据覆盖不是一种机制，但造成的体验同样让人抓狂：GitHub 能连、公司 GitLab 连不上，或者反过来。解决方案的核心思路就是：每个平台一把独立 key，然后用 ~/.ssh/config 把 host 和 key 文件绑定起来。
3.2 为每个平台生成独立key，私钥公钥各司其职
先为每个平台生成独立的 key。建议使用 ed25519 算法，比传统的 RSA 短、快、安全性也足够。命令如下，以 alice 为例：
bash复制ssh-keygen -t ed25519 -C "alice@example.com" -f ~/.ssh/github_ed25519
ssh-keygen -t ed25519 -C "alice@company.com" -f ~/.ssh/gitlab_company_ed25519
ssh-keygen -t ed25519 -C "alice@gitee.com" -f ~/.ssh/gitee_ed25519
每个命令执行时，ssh-keygen 会问你要不要给 key 设置 passphrase。我强烈建议加一个 passphrase，再配合 ssh-agent 使用，这样私钥文件即使被人拷走，也没法直接用来认证。如果图省事回车跳过，私钥就是明文文件，风险会高很多。
生成的 ~/.ssh/ 目录下会多出六个文件：三个私钥（github_ed25519、gitlab_company_ed25519、gitee_ed25519）和三个对应的 .pub 公钥文件。公钥是用来贴到平台上作验证的，私钥绝对不要外传。-C 参数只是备注，方便你在平台后台一眼认出是哪台机器、哪个账号的 key。
3.3 写一份可用的~/.ssh/config，让host和key一一对应
接下来在 ~/.ssh/ 目录下新建或编辑 config 文件（Windows 路径是 C:\Users\你的用户名\.ssh\config，没有就新建）。模板如下：
code复制# 个人 GitHub
Host github.com
HostName github.com
User git
IdentityFile ~/.ssh/github_ed25519
IdentitiesOnly yes
# 公司 GitLab
Host gitlab.company.com
HostName gitlab.company.com
User git
IdentityFile ~/.ssh/gitlab_company_ed