起因:
1.很久没有更新博客，今天本来打算用 VS Code 写篇新文章并推送到 GitHub 上。原本以为只需简单的“暂存-提交-推送”三连就能搞定，没想到却触发了一连串匪夷所思的报错。
2.经过一步步的排查、试错和底层逻辑剖析，我最终不仅解决了所有 Bug，还顺手重构了博客的“双分支备份工作流”。这篇文章完整记录了这次的踩坑与排雷过程，希望能给遇到同样问题的 Hexo 博主们提供一份详尽的避坑指南。

📍 阶段一：密码验证失败？旧时代的眼泪

一切的起因，源于我写完文章后，习惯性地在 VS Code 的源代码管理面板中点击了 “发布 Branch”。迎接我的不是成功的绿灯，而是一行刺眼的红字：

1
2
remote: Support for password authentication was removed on August 13, 2021.
fatal: Authentication failed for 'https://github.com/[用户名]/[仓库名].git/'

🐛 问题剖析：

这是 GitHub 在 2021 年进行安全升级留下的“坑”。GitHub 早已不支持使用账号和登录密码直接进行 Git 操作，必须使用 Personal Access Token (PAT) 或者浏览器授权登录。而我的 Git 显然还记着旧时代的密码。

🛠️ 解决过程：

排查本地凭据： 最初以为是 Windows 系统的“凭据管理器”里缓存了旧密码，但打开后发现列表里干干净净，并没有 github.com 的记录。这说明密码被 Git 的内部配置“死记硬背”下来了。

  1. 重新唤醒浏览器授权： 为了覆盖旧的无效身份，我直接使用了 VS Code 左下角自带的 “账户” 功能。
  2. 点击左下角的小人图标 -> 选择 “登录以同步设置”。
  3. 在弹出的选项中选择 GitHub。
  4. 系统成功唤起浏览器，点击绿色的 “Authorize” 完成授权。
  5. 至此，Git 的网络通信和权限问题暂时打通，但真正的硬核报错才刚刚开始。

📍 阶段二：神秘的 fatal: not a git repository 与 Hexo 的底层逻辑

授权成功后，我尝试在终端手动执行 git add .，结果又挨了一记闷棍：

1
fatal: not a git repository (or any of the parent directories): .git

🐛 问题剖析：

在这个瞬间，我猛然意识到问题的核心：我使用的博客框架是 Hexo！
在 Hexo 的工作流中，存在一个非常容易让人混淆的机制：

  1. 博客根目录（也就是我当前终端所在的文件夹）默认不是一个 Git 仓库。
  2. Hexo 在部署时，会偷偷在根目录下生成一个隐藏的 .deploy_git 文件夹，那个文件夹才是一个真正的 Git 仓库，用来存放生成好的网页代码。
  3. 所以我直接在根目录敲 Git 命令，当然会报错说找不到仓库。

🛠️ 解决思路转换：

既然是 Hexo，发布网页根本不需要手动 git add / commit。只需要使用 Hexo 专属三连：

1
2
3
hexo clean  # 清除缓存
hexo g      # 生成网页
hexo d      # 部署上天

📍 阶段三：头疼的 Error: Spawn failed

满怀希望地敲下 hexo d，万万没想到，终端吐出了一大段错误代码，最后定格在：

1
2
FATAL Something's wrong. Maybe you can find the solution here...
Error: Spawn failed

🐛 问题剖析：

Spawn failed 是 Hexo 最臭名昭著的报错之一。它的本质是：Hexo 尝试在后台调用 hexo-deployer-git 插件去推送到 GitHub 时，Git 进程卡死或崩溃了。结合前面的密码报错，极大可能是刚才网络不通畅时，导致隐藏的 .deploy_git 文件夹里的状态错乱了。

🛠️ 解决过程：

核弹级清理： 在 VS Code 的资源管理器中，直接找到并删除了 .deploy_git 文件夹。（不用担心，这只是临时生成的网页缓存，删除不影响源文件）。

测试底层连接： 为了确保 Git 有权限，在终端手动执行了一次测试：

1
git ls-remote https://github.com/[用户名]/[仓库名].git

终端成功返回了 HEAD 和 refs/heads/main 等哈希值。这证明本地和 GitHub 的网线彻底接通了！

📍 阶段四：配置文件的“地雷阵” (SSH 与 YAML)

你以为网络通了就能成功吗？并没有。删掉缓存后再次 hexo d，报错变成了找不到远程仓库。

我打开根目录下的 _config.yml 检查部署配置，发现了一个致命细节：

1
2
3
4
5
# 错误示范
deploy:
  type: git
  repository: git@github.com:[用户名]/[仓库名].git  # <--- 问题在这里
  branch: main

🐛 问题剖析：

SSH 地址的坑： repository 里写的是 git@github.com… 的 SSH 格式地址。但我刚才费劲打通和测试的，是基于浏览器的 HTTPS 授权！使用 SSH 地址会导致系统去寻找本地的 SSH 秘钥，找不到自然再次报错。
YAML 格式的傲娇： 当我把地址改成 HTTPS 后，Hexo 竟然直接无视了我的配置，提示 You should configure deployment settings in _config.yml first!。这是因为 YAML 文件对空格的要求极其苛刻，我在修改时不小心破坏了缩进（冒号后缺少空格）。

🛠️ 最终修复：

严格按照 YAML 的格式规范，重写了 deploy 部分（注意缩进和空格）：

1
2
3
4
deploy:
  type: git
  repo: https://github.com/[用户名]/[仓库名].git
  branch: main

保存文件，回到终端，最后一次屏住呼吸敲下：

1
hexo clean && hexo g && hexo d

终端里的代码疯狂滚动，最终停在了一行令人热泪盈眶的绿字：

1
INFO  Deploy done: git

至此，博客的网页代码终于成功发布到了 GitHub Pages 上！

（未完待续）