必须清空全局 user.name 和 user.email，否则所有仓库默认使用该配置，易导致提交身份混淆或安全审计告警；需为每个仓库单独配置；生成 ssh 密钥须指定文件名避免覆盖，推荐 ed25519 算法；~/.ssh/config 中 host 应设别名（如 github-personal）而非直接写域名，克隆和 remote 均需用别名；ssh -t 是定位 ssh 问题的关键命令。
为什么全局 user.name 和 user.email 必须清掉
因为 Git 提交时的作者信息，会优先从全局配置读取；一旦设了全局值，所有仓库都默认用它，哪怕你为每个项目单独配了 user.name，只要某次忘记配、或 clone 后没及时设，就会误推成公司账号提交到个人仓库（或反过来），轻则被同事问“这代码谁写的”，重则触发企业安全审计告警。
- 执行
git config --global --unset user.name和git config --global --unset user.email - 验证是否清空：
git config --global --list，输出里不应再出现这两项 - 后续每个仓库都得自己运行
git config user.name "xxx"和git config user.email "xxx"
生成密钥时别用默认名，id_rsa 是最大陷阱
Windows 下 Git Bash 默认只认 ~/.ssh/id_rsa 或 ~/.ssh/id_ed25519；如果你为 GitHub 生成了 id_rsa，再为 Gitee 也生成一次，默认会覆盖——结果就是两个平台共用一把钥匙，但服务器只认各自绑定的公钥，必然有一个连不上。
- 务必用
-f指定文件名，例如：ssh-keygen -t ed25519 -C "me@github.com" -f ~/.ssh/id_ed25519_github - 推荐统一用
ed25519算法（比rsa更快更安全），避免混用导致某些旧 GitLab 实例不兼容 - 密码（passphrase）可跳过（连续回车），但若在共享电脑上，建议设一个
~/.ssh/config 里 Host 别名不能直接写域名
很多人照抄教程写 Host github.com，以为这样就能让 git@github.com:xxx/yyy.git 自动走对应密钥——错了。SSH 客户端匹配的是 URL 中 @ 后面的部分，而 git@github.com 的主机名确实是 github.com，但问题在于：如果你有两个 GitHub 账号，它们都指向同一个域名，光靠 Host github.com 无法区分路由。
- 正确做法是定义不同别名，比如：
Host github-personal和Host github-work - 然后在
config中分别指定HostName github.com和对应IdentityFile - 克隆时必须用别名：
git clone git@github-personal:me/repo.git，而不是原始域名 - 已有仓库可改 remote：
git remote set-url origin git@github-work:org/project.git
测试连接失败？先看 ssh -T 报什么错
ssh -T git@github-personal 这类命令不是“走个过场”，它是唯一能快速定位 SSH 层问题的手段。常见错误和对应动作：
-
Permission denied (publickey)：私钥没加进 agent，或config里IdentityFile路径写错（Windows 下注意斜杠方向，推荐用正斜杠/c/Users/xxx/.ssh/xxx） -
Could not resolve hostname github-personal：说明config文件没生效，检查文件是否真在~/.ssh/config（无后缀！不是config.txt），且权限是 600（chmod 600 ~/.ssh/config） - 连得上但提示 “You've successfully authenticated, but GitHub does not provide shell access”：恭喜，SSH 层通了，问题一定出在 Git 用户名/邮箱配置，不是密钥
真正麻烦的永远不是生成几对密钥，而是 config 文件里一个字母写错、路径少个波浪号、或者记事本偷偷加了 BOM 头——这些细节卡住的人，比不会命令的还多。
