yanhuolt Hexo https://yanhuolt.dpdns.org/ All rights reserved 2026, yanhuolt 记录一些想法、折腾和踩过的坑 yanhuolt 2026-09-28T13:30:00.000Z yanhuolt 把博客从 Astro 换成了 Hexo + Butterfly 主题。这篇记录一下现在的技术选型和几个实际的坑。

为什么是纯静态

博客的本质就是「把 Markdown 渲染成 HTML 然后分发出去」。一旦接受这个前提，动态博客（WordPress 那类，PHP + 数据库）就是明显的过度设计：

  • 要维护运行环境和数据库备份
  • 要操心安全补丁
  • 服务器挂了站点就挂了

静态站点把这些全部消掉——构建产物就是一堆 HTML 文件，扔到 CDN 上，没有后端可攻击，没有数据库可炸。

技术栈

层选型说明
生成Hexo 8中文社区成熟，主题生态大
主题Butterfly 5.7功能齐全，配置项多
托管Cloudflare Pages免费、全球 CDN、自动 HTTPS
搜索hexo-generator-searchdb构建时生成索引，无后端
评论Giscus基于 GitHub Discussions，无数据库
统计Pages Functions + KV自建，不依赖第三方

为什么不用不蒜子

中文博客做浏览量统计，默认答案通常是不蒜子（busuanzi）。但实测它的计数接口主机 events.busuanzi.ibruce.info 已经不可达——脚本能加载，数据拿不到。

所以改成自己写：一个 Cloudflare Pages Function 加一个 KV 命名空间。

1
2
3
4
5
6
7
8
9
// functions/api/views.ts 的核心逻辑
export const onRequestPost = async ({ request, env }) => {
  const { path } = await request.json();

  const current = Number(await env.VIEWS.get(path)) || 0;
  await env.VIEWS.put(path, String(current + 1));

  return Response.json({ path, views: current + 1 });
};

前端只要扫一遍页面上的计数占位符，汇总成一个请求即可。这样没有任何外部依赖，数据也在自己的账号里。

几个实际的坑

Cloudflare 绑定自定义域名时不会自动创建 DNS 记录。

这是最容易卡住的地方。域名状态会一直停在 pending，报 CNAME record not set，HTTPS 完全不可用。必须手动加一条指向 <项目名>.pages.dev 的 CNAME，而且代理（橙色云朵）必须打开。

另外，Hexo 的构建产物目录也叫 public/，和很多静态站点生成器的「静态资源目录」同名，切换框架时容易搞混。

部署流程

1
2
3
npm run server   # 本地预览，热更新
npm run build    # 生成到 public/
npm run deploy   # 推到 Cloudflare Pages

没有 CI、没有服务器、没有需要守护的进程。构建产物推上去，全球节点几分钟内就是最新的。

]]> https://yanhuolt.dpdns.org/posts/hello-hexo/ 2026-09-27T02:00:00.000Z 从零搭一个纯静态博客：Hexo 生成、Cloudflare Pages 托管、自建浏览量统计，全程不依赖任何第三方统计服务。 这个博客现在的技术栈 2026-09-28T13:30:00.000Z yanhuolt 以前想让外网访问家里的服务，路子无非两条：要么在路由器上做端口映射并暴露公网 IP，要么租一台有公网 IP 的 VPS 做反向代理。

这两种做法都有个共同的毛病——你确实在公网上开了一个入口。哪怕只转发 443，扫描器也会很快找上门。

Cloudflare Tunnel 换了思路：连接是从内网主动向外建立的，公网侧根本不存在可以扫描的入站端口。

原理

1
访客 → Cloudflare 边缘节点 →（已建立的长连接）→ cloudflared → localhost:3000

cloudflared 进程在你这台机器上跑着，启动时主动连到 Cloudflare 并保持一条隧道。外部请求到达边缘节点后，顺着这条已建立的连接回传进来。

所以：

  • 路由器上不需要开任何端口
  • 不需要公网 IP，NAT 后面就行
  • 出口流量，防火墙通常不会拦

基本用法

1
2
3
cloudflared tunnel login
cloudflared tunnel create my-blog
cloudflared tunnel route dns my-blog blog.example.com

配置文件 ~/.cloudflared/config.yml：

1
2
3
4
5
6
7
8
9
tunnel: ff19965a-1b58-45e6-91bc-6d1d2202293c
credentials-file: /home/user/.cloudflared/ff19965a-....json

ingress:
  - hostname: blog.example.com
    service: http://localhost:3000

  # 兜底规则必须放最后，否则 cloudflared 会拒绝启动
  - service: http_status:404

最后那个 http_status:404 是必需的——少了它 cloudflared 会启动失败，因为 ingress 规则要求有一个不带 hostname 的兜底项。

几个会踩的点

DNS 记录必须指向隧道。 用 tunnel route dns 加出来的记录是一条 CNAME，指向 <隧道ID>.cfargotunnel.com，而且必须保持**橙色云朵（已代理）**打开。手动改成 DNS only 就废了。

Windows 上装成服务：

1
cloudflared service install

区分「隧道」和「DNS」两套权限。 Cloudflare 的 API Token 权限粒度很细——能改 DNS 的 Token 未必能管理隧道，Account → Cloudflare Tunnel → Edit 是另一个独立权限。报 9109 的时候先怀疑这个。

和 Pages 怎么选

Cloudflare TunnelCloudflare Pages
需要常开的机器是否
适合动态服务是否（纯静态）
全球加速依赖源站原生 CDN
运维成本中几乎为零

结论很简单：静态博客用 Pages，动态服务才上 Tunnel。 让一台机器整年开着只为托管几页 Markdown，实在没必要。

不过 Tunnel 有个 Pages 替代不了的优势：本地开发环境可以挂个域名直接给别人看，改完代码刷新即生效，不用重新部署。

]]> https://yanhuolt.dpdns.org/posts/cloudflare-tunnel-notes/ 2026-09-20T06:00:00.000Z 不开放任何入站端口、不需要公网 IP，用 Tunnel 把家里的服务安全地挂到公网域名上。 Cloudflare Tunnel 把内网服务暴露出去 2026-09-27T13:30:34.127Z yanhuolt 搭这个博客的时候，我差点又掉进同一个坑里。

先是纠结静态站点生成器选哪个：Hugo 构建快、Hexo 主题多、Astro 组件化好。选定之后，又开始比较主题——看了几十个，收藏了七个。接着觉得默认样式不够「有辨识度」，准备自己写一套设计系统。

到第二天晚上我才反应过来：一篇正文都还没写。

工具链是手段，不是目的

这种事我干过不止一次。

想学摄影，先花两周研究机身镜头参数；想练字，先挑了半天笔和纸；想读点书，先折腾出一套带标签、双链、自动同步的笔记系统。等装备齐了，那股劲也过去了。

有个说法叫「生产力色情」（productivity porn）——沉迷于优化工作流程本身，享受那种「一切尽在掌握」的快感，却始终没开始真正的工作。搭工具链的反馈是即时且确定的（装好了就是装好了），而写文章的反馈是延迟且模糊的（写完了也不知道好不好）。大脑当然会选前者。

两条规矩

所以这次我给自己定了两条：

第一，工具链最多花一天。 一天之内跑不起来，就直接用最土的办法——手写 HTML 也不是不行。工具的价值在于降低摩擦，如果搭工具的过程本身成了最大的摩擦，那它就是负资产。

第二，写作和改版分开。 写正文的时候不碰样式。看着不顺眼的地方记在待办里，攒够一批再统一改。边写边调 CSS 的结果通常是文章写了一半，样式改了二十遍。

反过来想

当然也不是说折腾工具就毫无价值——每次折腾都会摸清楚一些东西：静态生成器的构建流程、CDN 的缓存规则、API Token 的权限模型，这些知识以后都用得上。

区别在于它应该是写文章的副产品，而不是写文章的替代品。

完成比完美重要。先让东西存在，再让它变好。

现在这个博客的样式说不上多精致，但至少它已经在了。这比停在草稿箱里的完美设计稿强得多。

]]> https://yanhuolt.dpdns.org/posts/toolchain-first-trap/ 2026-09-12T13:00:00.000Z 花三天搭环境、写十分钟正文——聊聊这种本末倒置，以及我给自己定的两条规矩。 关于「先把工具链搭好」这件事 2026-09-27T13:30:34.129Z