暮色之狐

在Obsidian中，我使用了tabs插件来显示多个页签的切换功能，这种展示方式非常直观且实用。然而，这种语法并非Markdown原生支持，因此当文章发布到Hexo平台后，无法正常展示。 以下是一个示例的tabs语法： 1234567tab: Claude Pro / Max订阅规定月费，适合高频使用者首次启动时浏览器弹窗登录推荐给日常开发使用的用户tab: API key(按量付费)用多少付多少在Anthropic Console获取Key 为了解决这个问题，我编写了一个Hexo插件。首先，在Hexo目录下创建一个名为hexo-obsidian-tabs.js的文件，然后将以下内容复制到该文件中： 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100...

1234> [!info] 这是标注的标题> 这是一个标注块。> 它支持 **Markdown**、[[内部链接|内部链接]] 和 [[插入文件|嵌入]]！> ![[Engelbart.jpg]] 然而，当这些标注内容发布到Hexo博客时，无法正常显示。虽然Hexo本身支持类似的标注语法： 1{% note class_name %} Content (md partial supported) {% endnote %} 但为了保持Obsidian的编辑体验，我们需要一个插件来解决这个问题。 解决方案在Hexo博客的scripts目录下创建hexo-obsidian-tabs.js文件，并将以下内容复制到文件中： 1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980...

由于npm的默认镜像在国内下载速度较慢，我们可以通过切换到国内镜像源来解决这个问题。 国内镜像源汇总npm官方原始镜像: https://registry.npmjs.org/ 淘宝npm镜像： http://registry.npmmirror.com 阿里云npm镜像: https://npm.aliyun.com 腾讯云npm镜像: https://mirrors.cloud.tencent.com/npm/ 华为云npm镜像: https://mirrors.huaweicloud.com/repository/npm/ 网易npm镜像: https://mirrors.163.com/npm/ 中科大开源镜像站: http://mirrors.ustc.edu.cn/ 清华大学开源镜像站: https://mirrors.tuna.tsinghua.edu.cn/ 当前使用镜像源使用命令 1npm config get registry 切换镜像源使用命令 1npm config set registry http://mirrors.cloud.tencent.co...

打开vscode 文件->首选项->设置，打开设置（快捷键：ctrl + ,） 搜索shell windows 选择默认的终端为Git Bash 重启VSCode后，新建的终端将默认使用Git Bash。

我一直将Obsidian作为日常写作的主要工具，并想要能够将双链笔记一键转换为独立博客，因此采用了 Obsidian + Hexo + GitHub Pages 的组合方案。从零开始搭建到最终稳定上线，过程中遇到了诸多挑战——链接失效、图片异常、缓存不更新、访问速度慢、路径错乱等问题层出不穷。 这篇文章完整记录从搭建到极致优化的全过程，把所有遇到的问题、解决方案、优化技巧全部整理好，既是个人复盘，也给同样走这条路的朋友一份避坑指南。 整体技术栈与搭建思路我的目标很简单： 在 Obsidian 里无感写作，支持双链、相对路径、本地图片； 一键发布到线上博客，不用手动复制粘贴、改格式； 博客托管免费、稳定，即 GitHub Pages； 速度快、体验好、SEO 友好、无冗余 bug。 最终定型方案： Obsidian（写作） → Hexo（生成静态站） → GitHub Pages（托管） → uniCloud/CDN（加速） 搭建阶段：核心问题与解决方案刚把框架搭起来时，博客根本没法直接用 ——Obsidian 原生格式和 Hexo 不兼容，各种链接、图片、路径全炸了...

前言在公司、校园网络环境中，管理员常通过DPI 深度包检测、IPS 入侵防御封锁 SSH 默认 22 端口，一旦识别 SSH 协议就会发送 RST 包强制中断连接，导致无法远程管理自己的云服务器。 本文分享一套合法、安全、无侵入的解决方案：基于stunnel将 SSH 流量伪装成 HTTPS 加密流量，走 443 通用端口，绕过绝大多数网络封锁，适配Ubuntu 服务器 + Windows 客户端，全程复制粘贴即可完成。 核心原理 网络封锁逻辑：DPI 识别 22 端口 + SSH 明文特征，主动阻断； 绕过思路：用 TLS 加密包裹 SSH 流量，伪装成 HTTPS 网站流量； 方案优势：端口 443（全网通行）、无 SSH 特征、全程加密，抗 RST 阻断。 服务端配置（Ubuntu 一键部署）安装依赖1apt update && apt install stunnel4 -y 生成 TLS 证书（自用无需申请）1234openssl req -new -days 3650 -nodes -x509 -sha256 \ -keyout /etc/stunn...

💡Tip这是Claude Code通关手册的第一篇。本系列将带你从零开始，系统掌握Claude Code的完整知识体系，从CLI命令到自动化工作流，从个人使用到团队协作。 AI发展如火如荼，你可能已经在使用各种AI编程工具。每天打开编辑器，自动补全代码、生成测试用例，或协助编写需求代码。在编辑器中与AI交互，通过不断修改完善，工作效率得到显著提升。 然而，大名鼎鼎的Claude Code安装完成后，仅呈现为一个简单的命令终端。这个看似简陋的终端工具中，却蕴藏着一套与其他工具截然不同的AI编程哲学。 今天这篇文章，我不会铺天盖地讲解其功能列表，而是带你搞清楚三件事：Claude Code的具体价值、快速安装并运行Claude Code，以及它为何能火遍全网，让人爱不释手？ Claude Code的价值Claude Code与其他AI工具不同，它开启了一个新的竞争赛道。打个比方你就会明白： 去厨房做一顿饭： Copilot 是菜谱App。搜索”番茄炒蛋”，它告诉你：番茄切块、鸡蛋打散、热油下锅、先炒蛋再炒番茄……步骤写得清清楚楚，但切菜、开火、翻炒、调味，全是自己...

GitHub Pages 提供了免费、便捷的静态网页托管服务，让我们可以轻松地将博客部署在 GitHub 上。然而，由于网络原因，国内访问 GitHub 的速度往往不尽如人意，严重影响博客的加载体验。 有没有一种既经济又能显著提升访问速度的方案呢？uniCloud 前端网页托管 就是一个不错的选择。它提供了免费的云服务空间，对于个人博客来说，资源配额完全够用，并且在国内的访问速度非常理想。 👉 uniCloud 前端网页托管官方文档 在之前的文章 从零到一键发布：Obsidian + Hexo + GitHub Pages 个人博客搭建指南 中，我们已经实现了将 Hexo 博客自动部署到 GitHub Pages。本文将在此基础上进行改造：将生成的静态网页从推送至 <用户名>.github.io 仓库，改为部署到 uniCloud 的云存储空间中，从而实现国内访问加速。 操作步骤创建 uniCloud 服务空间 访问 uniCloud Web 控制台，注册并登录账号。 点击 新建服务空间，创建一个新的云环境。 在云服务商选择中，建议选择 支付宝云 / 阿里...

在本地用 Markdown 写文章时，我们常用相对路径引用其他文章，例如： 1[Hexo永久链接最佳实践：终极方案与优化指南](./Hexo永久链接最佳实践：终极方案与优化指南.md) 但 Hexo 在生成静态页面时，会将上述语法直接转换为： 1<a href="./Hexo永久链接最佳实践：终极方案与优化指南.md" target="_blank"></a> 由于浏览器无法解析 .md 文件路径，导致超链接失效。 解决方案在 Hexo 项目根目录下创建 scripts/fix-relative-links.js 文件，并添加以下代码： 1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889909192939495969798991...

问题现象：博客搜索功能正常，但点击搜索结果后跳转链接丢失了站点域名，例如实际文章链接为 http://www.gloam.cn:4000/20260302020433.html，搜索后却指向 http://20260302020433.html，导致无法访问。 根本原因：Hexo 搜索插件在生成搜索数据时，只记录了文章的相对路径（即 permalink 配置值），没有自动补全站点的完整域名。 解决方案：修改主题中负责渲染搜索结果的 JavaScript 文件，将文章的相对路径拼接上站点的根路径（如 location.origin），生成绝对链接即可解决。 问题复现根据 Hexo永久链接最佳实践：终极方案与优化指南 对文章的url进行了优化，但是优化后通过搜索无法跳转到正确的文章。 12345实际链接:http://www.gloam.cn:4000/20260302020433.html搜索后跳转链接:http://20260302020433.html 修复指南定位搜索功能相关文件在主题目录中寻找负责搜索的脚本文件。以 hexo-theme-matery 主题为例，需要找到...

结论先行：日期方案是最佳选择经过多种方案的对比与实践，推荐使用基于文章创建时间的日期格式作为永久链接，即: 1permalink: :year:month:day:hour:minute:second.html 该方案完全依赖 Hexo 原生功能，无需额外插件；生成的 URL 简洁、无中文乱码、长度固定；只要在每篇文章的 Front-matter 中明确设置 date 字段，链接即可永久不变，彻底解决了文件名修改、中文转义等痛点，是兼顾 SEO 与稳定性的最优解。 下面详细分析各方案的优缺点，根据实际需求选择。 默认配置Hexo 生成永久链接的常规设置位于站点根目录的 _config.yml 文件中，如下所示： 12345permalink: :year:month:day:hour:minute:second.html permalink_defaults: pretty_urls: trailing_index: true # 设为 false 可移除 URL 末尾的 'index.html' trailing_html: true #...

太大的图片不仅会影响加载速度，而且会让捉襟见肘的网站流量变得更多，为此有必要在上传图片前先确认下图片的大小，如果图片太大建议先进行一下图片的压缩。 图片压缩那么如何压缩图片呢？个人使用的是一个在线的网站工具：tinypng.com，完全免费，可以批量压缩 20 张图片，最大 5MB。 该网站还提供了： API ，开发者可以调用它来为自己的产品提供图片压缩服务，但每月只能调用 500 次。 Mac 的桌面端工具 TinyPNG4Mac，开源在 GitHub，可以压缩超过 5M 的图片。 webp / avif 格式webp 和 avif 格式比起传统的 jpg 格式体积更小，也是目前非常主流的图片格式。 WebP 使用了更优的图像数据压缩算法，能带来更小的图片体积。例如微信文章里的很多图片都是 webp 格式。avif 格式压缩的更厉害，体积更小。一些主流网站使用的图片就是avif格式的。 但是这两种格式得考虑兼容性问题，读者可以去 caniuse.com 搜索各大浏览器的兼容情况。 感兴趣的同学可以参考以下博客进行了解 什么是WebP？使用WebP格式的图片提供网...