Git HTTPS 临时 Token 过期后 push 失败，需手动清除系统凭据缓存（如 macOS 的 osxkeychain 或 Windows 凭据管理器），或改用 git-credential-cache 内存缓存并设 --timeout=3600；CI/CD 中应通过平台 Secret 动态注入短效 Token，禁用明文存储与日志输出；SSH 密钥虽不过期，但常被企业策略禁止，Token 的可控生命周期才是合规关键。
Git HTTPS 临时 Token 过期后 push 失败怎么办
GitHub、GitLab 等平台对 HTTPS 方式推送强制要求使用 Personal Access Token（PAT）而非密码，而 GitHub 的默认 PAT 有效期是 30 天，但某些 CI/CD 场景或企业策略下会设为 1 小时——这会导致 git push 突然报错：remote: Support for password authentication was removed 或 fatal: Authentication failed。
这不是网络问题，也不是本地 Git 配置损坏，而是凭据缓存里的 Token 已失效。系统不会主动提示“你的 Token 过期了”，只会静默用旧值重试直到失败。
- 检查当前凭据：运行
git config --get credential.helper，若输出osxkeychain（macOS）、manager-core（Windows Git Credential Manager）或store，说明凭据被缓存过 - 手动清除旧凭据：macOS 执行
git credential reject 后输入protocol=https、host=github.com、空行；Windows 可在“Windows 凭据管理器”里删掉对应条目 - 避免反复输 Token：不要直接在命令行写
https://token@github.com/...，这种 URL 会被缓存且明文暴露在git remote -v和 shell 历史中
用 git-credential-cache 临时托管一小时 Token
如果你确实需要“一小时有效”的短生命周期 Token（比如临时接入某测试环境、审计合规要求），git-credential-cache 是比系统凭据管理器更可控的选择——它把 Token 存在内存里，超时自动丢弃，不落盘。
启用方式很简单，但要注意路径和权限：
- 先确保没启用其他 helper：
git config --unset credential.helper - 启动缓存服务（有效期单位为秒）：
git config --global credential.helper 'cache --timeout=3600' - 首次 push 时会弹出终端提示输入用户名和 Token（不是密码），输入后即缓存，后续一小时内所有
git push都复用该 Token - 超时后再次 push 会重新提示，不会静默失败；也可手动清空：
git credential reject
注意：git-credential-cache 不支持 Windows，默认只在 Linux/macOS 可用；且它不加密，仅防误泄露，不适合高敏场景。
CI/CD 中如何安全注入短时效 Token
GitHub Actions、GitLab CI 等平台常要求 Token 有效期严格控制（如 1 小时），但直接写死在 .git/config 或环境变量里容易误提交或日志泄露。
正确做法是利用平台原生机制动态注入，并限制作用域：
- GitHub Actions：优先用
${{ secrets.GITHUB_TOKEN }}（自动续期，无需设置过期），如需自定义短效 Token，应存为 Secret 并在 job 中通过env:注入，再用git remote set-url动态替换 origin：git remote set-url origin https://${{ env.TEMP_TOKEN }}@github.com/org/repo.git - GitLab CI：用
CI_JOB_TOKEN（自带 1 小时有效期），配合git push https://gitlab.com:$CI_JOB_TOKEN@${CI_SERVER_HOST}/${CI_PROJECT_PATH}.git - 禁止行为：不要用
git config --local credential.helper store写入明文文件；不要在脚本里 echo $TOKEN 到日志（哪怕加了set +x，部分 runner 仍会记录）
为什么不用 SSH 密钥替代？
SSH 密钥本身不过期，看起来能绕过 Token 过期问题——但很多企业禁用 SSH（尤其对接 SSO 的 GitLab 实例），或要求所有访问必须走 HTTPS 以便统一审计、强制 MFA、绑定 IP 白名单。
这时强行配 SSH 不仅无效，还可能触发安全告警。更关键的是：SSH 密钥 ≠ 认证代理，它不解决“临时授权”问题——你无法给一个密钥设置“仅限今天下午 2–3 点生效”。而 Token 的生命周期、scope、可撤销性都是可编程控制的。
所以别纠结“为什么不用 SSH”，先确认你的 Git 托管平台是否允许、以及所在组织的安全策略是否接受。很多时候，不是技术不能，而是策略不让。
Token 过期本身不是 bug，是设计使然；真正容易被忽略的是：缓存机制与 Token 有效期不匹配时，错误表现极其隐蔽——它不报“token expired”，只报“auth failed”，然后你花半小时查网络、查权限、查两步验证，最后发现只是 keychain 里塞了个过期字符串。
