博客踩坑与重生：解决无提示错误ERR_INVALID_URL

发表于 2025-05-11 Waline：本文字数： 18k 阅读时长 ≈ 16 分钟

上一篇文章发出来太艰难了，hexo更新后对url的要求变得极其严格。导致hexo g时出现了ERR_INVALID_URL。

而且！！有时候它会不告诉你报错内容在哪里！！极其恶心，今天花了两个小时解决这个问题，全程和gemini讨论，最终解决。实在应该记录一下，要不然之后又忘了怎么解决了。本人经过两个小时的摧残，已经几近爆炸，因此下文全篇由和我对话，帮我解决此问题的的Gemini记录。

不想看本人心路历程直接看解决方案的跳到解决方案。

心路历程

Hexo 博客踩坑与重生：从 ECONNREFUSED 到 ERR_INVALID_URL 再到 Git Submodule 疑云的完整排查实录

大家好，我是晴雀。最近在折腾我的 Hexo 博客时，遇到了一连串棘手的问题，一度让我非常头疼。从 npm 安装时的网络连接被拒，到生成静态文件时的无效 URL 错误，再到部署阶段的 Git 子模块迷局，每一个都堪称拦路虎。不过，经过一番系统的排查和不懈的努力，这些问题最终都得到了解决。我把整个过程详细记录下来，希望能给遇到类似问题的朋友们提供一些借鉴和思路。

问题一：npm 安装 Hexo 失败 - `ECONNREFUSED`

一切的开始，是我尝试安装 Hexo 命令行工具。当我信心满满地敲下 npm i hexo 时，终端却无情地抛出了错误：

npm i hexo
npm ERR! code ECONNREFUSED
npm ERR! syscall connect
npm ERR! errno ECONNREFUSED
npm ERR! FetchError: request to [https://registry.npmmirror.com/hexo](https://registry.npmmirror.com/hexo) failed, reason: connect ECONNREFUSED 127.0.0.1:12334
npm ERR!      at ClientRequest.<anonymous> (C:\Users\ThinkPad\AppData\Roaming\nvm\v21.7.3\node_modules\npm\node_modules\minipass-fetch\lib\index.js:130:14)
npm ERR!      at ClientRequest.emit (node:events:519:28)
npm ERR!      at _destroy (node:_http_client:880:13)
npm ERR!      at onSocketNT (node:_http_client:900:5)
npm ERR!      at process.processTicksAndRejections (node:internal/process/task_queues:83:21)
npm ERR!  FetchError: request to [https://registry.npmmirror.com/hexo](https://registry.npmmirror.com/hexo) failed, reason: connect ECONNREFUSED 127.0.0.1:12334
npm ERR!      at ClientRequest.<anonymous> (C:\Users\ThinkPad\AppData\Roaming\nvm\v21.7.3\node_modules\npm\node_modules\minipass-fetch\lib\index.js:130:14)
npm ERR!      at ClientRequest.emit (node:events:519:28)
npm ERR!      at _destroy (node:_http_client:880:13)
npm ERR!      at onSocketNT (node:_http_client:900:5)
npm ERR!      at process.processTicksAndRejections (node:internal/process/task_queues:83:21) {
npm ERR!    code: 'ECONNREFUSED',
npm ERR!    errno: 'ECONNREFUSED',
npm ERR!    syscall: 'connect',
npm ERR!    address: '127.0.0.1',
npm ERR!    port: 12334,
npm ERR!    type: 'system',
npm ERR!    requiredBy: '.'
npm ERR! }
npm ERR!
npm ERR! If you are behind a proxy, please make sure that the
npm ERR! 'proxy' config is set properly.  See: 'npm help config'

npm ERR! A complete log of this run can be found in: C:\Users\ThinkPad\AppData\Local\npm-cache\_logs\2025-05-11T04_27_04_804Z-debug-0.log

错误信息非常明确地指向了 127.0.0.1:12334，并且提到了 registry.npmmirror.com (淘宝 NPM 镜像)。这说明 npm 试图通过一个本地代理去访问镜像，但连接被拒绝了。我想起来之前确实调整过代理设置。

解决方案：清除 npm 代理配置

根据AI助手的建议，我执行了以下步骤：

查看当前的 npm 代理设置：

1 2	npm config get proxy npm config get https-proxy

如果返回了代理地址，则清除它们：
1
2
npm config delete proxy
npm config delete https-proxy
我还检查了系统环境变量 HTTP_PROXY 和 HTTPS_PROXY（在 Windows 中使用 echo %HTTP_PROXY% 和 echo %HTTPS_PROXY% 查看，或通过系统属性的环境变量设置界面修改），以及用户目录下的 .npmrc 文件 (C:\Users\你的用户名\.npmrc)，确保没有残留的代理配置。

清除了这些配置后，npm i hexo 终于可以顺利执行了。第一个问题解决！

问题二：`hexo g -d` 失败 - `ERR_INVALID_URL`

本以为可以顺利生成和部署了，没想到运行 hexo g -d (即 hexo generate -d) 时，又遇到了新的错误：

PS E:\Geek\code\blog-source-main\blog-source-main> hexo g -d
INFO  Validating config
INFO  index2 generators:
INFO
(node:20092) [DEP0040] DeprecationWarning: The `punycode` module is deprecated. Please use a userland alternative instead.
(Use `node --trace-deprecation ...` to show where the warning was created)
INFO  ==================================
  ███╗   ██╗███████╗██╗  ██╗████████╗
  ████╗  ██║██╔════╝╚██╗██╔╝╚══██╔══╝
  ██╔██╗ ██║█████╗    ╚███╔╝    ██║
  ██║╚██╗██║██╔══╝    ██╔██╗    ██║
  ██║ ╚████║███████╗██╔╝ ██╗    ██║
  ╚═╝  ╚═══╝╚══════╝╚═╝  ╚═╝    ╚═╝
========================================
NexT version 8.12.2
Documentation: [https://theme-next.js.org](https://theme-next.js.org)
========================================
INFO  Start processing
FATAL Something's wrong. Maybe you can find the solution here: [https://hexo.io/docs/troubleshooting.html](https://hexo.io/docs/troubleshooting.html)
TypeError [ERR_INVALID_URL]: Invalid URL
    at Url.parse (node:url:416:17)
    at urlParse (node:url:141:13)
    at E:\Geek\code\blog-source-main\blog-source-main\themes\next\scripts\filters\post.js:24:20
    at [Symbol.replace] (<anonymous>)
    at String.replace (<anonymous>)
    # ... (省略部分堆栈信息) ...

这次的错误是 TypeError [ERR_INVALID_URL]: Invalid URL，并且指向了我的 NexT 主题（版本 8.12.2）中的一个脚本 themes\next\scripts\filters\post.js 的第 24 行。

初步诊断是博客的全局配置 _config.yml 中的 url 字段，或者主题配置文件、文章内容中存在不合法的 URL。我检查了这些地方，特别是 _config.yml 中的 url 确保是完整的 https://... 格式，但问题依旧。

深入排查：使用 `console.log` 大法

为了定位 post.js 中到底是哪个 URL 出了问题，我们决定修改这个脚本，加入日志打印。我将当时的 post.js (位于 themes/next/scripts/filters/post.js) 内容提供给了AI助手，它帮我改造了脚本，加入了详细的 console.log 语句。以下是其中一个关键的调试版本（最终版，包含了非常详细的日志点）：

/* global hexo */

'use strict';

hexo.extend.filter.register('after_post_render', data => {
  // --- 日志打印开始 (第0处：确认filter执行) ---
  // 尝试获取文章标题或路径用于日志，data.source 是源 .md 文件路径, data.path 是输出的 HTML 路径
  const postIdentifier = data.source || data.path || (data.title ? `文章标题: ${data.title}` : '未知文章');
  console.log(`[DEBUG] post.js: Filter 'after_post_render' 被调用，处理: ${postIdentifier}`);
  // --- 日志打印结束 ---

  const { config } = hexo; // Hexo 主配置
  const theme = hexo.theme.config; // NexT 主题配置

  // --- 日志打印开始 (检查主题配置的实际值) ---
  console.log(`[DEBUG] post.js: 读取到的主题配置 - theme.exturl 的值: ${JSON.stringify(theme.exturl)}`);
  console.log(`[DEBUG] post.js: 读取到的主题配置 - theme.lazyload 的值: ${JSON.stringify(theme.lazyload)}`);
  // --- 日志打印结束 ---

  if (!theme.exturl && !theme.lazyload) {
    // --- 日志打印开始 ---
    console.log('[DEBUG] post.js: 条件 (!theme.exturl && !theme.lazyload) 为真，脚本提前返回。');
    // --- 日志打印结束 ---
    return;
  }

  if (theme.lazyload) {
    // --- 日志打印开始 ---
    console.log('[DEBUG] post.js: 检测到 theme.lazyload 为真，准备处理图片懒加载。');
    // --- 日志打印结束 ---
    data.content = data.content.replace(/(<img[^>]*) src=/img, '$1 data-src=');
    console.log('[DEBUG] post.js: 图片懒加载处理完成。');
  }

  if (theme.exturl) {
    // --- 日志打印开始 ---
    console.log('[DEBUG] post.js: 检测到 theme.exturl 为真，进入外部链接处理模块。');
    // --- 日志打印结束 ---
    const url = require('url');

    console.log(`[DEBUG] post.js: (exturl) 正在处理文章: ${postIdentifier}`);
    console.log('[DEBUG] post.js: (exturl) 准备解析 config.url (主配置)。值为:', JSON.stringify(config.url));

    let siteHost;
    try {
      siteHost = url.parse(config.url).hostname || config.url;
      console.log('[DEBUG] post.js: (exturl) 成功解析 config.url。得到的 siteHost:', JSON.stringify(siteHost));
    } catch (e) {
      console.error('[DEBUG] post.js: (exturl) 解析 config.url (主配置) 时发生致命错误! config.url 的值是:', JSON.stringify(config.url));
      console.error('[DEBUG] post.js: (exturl) 错误详情:', e);
      throw e; // 重新抛出错误，让 Hexo 停止
    }

    data.content = data.content.replace(/<a[^>]* href="([^"]+)"[^>]*>([^<]+)<\/a>/img, (match, href, html) => {
      if (!href) {
        console.log(`[DEBUG] post.js: (exturl) 在文章 "${postIdentifier}" 中发现一个空的 href 属性，跳过处理。原始匹配 (前100字符):`, match.substring(0, 100) + '...');
        return match;
      }

      console.log(`[DEBUG] post.js: (exturl) 在文章 "${postIdentifier}" 中，准备解析链接的 href。值为:`, JSON.stringify(href));

      let link;
      try {
        link = url.parse(href);
      } catch (e) {
        console.error(`[DEBUG] post.js: (exturl) 在文章 "${postIdentifier}" 中，解析 href 时发生致命错误! href 的值是:`, JSON.stringify(href));
        console.error('[DEBUG] post.js: (exturl) 错误详情:', e);
        throw e; // 重新抛出错误
      }

      if (!link.protocol || link.hostname === siteHost) {
        return match;
      }

      return `<span class="exturl" data-url="${Buffer.from(href).toString('base64')}">${html}<i class="fa fa-external-link-alt"></i></span>`;
    });
    // --- 日志打印开始 ---
    console.log('[DEBUG] post.js: (exturl) 外部链接处理模块执行完毕。');
    // --- 日志打印结束 ---
  } else {
    // --- 日志打印开始 ---
    console.log('[DEBUG] post.js: 条件 (theme.exturl) 为假，跳过外部链接处理模块。');
    // --- 日志打印结束 ---
  }
  console.log(`[DEBUG] post.js: Filter 'after_post_render' 执行完毕，针对: ${postIdentifier}`);
}, 0);

（注：实际调试中，我经历了日志未显示、发现 Hexo 加载了 post - 副本.js 文件名问题并修正、再到最终版详细日志的采用的过程。上面的代码是最终帮助定位问题的版本。）

转机：GitHub Codespaces 的纯净环境

在我本地反复尝试，甚至回档了之前在 GitHub 上能正常运行的备份，都无法解决问题，也无法让日志在本地正确输出时，我几乎要放弃了。AI助手建议我尝试在 GitHub Codespaces 这样的纯净环境中运行。我抱着试一试的心态，在 Codespaces 里打开了我的“老备份”项目，清除了 node_modules 和 package-lock.json，重新 npm install，并将上面带有最详细日志的 post.js 文件放到了正确的位置 (themes/next/scripts/filters/post.js)，同时确认了主题配置文件 themes/next/_config.yml 中的 exturl 设置为 true。然后运行 hexo clean && hexo g。

奇迹发生了！这次，控制台终于打印出了我们期待已久的 [DEBUG] 日志！

定位问题URL

大量的日志输出（部分示例如下，实际日志非常长，遍历了所有文章），最终将问题指向了特定的文章和其中的链接：

INFO  Start processing
[DEBUG] post.js: Filter 'after_post_render' 被调用，处理: _posts/2022流水账.md
[DEBUG] post.js: 读取到的主题配置 - theme.exturl 的值: true
[DEBUG] post.js: 读取到的主题配置 - theme.lazyload 的值: true
[DEBUG] post.js: 检测到 theme.lazyload 为真，准备处理图片懒加载。
[DEBUG] post.js: 图片懒加载处理完成。
[DEBUG] post.js: 检测到 theme.exturl 为真，进入外部链接处理模块。
[DEBUG] post.js: (exturl) 正在处理文章: _posts/2022流水账.md
[DEBUG] post.js: (exturl) 准备解析 config.url (主配置)。值为: "[https://blog.nbplus.eu.org](https://blog.nbplus.eu.org)"
[DEBUG] post.js: (exturl) 成功解析 config.url。得到的 siteHost: "blog.nbplus.eu.org"
[DEBUG] post.js: (exturl) 外部链接处理模块执行完毕。
[DEBUG] post.js: Filter 'after_post_render' 执行完毕，针对: _posts/2022流水账.md
# ... 大量其他文章的正常处理日志 ...
[DEBUG] post.js: Filter 'after_post_render' 被调用，处理: _posts/vercel的DNS服务器疑似出现故障.md
# ... (相关日志) ...
[DEBUG] post.js: (exturl) 在文章 "_posts/vercel的DNS服务器疑似出现故障.md" 中，准备解析链接的 href。值为: "[http://www.hehysh.eu.org](http://www.hehysh.eu.org)………"
[DEBUG] post.js: (exturl) 在文章 "_posts/vercel的DNS服务器疑似出现故障.md" 中，解析 href 时发生致命错误! href 的值是: "[http://www.hehysh.eu.org](http://www.hehysh.eu.org)………"
[DEBUG] post.js: (exturl) 错误详情: TypeError [ERR_INVALID_URL]: Invalid URL
    # ... (错误堆栈) ...
  code: 'ERR_INVALID_URL',
  input: '[http://www.hehysh.eu.org](http://www.hehysh.eu.org)………'
}
# ... 可能还有其他文章的处理，直到遇到下一个致命错误或 Hexo 决定停止 ...
[DEBUG] post.js: Filter 'after_post_render' 被调用，处理: _posts/添加开往-友链接力在你的博客.md
# ... (相关日志) ...
[DEBUG] post.js: (exturl) 在文章 "_posts/添加开往-友链接力在你的博客.md" 中，准备解析链接的 href。值为: "[https://travellings.link](https://travellings.link)），加入您的顶栏导航或侧栏导航中，便于访客看到并点击："
[DEBUG] post.js: (exturl) 在文章 "_posts/添加开往-友链接力在你的博客.md" 中，解析 href 时发生致命错误! href 的值是: "[https://travellings.link](https://travellings.link)），加入您的顶栏导航或侧栏导航中，便于访客看到并点击："
[DEBUG] post.js: (exturl) 错误详情: TypeError [ERR_INVALID_URL]: Invalid URL
    # ... (错误堆栈) ...
  code: 'ERR_INVALID_URL',
  input: '[https://travellings.link](https://travellings.link)），加入您的顶栏导航或侧栏导航中，便于访客看到并点击：'
}
# ... 以及最终的 FATAL ERROR ...
FATAL Something's wrong. Maybe you can find the solution here: [https://hexo.io/docs/troubleshooting.html](https://hexo.io/docs/troubleshooting.html)
TypeError [ERR_INVALID_URL]: Invalid URL
    # ... (错误堆栈，指向 post.js 中 url.parse(href) 的地方) ...

从这些日志中，我们明确找到了两个（或更多）有问题的链接：

在 _posts/vercel的DNS服务器疑似出现故障.md 中，链接 http://www.hehysh.eu.org……… 末尾的多个点是无效的。
在 _posts/添加开往-友链接力在你的博客.md 中，链接 https://travellings.link），加入您的顶栏导航或侧栏导航中，便于访客看到并点击： 在有效域名后包含了中文括号和文字，这也是无效的。
（在完整的日志分析中还发现一个 _posts/next主题使用Gemini进行ai文章总结.md 中的链接也包含了未编码的中文和特殊字符，同样可疑）。

解决方案：修正文章中的无效链接

我立刻打开这些 Markdown 文件 (source/_posts/目录下对应的文件)，找到了这些错误的链接并进行了修正：

对于 http://www.hehysh.eu.org………，我将其修正为预期的正确地址（例如 http://www.hehysh.eu.org/）。
对于 https://travellings.link），...，我将 href 的值修正为 https://travellings.link，并将多余的描述文字放到了 Markdown 链接的显示文本部分或链接之外。例如，将 [文本](URL和多余文字) 修改为 [文本](URL) 多余文字。

修正这些链接后，再次运行 hexo clean && hexo g。
成功了！ hexo generate 命令终于顺利完成，没有再报 ERR_INVALID_URL 错误！

问题三：`hexo d` 部署失败 - Git Submodule 问题

正当我以为大功告成，准备部署 hexo d 时，新的拦路虎又出现了：

fatal: in unpopulated submodule '.deploy_git'
FATAL Something's wrong. Maybe you can find the solution here: [https://hexo.io/docs/troubleshooting.html](https://hexo.io/docs/troubleshooting.html)
Error: Spawn failed
    at ChildProcess.<anonymous> (/workspaces/blog-source/node_modules/hexo-util/lib/spawn.js:51:21)
    at ChildProcess.emit (node:events:524:28)
    at ChildProcess._handle.onexit (node:internal/child_process:293:12)

这个错误 fatal: in unpopulated submodule '.deploy_git' 表明 .deploy_git 目录被视作一个未初始化的 Git 子模块。

我尝试了 git submodule init：

1 2	@hehysh ➜ /workspaces/blog-source (main) $ git submodule init fatal: No url found for submodule path '.deploy_git' in .gitmodules

结果又报了 No url found for submodule path '.deploy_git' in .gitmodules 的错误，说明 .gitmodules 文件中没有这个子模块的 URL 配置。

AI助手解释说，Hexo 的 hexo-deployer-git 插件通常是将 .deploy_git 作为一个独立的 Git 仓库（克隆自你的部署目标仓库）来管理的，而不是作为博客源码仓库的一个子模块。我遇到的情况很可能是 .deploy_git 被错误地添加为了主项目的子模块引用。

解决方案：移除错误的子模块引用并让 Hexo重新管理部署目录

我按照指示执行了以下步骤：

从主项目的 Git 索引中移除 .deploy_git 的子模块引用（在项目根目录 /workspaces/blog-source 执行）：

1	git rm --cached .deploy_git

或者更彻底地：

1
2
3

git submodule deinit -f .deploy_git # 强制反初始化
git rm -f .deploy_git               # 从工作区和索引中移除
rm -rf .git/modules/.deploy_git     # 删除子模块的 .git 目录数据（如果存在）

然后，如果存在 .gitmodules 文件并且里面有 .deploy_git 的内容，也需要手动删除那部分。

将 .deploy_git/ 添加到主项目的 .gitignore 文件中，以防止将来被错误跟踪。
.gitignore 文件内容示例：
1
2
3
4
5
node_modules/
public/
.deploy_git/
db.json
# 其他需要忽略的文件或文件夹

提交这些更改到你的主博客仓库：

1 2	git add .gitignore .gitmodules # .gitmodules 可能已被删除或修改 git commit -m "Remove stale .deploy_git submodule reference and update .gitignore"

彻底删除本地的 .deploy_git 目录（如果还存在的话）：
1
rm -rf .deploy_git

确保 _config.yml 中的部署配置正确：
检查主 _config.yml 文件中的 deploy 部分，例如：

deploy:
  type: git
  repo: git@github.com:YOUR_USERNAME/YOUR_GITHUB_PAGES_REPO.git # 替换成你的仓库地址
  branch: main # 或者 gh-pages

重新部署：

1 2	hexo clean hexo deploy -g # -g 参数会先执行 generate

这一次，部署过程非常顺利！所有的文件都成功推送到了我的 GitHub Pages 仓库。

总结与感悟

这次漫长的排错过程，让我深刻体会到了以下几点：

环境的重要性： 本地环境的复杂性（代理、缓存、文件占用、Node版本）确实可能导致很多难以预料的问题。适时切换到纯净环境（如 Codespaces）进行测试，可以帮助快速排除环境因素。
日志是王道： console.log 虽然简单，但在定位 JavaScript 相关问题时非常有效。关键在于把日志加到正确的位置，并仔细分析输出。
理解工具原理： 对 Hexo 的工作流程、插件（如 hexo-deployer-git）的运作方式以及相关技术（如 Git 子模块）有基本了解，能帮助更快地诊断问题。
备份和版本控制： 幸好我有之前的备份，虽然它在新环境下也出了问题，但至少提供了一个相对稳定的基线。Git 的版本控制也让我在尝试各种修改时有恃无恐。
善用AI和社区： 在遇到难题时，向AI助手提问，或者搜索社区的解决方案，往往能获得意想不到的帮助和启发。
耐心和细致： 排查问题就像侦探破案，需要一步步缩小范围，不放过任何细节。尤其是在错误信息不直观时，更要保持耐心。
不要忘记清理： 调试完成后，记得移除或注释掉添加的调试代码，保持项目整洁。

希望我这次的踩坑经历能为同样使用 Hexo 的朋友们提供一些帮助。如果你也遇到了类似的问题，不妨试试本文中提到的一些排查思路和方法。祝大家的博客都能顺利运行！

解决方案

也是由ai写的。

好的，这是针对“问题二：hexo g -d 失败 - ERR_INVALID_URL”的简洁明了的解决方案，采用 Markdown 格式并包含相关代码示例：

问题二：`hexo g -d` 失败 - `ERR_INVALID_URL` 的解决方案

背景：
在执行 hexo g -d (或 hexo generate) 命令时，控制台报错 TypeError [ERR_INVALID_URL]: Invalid URL，错误堆栈指向了主题文件 themes/next/scripts/filters/post.js（具体行号可能因主题版本和代码略有差异）。尽管已初步检查 Hexo 的主配置文件 (_config.yml) 和 NexT 主题的配置文件 (themes/next/_config.yml) 中的 url 等相关设置，确保其格式正确（例如，url 字段为完整的 https://yourdomain.com），但问题依旧未能解决。

核心排查与解决步骤：

利用纯净环境与详细日志定位问题源头：

切换至纯净环境：为了排除本地复杂环境的干扰，将项目迁移至如 GitHub Codespaces 这样的纯净环境中进行测试。在此环境中，需要重新 npm install 依赖。

修改 themes/next/scripts/filters/post.js 文件：在该脚本中，关键的 URL 解析通常发生在处理外部链接（exturl 功能）时，涉及到对 config.url（博客全局URL）和文章内容中每个链接的 href 属性的解析。在这些 url.parse() 调用前后添加 console.log 语句，以便打印出正被处理的 URL 值。

添加日志的核心思路（仅为示例，具体代码参照实际调试时使用的版本）：

// 在 post.js 文件中找到类似处理外部链接的逻辑块
if (theme.exturl) {
  const url = require('url'); // Node.js 'url' 模块

  // 日志点1: 检查 config.url
  console.log('[DEBUG] post.js: (exturl) 准备解析 config.url (主配置)。值为:', JSON.stringify(config.url));
  let siteHost;
  try {
    siteHost = url.parse(config.url).hostname || config.url;
    console.log('[DEBUG] post.js: (exturl) 成功解析 config.url。得到的 siteHost:', JSON.stringify(siteHost));
  } catch (e) {
    console.error('[DEBUG] post.js: (exturl) 解析 config.url (主配置) 时发生致命错误!', e);
    throw e; 
  }

  data.content = data.content.replace(/<a[^>]* href="([^"]+)"[^>]*>([^<]+)<\/a>/img, (match, href, html) => {
    if (!href) {
      // console.log('[DEBUG] post.js: (exturl) 空 href，跳过'); // 可选日志
      return match;
    }

    // 日志点2: 检查文章中的 href
    // 最好同时打印出当前处理的文章名，如 data.source
    console.log(`[DEBUG] post.js: (exturl) 在文章 "${data.source}" 中，准备解析链接的 href。值为:`, JSON.stringify(href));
    let link;
    try {
      link = url.parse(href); 
    } catch (e) {
      // 日志点3: 捕获解析 href 时的错误
      console.error(`[DEBUG] post.js: (exturl) 在文章 "${data.source}" 中，解析 href 时发生致命错误! href 的值是:`, JSON.stringify(href));
      console.error('[DEBUG] post.js: (exturl) 错误详情:', e);
      throw e; // 重新抛出错误以便看到 Hexo 的原始中断
    }
    // ...后续判断是否为外部链接并处理的逻辑...
    if (!link.protocol || link.hostname === siteHost) {
      return match;
    }
    return `<span class="exturl" data-url="${Buffer.from(href).toString('base64')}">${html}<i class="fa fa-external-link-alt"></i></span>`;
  });
}

分析日志，找出问题URL及所在文章：

执行 hexo clean && hexo g 命令。
仔细查看控制台输出的 [DEBUG] post.js: 开头的日志行。当 ERR_INVALID_URL 错误发生时，它之前的日志会显示导致问题的文章名和具体的 href 值。

根据实际排查时得到的日志，发现的错误示例如下：

错误日志片段 1 (文章 _posts/vercel的DNS服务器疑似出现故障.md)：

[DEBUG] post.js: (exturl) 在文章 "_posts/vercel的DNS服务器疑似出现故障.md" 中，准备解析链接的 href。值为: "http://www.hehysh.eu.org………"
[DEBUG] post.js: (exturl) 在文章 "_posts/vercel的DNS服务器疑似出现故障.md" 中，解析 href 时发生致命错误! href 的值是: "http://www.hehysh.eu.org………"
[DEBUG] post.js: (exturl) 错误详情: TypeError [ERR_INVALID_URL]: Invalid URL
input: 'http://www.hehysh.eu.org………'

错误日志片段 2 (文章 _posts/添加开往-友链接力在你的博客.md)：

[DEBUG] post.js: (exturl) 在文章 "_posts/添加开往-友链接力在你的博客.md" 中，准备解析链接的 href。值为: "https://travellings.link），加入您的顶栏导航或侧栏导航中，便于访客看到并点击："
[DEBUG] post.js: (exturl) 在文章 "_posts/添加开往-友链接力在你的博客.md" 中，解析 href 时发生致命错误! href 的值是: "https://travellings.link），加入您的顶栏导航或侧栏导航中，便于访客看到并点击："
[DEBUG] post.js: (exturl) 错误详情: TypeError [ERR_INVALID_URL]: Invalid URL
input: 'https://travellings.link），加入您的顶栏导航或侧栏导航中，便于访客看到并点击：'

修正源 Markdown 文件中的无效URL：
- 根据日志定位到的 .md 文章文件和具体的 href 值，在文本编辑器中打开这些文章。
- 具体修正方法：
  - 对于 "http://www.hehysh.eu.org………"：问题在于 URL 末尾的多个连续点 ………。应将其修改为正确的 URL，例如 http://www.hehysh.eu.org/，或删除这些多余的点。
  - 对于 "https://travellings.link），加入您的顶栏导航或侧栏导航中，便于访客看到并点击："：问题在于有效的 URL https://travellings.link 之后，错误地包含了中文括号 ） 和其他描述性文字。应确保 href 属性的值仅为 https://travellings.link。
    - 例如，如果 Markdown 源码中错误地写成了：
      1
      [链接显示文本](https://travellings.link），加入您的顶栏导航或侧栏导航中，便于访客看到并点击：)
    - 应修正为，将描述文字移出 href 部分：
      1
      [链接显示文本](https://travellings.link)），加入您的顶栏导航或侧栏导航中，便于访客看到并点击：
      或者，根据原意调整链接文本和周围句子，确保 () 内只有纯粹的 URL。
迭代修正与验证：
- 每修正一处或几处发现的无效链接后，保存文件。
- 再次运行 hexo clean && hexo g。
- 如果错误依旧，重复步骤2和3，根据新的日志提示找出并修正下一个问题链接。这个过程可能需要重复几次，直到所有文章中的无效链接都被修正。
清理调试代码：
- 当 hexo g 命令能够成功完成，不再出现 ERR_INVALID_URL 错误后，务必将之前在 themes/next/scripts/filters/post.js 中添加的所有 console.log 调试语句移除或注释掉，以恢复脚本的原始状态并避免不必要的控制台输出。

最终结果：
通过上述系统性的日志分析和内容修正，所有导致 url.parse() 失败的无效链接均被找出并更正。随后，hexo g 命令成功执行，ERR_INVALID_URL 问题得到彻底解决。

结语

现在又是本人在写了。没想到ai已经发展到如此地步，这次成功解决问题也是多亏了Gemini。另外谷歌的Gemini最近有bug，只要到https://gemini.google/students 这个链接点击领取offer就可以不用验证edu邮箱和信用卡获得免费的google advance，不过只到今年8月30日，之后就要验证了