小磊哥の博客

Cloudflare 免费档一天 10 万请求够不够？用临时邮箱项目省配额实战

email@example.com (小磊哥) — Sat, 19 Sep 2026 17:10:00 +0800

结论先行

我跑临时邮箱、短链、OTP、小游戏这一串站，几乎全挂在同一个 Cloudflare 账号上。先说结论，别绕：

起步和个人项目，免费档通常够用。 真要爆，先撞的往往是 账号级 Workers 每天 10 万请求，不是「邮箱业务本身」突然吃光额度。邮件进来靠 Email Routing + Worker 处理一次；列表、读信才打 API。真正烧配额的，是前端没事就轮询、静态资源也走 Worker、以及同账号里其他站一起抢。

下面以 mail.5201616.xyz 这类基于 cloudflare_temp_email 方案的自用临时邮箱为例，先给 可跟做的部署步骤，再摊开「什么吃请求、怎么省」。数字按 2026 年常见免费档口径 写，最终以 Cloudflare 官方文档为准——他们偶尔会改表。

声明：公开开放中继有滥用风险。本文只谈 自用部署与配额，不教怎么刷、怎么对外中继滥用。

免费档关键数字（2026 口径，以官方为准）

个人项目最常盯这三块：

产品	免费档常见上限（账号级 / 日）	备注
Workers	100,000 requests/day/account	整账号共享，不是「每个 Worker 各 10 万」
KV	读约 10 万/天，写仅约 1000/天	写极少，排行榜狂写很容易顶穿
D1	读约 500 万行/天，写约 10 万行/天	适合列表、日榜、结构化查询

还有 Pages、R2、Cache 等，但对「临时邮箱 + 几个小站」来说，最先报警的通常是 Workers 请求数，其次才是 KV 写入。

记住一句：10 万是账号池。 我这边同账号还有 go / otp / air / brick 等站，配额是抢的——邮箱今天省下来，游戏接口也可能把它花掉。

临时邮箱真实架构（自用视角）

mail.5201616.xyz 这类项目，常见链路大致是：

收信：Cloudflare Email Routing 把邮件转到绑定的 Worker（或 Worker 入口），入库（常见 D1 / KV 等，视部署而定）。
前端：SPA（静态资源适合挂 Pages / CDN）。
读信：只有打开列表、点开某封、刷新收件箱时，才打后端 API（Worker）。

所以：

邮件到达 → 触发一次（或少量）Worker 处理，这是「业务必要」。
人盯着页面疯狂刷新 / 短间隔轮询 → 才是配额刺客。

Email Routing 本身把「收信入口」接到 Cloudflare 生态里，省去自建 SMTP 那一摊；但 Worker 被调用一次，就算一次请求——别幻想「邮件相关都不算」。

什么吃请求，什么相对不吃

吃配额（Workers 请求）

每次打到 Worker 的 动态请求 / API（列表、读信、鉴权、删除等）。
前端定时 轮询收件箱（哪怕返回空列表，也算）。
误把 HTML/JS/CSS 也绑到 Worker 上、每次打开页面都经 Worker 吐静态文件。

相对省

Pages / 静态资源走 CDN：打开页面本身不经过 Worker（或极少经过）。
浏览器缓存：合理 Cache-Control，别每次强制拉全量前端。
减少无意义轮询：页面隐藏、用户离开标签页时暂停。
短 TTL 的 Cache API：对「短时不变」的只读响应做边缘缓存（注意邮件内容时效，别把「新信」缓存成旧信）。

一句话：静态尽量静态，动态尽量少打、打准。

实战部署：临时邮箱上 Cloudflare

前面把「吃配额」讲清楚了；很多人缺的是 怎么从零落到能收信。下面按我这边自用站 mail.5201616.xyz 的路径写——基于开源项目 dreamhunter2333/cloudflare_temp_email（替换旧的 tempik Worker），Worker 名常见为 cloudflare_temp_email，收信靠 Email Routing catch-all → 该 Worker。

配置项、变量名以 上游 README / 官方 CLI 文档 为准；版本会变，下面命令标成示例，勿照抄未核对的键名。

0. 前置条件

Cloudflare 账号，域名已接入（例：5201616.xyz）
本机有 Node.js + 包管理器（文档常用 pnpm），并安装 Wrangler：npm i -g wrangler
准备好要用来收临时信的域名；MX 最终由 Email Routing 托管（别自己乱改成第三方 MX）

1. 拉代码并登录

# 示例
git clone https://github.com/dreamhunter2333/cloudflare_temp_email.git
cd cloudflare_temp_email
# 可选：切到最新 tag，也可用 main
# git checkout $(git describe --tags $(git rev-list --tags --max-count=1))

wrangler login

浏览器完成 Cloudflare OAuth 后，本机 Wrangler 才能建 D1 / 部署 Worker。

2. 创建 D1（必选）与 KV（按需）

项目用 D1 存地址与邮件；KV 多用于注册验证码、Telegram 等，自用不启用可跳过。

# 示例：在仓库根或文档指定目录执行（以你 clone 下来的路径为准）
wrangler d1 create temp-email-db
# 初始化表结构（路径以仓库内 db/schema.sql 为准）
wrangler d1 execute temp-email-db --file=db/schema.sql --remote

# 需要注册验证 / Telegram 时再创建，例如：
# wrangler kv namespace create DEV

创建成功后控制台会给出 database_id；后面填进 wrangler.toml 的 [[d1_databases]]。绑定名必须是 DB（上游硬编码，改名会挂）。

我这边自用实例的 D1 曾命名为类似 cf-temp-email-db——名字你自定即可，关键是 ID 与 binding 配对正确。

3. 配置 Worker 并部署

cd worker
pnpm install
cp wrangler.toml.template wrangler.toml

编辑 wrangler.toml（示例字段，值请自己生成，不要用占位密码上线）：

name = "cloudflare_temp_email"（可与线上一致，便于对照 Dashboard）
compatibility_flags = ["nodejs_compat"]（缺了常直接起不来）
[[d1_databases]]：binding = "DB"，填入刚创建的 database_name / database_id
[vars] 里至少核对：
- DOMAINS / DEFAULT_DOMAINS：你的域名，如 ["5201616.xyz"]
- JWT_SECRET：随机串，例如本机执行 openssl rand -hex 32 后填入
- 站点访问密码：PASSWORDS（可选，私有站点建议开）
- 管理台密码：ADMIN_PASSWORDS（不配则进不了 admin）
密码用本地生成，例如：openssl rand -base64 24——文章不写真实密码；生成后只放进你的 wrangler.toml / Secrets，别提交到公开仓库

部署：

# 示例
pnpm run deploy
# 或：wrangler deploy

首次可能提示创建 Workers 项目；成功后 Dashboard → Workers 能看到该 Worker，打开 Worker URL 或 /health_check 若返回 OK，后端基本通了。完整变量说明见上游文档，勿凭记忆猜键名。

前端两种常见做法（二选一或按上游当前推荐）：

Worker 带 assets：先 frontend 里 pnpm build，在 wrangler.toml 配 [assets] 指向 ../frontend/dist/（见上游「带前端的 Worker」说明），再 deploy。
前后端分离：Pages 部署前端，.env 里 VITE_API_BASE 指向 Worker URL（末尾不要 /），再绑自定义域。

我这边对外入口是 https://mail.5201616.xyz——自定义域绑到 Worker 或 Pages（看你选的部署方式）。

4. Email Routing：catch-all 进 Worker

Dashboard 路径（点选，不编造截图）：

Email → Email Routing：对目标域名启用 Email Routing（按向导验证目标邮箱等）。
确保 DNS 里 Email Routing 所需的 MX / TXT 由 Cloudflare 托管生成——不要再指到其他邮件服务。
Routing rules → 添加 Catch-all（或等价「全部未匹配地址」规则）→ Action：Send to a Worker → 选中你的 cloudflare_temp_email Worker。

这样 *@你的域名（例如 *@5201616.xyz）入站都会进 Worker 解析入库，而不是丢进某个真人邮箱。

5. 自定义域 `mail.你的域名`

Worker 方案：Workers → 你的 Worker → Settings / Domains & Routes → 添加 mail.5201616.xyz（示例）为 Custom Domain，或按文档写 routes。
Pages 方案：Pages 项目 → Custom domains 绑定同名主机。

DNS 会自动出现对应记录；MX 仍交给 Email Routing，别和「网站 A/CNAME」搞混——网站记录管网页，MX 管收信。

6. 验证收信

浏览器打开 https://mail.5201616.xyz （或你的域名），用你设置的站点密码进入（若启用了 PASSWORDS）。
在界面生成/创建一个临时地址，例如 某人@5201616.xyz。
用任意外部邮箱向该地址发一封测试信。
回到页面刷新/等待列表出现；能看到主题与正文，说明 Routing → Worker → D1 → 前端 API 整条链路通了。

若一直收不到：先查 Email Routing 是否 Enabled、catch-all 是否指向正确 Worker、域名是否在 DOMAINS 列表、以及 Workers 日志有无报错。

7. 部署完立刻想到「省配额」

默认前端若 短间隔疯狂轮询，免费档 Workers 请求会被空转吃掉。部署只是上线；省配额才是长期能玩。改 poll 间隔、页面隐藏暂停、静态与 API 分离——具体清单见下一节。

部署检查清单

wrangler login 成功，本机能操作目标账号
D1 已创建且执行过 schema.sql；wrangler.toml 里 binding = "DB" 且 ID 正确
JWT_SECRET / 站点与 admin 密码已本地生成并写入配置（未提交明文到公开 Git）
DOMAINS 含你的收信域名；Worker pnpm run deploy 成功，/health_check 正常
Email Routing 已启用；catch-all → Worker cloudflare_temp_email
自定义域（如 mail.5201616.xyz）已绑定；MX 由 Email Routing 托管
向 *@你的域名 发测试信，Web UI 能看到
轮询间隔已按后文「省配额」拉长，避免一上线就空烧请求

省配额清单（可直接改）

1. 前端拉信：间隔拉长 + 可见才 poll

默认别 5 秒一轮；自用 30～60 秒 往往够。
用 Page Visibility：document.hidden 为 true 时 暂停轮询，回到前台再拉一次。
用户点「刷新」才立刻请求；自动轮询只做兜底。

2. 静态与 API 分离

前端挂 Pages（或 R2 + 自定义域），API 才走 Worker 路由。
HTML/JS/CSS 设缓存；API 路径明确不缓存或短缓存。

3. 别拿 KV 当「狂写日榜」

KV 免费档 写大约才 1000/天。排行榜、计数器、游戏日榜这类「频繁更新」：

更适合 D1（写额度量级大得多，还好做按日聚合）。
KV 适合配置、会话、低频状态；拿去做每分钟刷榜，很容易先撞写上限，而不是撞 Workers。

4. 同账号多站：监控 Workers 用量

我这边同一账号还有 go.5201616.xyz、brick.5201616.xyz 等。仪表盘里看 Workers 请求 / 天，别等 429 或配额告警才反应。哪个站突然涨，先查有没有短间隔轮询或爬虫。

5. 开放访问要克制

自用可以；若域名被扫、被当成公开中继，Worker 会被外部流量打穿配额。限流、鉴权、关公开注册——这是运维问题，也是配额问题。

粗算：1 人打开邮箱页，一天多少次？（估算）

下面是估算，不是我后台真实 analytics，别当官方数据。

场景 A：打开页面后每 30 秒轮询，挂一整天

假设活跃约 8 小时盯着标签页：8 × 60 × 2 = 960 次 API/天（仅轮询）。
再加上打开列表、读几封信、收信入库的 Worker 调用，一人一天大概 一千次量级。
相对账号 10 万：一个人这样玩，通常还宽裕——但同账号十几个站 + 多人 + 爬虫，就会挤。

场景 B：改成 60 秒间隔，且仅页面可见时轮询

同样 8 小时「可见」：约 8 × 60 = 480 次。
若实际只有 2～3 小时在看邮箱页，可见轮询大约 120～180 次，再加手动刷新与收信处理。
量级往往能砍一半甚至更多，尤其是你习惯开着标签页去干别的——隐藏即停，省的是「空转」。

多人同时用、或前端写错成 5 秒一轮，估算直接乘上去。免费档的边界感，来自这种乘法，而不是「邮箱业务神秘很贵」。

6. 收信路径别重复打

Email Routing 进 Worker 后，入库逻辑尽量一次写完。别在 Worker 里再连环 fetch 自己的另一个 Worker 做「转发」，除非必要——每次跳转都可能再计一次请求。自用场景：收信 → 解析 → 写 D1/KV → 返回，链路越短越好。

7. 读信 API 做「按需」而不是「全量」

列表接口只返回标题、发件人、时间、id；正文另开详情接口。用户刷列表时别每次把整封 MIME 拖出来。详情可以短时 Cache（注意隐私：临时邮箱内容敏感，缓存键要带邮箱地址与邮件 id，TTL 宜短）。

和「邮箱业务本身」划清边界

有人以为：临时邮箱 = 高并发收信 = 一定贵。自用体感不是这样。

收信频率：个人注册、验证码、偶尔测邮箱，一天几十封都算多；每封触发的 Worker 次数有限。
读信频率：你打开页面的次数 × 轮询频率，才是可控变量。
被扫 / 被滥用：域名暴露后，陌生流量打 API，才会突然贴近 10 万。这和「业务功能」无关，是暴露面问题。

所以排查顺序建议是：仪表盘看 Workers 曲线 → 分路由看哪条 path 多 → 是轮询、爬虫，还是静态误绑 Worker。别一上来就怪「免费档太抠」。

同账号多站时的实操习惯

我自己的习惯就三件事：

每天或每周瞟一眼 Cloudflare 仪表盘里 Workers 的 requests（免费档按天重置的节奏心里有数）。
新功能默认静态优先：能 Pages 就不进 Worker；能浏览器本地状态就不打 API。
写多的数据走 D1：日榜、计数、邮件元数据列表；KV 留给真正低频的配置。下一篇会专门写 D1 日榜怎么设计，避免把写额度花在错误模型上。

小结

够不够：个人起步通常够；爆了先看 账号级 10 万 Workers/天。
怎么上线：clone cloudflare_temp_email → D1 + Worker → Email Routing catch-all → 自定义域；清单见上文「部署检查清单」。
邮箱本身：收信 + 按需读信，合理；杀手是轮询和静态走错路径。
省钱：Pages/CDN、拉长间隔、可见才 poll、KV 慎写、多站一起盯仪表盘。
下篇预告：游戏日榜、计数这类，我会单独写一篇 D1 日榜 怎么建、怎么和免费写额度相处。

自用可玩：临时邮箱 mail.5201616.xyz · 主站 www.5201616.xyz · 短链 go.5201616.xyz · brick.5201616.xyz

有具体 Worker 路由或轮询代码想对照改的，评论区或站点留言丢我；下篇见 D1。

—— 小磊哥

PVE+Ceph 超融合架构解决方案

email@example.com (小磊哥) — Mon, 06 Oct 2025 19:00:00 +0800

一、方案定位：中小客户的“零负担”IT 基础设施

在虚拟化方案选择中，中小企业往往面临多重选择困境：用 VMware 成本过高，用 OpenStack 运维太难，用 ZStack 虽易用但商业版仍有成本门槛。PVE+Ceph 超融合架构以“开源免费 + 极简架构 + 高可用”为核心，专为解决中小客户的 IT 痛点设计，既能替代传统“服务器 + 存储阵列”的复杂架构，又能规避商业方案的成本陷阱，在与 ZStack 的对比中更凸显“零成本门槛”优势。

二、方案核心：计算与存储的“无缝融合”

架构逻辑

同一集群，双重角色：每台服务器同时作为“计算节点”和“存储节点”，无需单独采购存储设备。
Proxmox VE（PVE）：负责管理虚拟机、容器和集群资源，提供 Web 图形化操作界面。
Ceph：作为分布式存储引擎，数据自动多副本存储，支持在线扩容，性能可随节点增加而提升。

与竞品的核心差异

对比项	PVE+Ceph	VMware vSphere	OpenStack	ZStack
成本	开源免费，仅需硬件投入	单节点 License 成本高	开源免费，但运维成本高	开源版免费，商业版按节点收费
部署难度	3 节点集群 1 天内可完成	依赖专业工程师	需要团队掌握命令行工具	图形化部署，半天可完成
硬件要求	支持通用 x86 服务器	认证硬件为主	兼容性复杂	支持通用 x86，兼容性略逊于 PVE
扩容成本	新增节点无额外费用	每节点需追加 License	需专业团队调整架构	商业版按新增节点收费
存储深度	Ceph 与计算层深度融合	需搭配额外收费的 VSAN	需单独集成 Ceph 等存储	内置分布式存储，定制能力弱于 Ceph

三、方案优势：中小客户最关心的 5 个问题

1. 成本能省多少？

对比 VMware：相同规模集群可节省 70% 以上成本，主要来自 License 与专用存储阵列投入的减少。
对比 ZStack 商业版：3 节点集群每年可节省数万元授权费用，且无功能限制。
对比 OpenStack 长期运维：日常操作可通过 Web 界面完成，无需专职运维工程师。

2. 可靠性如何保障？

计算层：节点故障时，虚拟机自动迁移到健康节点，业务不中断。
存储层：数据默认多副本存储，单节点或单磁盘故障时可自动重建。
网络层：支持业务与存储流量分离，10Gbps 网络可保障性能稳定。
相比 OpenStack：PVE 与 Ceph 的联动更紧密，故障恢复链路更直接。

3. 扩展性是否灵活？

横向扩展：新增服务器节点后，计算能力和存储容量同步提升。
纵向扩展：单节点可升级内存或更换 SSD，支持平滑扩容。
对异构硬件兼容较好，可混用不同品牌服务器逐步扩容。

4. 功能是否能满足需求？

支持虚拟机与容器混合部署。
支持快照备份、异地容灾、网络隔离等核心能力。
可完整覆盖中小企业常见 IT 基础设施需求。

5. 适用哪些场景？

中小企业私有云。
分支机构本地化 IT 部署。
开发测试环境。
预算有限、希望“零成本起步 + 全功能使用”的业务场景。

四、详细设计方案

1. 整体架构设计

PVE+Ceph 超融合架构采用“计算 - 存储 - 网络”三层融合设计，各层通过软件定义技术实现资源池化。

客户端层：终端用户或业务系统通过网络访问虚拟机与容器。
网络层：分离业务流量与存储流量，避免相互干扰。
计算层：基于 PVE 实现虚拟机、容器生命周期管理和高可用。
存储层：基于 Ceph 提供分布式块存储，与计算层深度联动。

3 节点基础集群示例

2. 计算层（Proxmox VE）设计

PVE 作为计算层核心，负责虚拟机与容器管理、集群调度和高可用。

PVE 集群机制

通过 corosync 协议实现节点间心跳，默认端口为 5404/5405。
将 3 节点 CPU 和内存聚合为统一的计算资源池。
虚拟机磁盘直接映射 Ceph RBD，减少中间层性能损耗。
基于 PVE 快照机制与 Ceph RBD 快照联动，支持增量快照。

高可用设计

触发条件包括节点故障、虚拟机进程崩溃、存储访问异常。
故障检测由 pve-ha-manager 配合 corosync 完成。
通过 fencing 机制释放故障节点资源，避免脑裂。
依赖 Ceph 存储一致性，在健康节点重启虚拟机，无需拷贝数据。

3. 存储层（Ceph）设计

Ceph 负责提供高可用、可扩展的分布式块存储。

核心组件部署

MON：3 节点各部署 1 个 MON，形成仲裁机制。
MGR：1 个活跃节点，其他节点作为备用。
OSD：每块数据盘对应 1 个 OSD，3 节点合计 9 个 OSD。

数据分布设计

通过 CRUSH 规则优先将副本分布在不同节点，避免单节点故障带来连锁影响。
建议规划 vm-disks 和 backups 两类 Pool。
核心业务数据使用 3 副本，备份数据可根据容量需求使用 2 副本。
vm-disks 可按 9 个 OSD 规模规划为 128 个 PG。

性能优化设计

数据盘建议优先采用 SSD，热数据可优先落在 NVMe。
每节点预留系统 SSD 空间给 block.wal 与 block.db。
存储网络建议启用 Jumbo Frame，减少协议开销。

4. 网络设计

网络分层与 VLAN 规划

网络冗余设计

业务网可采用双网卡 bond0，推荐 active-backup 模式。
存储网可采用双网卡 bond1，推荐 LACP 模式，以提升同步带宽。

5. 高可用与可靠性设计

故障场景与恢复机制

数据一致性保障

Ceph 通过主从副本同步机制保证写入一致性。
PVE 集群启用 corosync quorum，Ceph MON 集群通过多数派维持状态一致。

6. 适配中小客户的设计优化

简化运维

通过 PVE Web 界面统一管理计算与存储。
可预制自动化脚本，降低命令行操作依赖。

低成本适配

支持白牌服务器与消费级 SSD 组合。
可通过 osd crush weight 控制不同性能磁盘的负载分配。
针对非核心业务允许适度资源超分，以提升资源利用率。

7. 扩展设计

横向扩展

新增节点安装 PVE 后，通过 pvecm add 加入现有集群。
使用 ceph orch daemon add osd 部署新磁盘为 OSD。
CRUSH 规则与资源池会自动纳入新节点。

纵向扩展

支持升级单节点内存并自动纳入资源池。
替换 SSD 时，可先将旧 OSD 标记下线、迁移数据后再部署新盘。

扩展设计示意

8. 安全设计

PVE 可通过用户与角色实现权限管理。
Ceph 可通过 ceph auth 控制客户端访问权限。
Ceph 支持 RBD 磁盘加密，密钥可存放在 PVE 节点的受限目录中。
业务网与存储网建议通过 VLAN 严格隔离，并在交换机侧配置 ACL。

五、核心价值总结

PVE+Ceph 超融合架构在与 ZStack 的对比中，以“全功能开源免费”和“存储深度优化”脱颖而出，让中小企业无需为功能付费，也无需妥协性能。

花小钱办大事：用通用硬件搭建接近商业方案能力的 IT 基础设施。
少操心多做事：统一管理、简化运维，比 OpenStack 更容易落地。
随需而变：从 3 节点起步，平滑扩容，适配业务增长。

如果你的目标是在预算可控的前提下，构建一套稳定、可扩展、易维护的私有云基础设施，那么 PVE+Ceph 是一条非常务实的落地路径。

2026 保姆级教程｜Github+Hugo+Cloudflare，零成本搭建个人技术博客

email@example.com (小磊哥) — Mon, 29 Sep 2025 20:00:00 +0800

引言

在数字时代，拥有一个个人技术博客是展示技能、分享知识、建立个人品牌的绝佳方式。然而，许多人因为成本、技术门槛或维护复杂性而却步。本文将介绍一种 零成本、高稳定性、易于维护 的解决方案：使用 GitHub 托管代码、Hugo 生成静态网站、Cloudflare Pages 部署，并搭配功能强大的 FixIt 主题。

为什么选择这个技术栈？

GitHub：免费私有仓库，版本控制，协同工作。
Hugo：全球最快的静态网站生成器之一，使用 Go 语言编写，构建速度极快。
Cloudflare Pages：全球 CDN 加速，免费 SSL 证书，自动构建和部署。
FixIt：现代化的 Hugo 主题，功能丰富，性能优异，支持多语言、评论系统、SEO 优化等。

这套方案完全免费（个人使用），并且可以轻松扩展到生产环境。

适用场景

个人技术博客：记录学习笔记、项目经验、技术心得。
作品集展示：展示开发项目、设计作品、写作文章。
知识分享：分享特定领域的知识，如编程、设计、数据分析。
团队文档：小型团队或开源项目的文档站点。
实验性项目：快速搭建和部署实验性网站。

无论你是学生、开发者、设计师还是技术爱好者，这个方案都能满足你的需求。

准备工作

所需工具

Git：版本控制工具。下载地址
Hugo Extended：静态网站生成器（Extended 版本支持 SCSS）。安装指南
文本编辑器：推荐 VS Code、Sublime Text 或任何你喜欢的编辑器。
终端：命令行界面（Windows 可使用 PowerShell 或 WSL，macOS/Linux 使用 Terminal）。

账号注册

GitHub 账号：注册地址
Cloudflare 账号：注册地址（使用 GitHub 登录更便捷）

第一步：创建 GitHub 仓库

1.1 新建仓库

Repository name：建议使用 my-blog 或 tech-blog。
Description：可选，例如 “我的个人技术博客”。
Public/Private：选择 Public（免费）或 Private（Hugo 生成的静态文件可以托管在 Public 仓库）。
Initialize this repository with：不要勾选任何初始化选项（如 README、.gitignore 等）。

点击 “Create repository”。

1.2 克隆仓库到本地

在终端中执行以下命令（将 <your-username> 和 <repo-name> 替换为你的信息）：

git clone https://github.com/<your-username>/<repo-name>.git
cd <repo-name>

1.3 初始化 Hugo 站点

在仓库目录中，执行：

hugo new site . --force

这会在当前目录创建 Hugo 站点结构。

第二步：安装和配置 Hugo 主题

2.1 选择 Hugo 主题

这里我们使用功能丰富的 FixIt 主题。有三种安装方式：

方式一：使用 FixIt CLI（推荐）

npx fixit-cli create my-blog

方式二：Git Submodules（传统方式）

git submodule add https://github.com/hugo-fixit/FixIt.git themes/FixIt

方式三：Hugo Modules（高级方式）

初始化 Hugo 模块：

hugo mod init github.com/<your-username>/<repo-name>

在 hugo.toml 中添加：

[module]

[[module.imports]]
path = "github.com/hugo-fixit/FixIt"

2.2 配置主题

打开 hugo.toml 文件，添加以下基本配置：

baseURL = "https://<your-username>.github.io/<repo-name>/"
languageCode = "zh-cn"
title = "我的技术博客"
theme = "FixIt"

# 启用 Git 信息
enableGitInfo = true

# 默认主题：light / dark / auto
[params]
defaultTheme = "auto"

# 站点描述
description = "记录技术学习和项目经验的博客"

# 作者信息
[params.author]
name = "你的名字"
email = "your-email@example.com"
link = "https://github.com/<your-username>"
avatar = "/images/avatar.jpg"

# 搜索功能
[params.search]
enable = true
type = "fuse"

# 评论系统（以 Waline 为例）
[params.page.comment]
enable = true

[params.page.comment.waline]
enable = true
serverURL = "https://your-waline-server.vercel.app"

# 数学公式支持
[params.page.math]
enable = true
type = "katex"

2.3 创建第一篇文章

hugo new posts/my-first-post.md

编辑 content/posts/my-first-post.md：

---
title: "我的第一篇文章"
date: 2026-03-29T20:00:00+08:00
draft: false
tags: ["Hugo", "博客", "教程"]
categories: ["技术"]
---

## 欢迎来到我的博客

这是我的第一篇文章，使用 Hugo 和 FixIt 主题生成。

### 功能展示

- 支持 **Markdown** 语法
- 支持代码高亮
- 支持数学公式：$E = mc^2$
- 支持图表（Mermaid）

```mermaid
graph TD;
 A-->B;
 A-->C;
 B-->D;
 C-->D;

感谢阅读！


---

## 第三步：本地预览和测试

### 3.1 启动开发服务器

```bash
hugo server -D

访问 http://localhost:1313 预览博客。

3.2 构建静态站点

测试构建命令：

hugo --minify

这会生成 public 目录，包含所有静态文件。

第四步：部署到 Cloudflare Pages

4.1 连接 GitHub 仓库

登录 Cloudflare Dashboard。
进入 “Workers & Pages”，点击 “Create application” -> “Pages” -> “Connect to Git”。
选择你的 GitHub 仓库，授权 Cloudflare 访问。

4.2 配置构建设置

Project name：项目名称（自动生成或自定义）。
Production branch：main 或 master。
Build command：hugo --minify（或者 bash build.sh 如果你有自定义脚本）。
Build output directory：public（如果是 FixIt 主题的 demo 应用，可能是 apps/demo/public）。

4.3 环境变量（可选）

如果使用 Hugo Modules，可能需要设置环境变量：

HUGO_VERSION：0.156.0 或更高版本。
HUGO_ENV：production。

4.4 部署

点击 “Save and Deploy”。Cloudflare 会自动拉取代码、构建并部署。

几分钟后，你会获得一个 *.pages.dev 域名，例如：https://my-blog.pages.dev。

第五步：自定义域名（可选）

5.1 购买或使用已有域名

在域名注册商处购买域名，或使用已有的域名。

5.2 配置 DNS

在 Cloudflare DNS 设置中，添加一条 CNAME 记录：

Type：CNAME
Name：www（或 @）
Target：<your-project>.pages.dev
Proxy status：启用（橙色云朵）

5.3 在 Cloudflare Pages 绑定域名

进入 Pages 项目设置 -> “Custom domains”。
点击 “Set up a custom domain”，输入你的域名。
Cloudflare 会自动配置 SSL 证书。

进阶技巧

1. 使用 FixIt 主题的丰富功能

FixIt 主题提供了许多开箱即用的功能：

评论系统

支持 Disqus、Gitalk、Waline、Twikoo 等多种评论系统。在 hugo.toml 中配置：

[params.page.comment.twikoo]
enable = true
envId = "https://your-twikoo-id"

搜索功能

支持 Algolia、Fuse.js、Google CSE 等搜索后端：

[params.search]
enable = true
type = "algolia"

SEO 优化

主题内置了 SEO 优化，包括 JSON-LD 结构化数据、Open Graph、Twitter Cards 等。

2. 自定义主题样式

创建 assets/css/_override.scss 文件，覆盖主题变量：

// 全局字体
$global-font-family: 'LXGW WenKai', $global-font-family;

// 代码字体
$code-font-family: 'Fira Mono', $code-font-family;

// 页面宽度
[data-page-style='custom'] {
 %page-style {
 width: 80%;
 max-width: 1200px;
 }
}

3. 添加 Google Analytics

[params.analytics.google]
id = "G-XXXXXXXXXX"
anonymizeIP = true

4. 多语言支持

FixIt 支持 17 种语言。在 hugo.toml 中配置：

[languages]

[languages.en]
languageCode = "en"
title = "My Tech Blog"
weight = 1

[languages.zh-cn]
languageCode = "zh-cn"
title = "我的技术博客"
weight = 2

5. 使用 PWA（渐进式 Web 应用）

[params]
enablePWA = true

6. 自动部署工作流

在 GitHub 仓库中创建 .github/workflows/deploy.yml，实现推送代码后自动构建和部署。

常见问题解答

Q1: Hugo Extended 版本是什么？为什么需要它？

A1: Hugo Extended 版本支持 SCSS/SASS 处理。FixIt 主题使用 SCSS 进行样式设计，因此需要 Extended 版本。

Q2: 如何更新 FixIt 主题？

A2: 如果使用 Git Submodules：

git submodule update --remote --merge themes/FixIt

如果使用 Hugo Modules：

hugo mod get -u github.com/hugo-fixit/FixIt

Q3: Cloudflare Pages 构建失败怎么办？

A3: 检查构建日志，常见问题：

Hugo 版本过低：设置环境变量 HUGO_VERSION=0.156.0。
构建命令错误：确保命令正确，例如 hugo --minify。
输出目录错误：确认是 public 或 apps/demo/public。

Q4: 如何添加图片？

A4: 在 static/images/ 目录下添加图片，然后在 Markdown 中引用：

![图片描述](/images/example.jpg)

Q5: 如何启用 MathJax 或 KaTeX 数学公式？

A5: 在 hugo.toml 中配置：

[params.page.math]
enable = true
type = "katex" # 或 "mathjax"

然后在文章中使用 LaTeX 语法。

配图建议

为了让文章更直观，建议在以下步骤添加配图：

GitHub 仓库创建：截图展示创建仓库的界面。
Hugo 站点结构：展示 hugo new site 生成的目录结构。
FixIt 主题预览：展示主题的演示站点截图。
本地预览：展示 hugo server 后的浏览器界面。
Cloudflare Pages 部署：截图展示 Cloudflare Pages 的配置界面。
最终效果：展示部署后的博客首页、文章页、移动端适配等。

可以使用工具如 ShareX、Flameshot（Linux）、截图工具（Windows/macOS）来截取图片，并上传到图床（如 GitHub 仓库的 images 目录）。

总结

通过 GitHub + Hugo + Cloudflare Pages 的组合，你可以零成本搭建一个高性能、高可用的个人技术博客。FixIt 主题提供了丰富的功能和现代化的设计，让你专注于内容创作，而无需担心技术细节。

资源链接

FixIt 主题文档：https://fixit.lruihao.cn/documentation/
Hugo 官方文档：https://gohugo.io/documentation/
Cloudflare Pages 文档：https://developers.cloudflare.com/pages/
GitHub 文档：https://docs.github.com/

开始你的博客之旅吧！分享你的知识，记录你的成长。

My First Post

email@example.com (小磊哥) — Mon, 20 Feb 2023 20:14:22 +0800

A blog (a truncation of “weblog”) is an informational website published on the World Wide Web consisting of discrete, often informal diary-style text entries (posts). Posts are typically displayed in reverse chronological order so that the most recent post appears first, at the top of the web page. Until 2009, blogs were usually the work of a single individual,[citation needed] occasionally of a small group, and often covered a single subject or topic. In the 2010s, “multi-author blogs” (MABs) emerged, featuring the writing of multiple authors and sometimes professionally edited. MABs from newspapers, other media outlets, universities, think tanks, advocacy groups, and similar institutions account for an increasing quantity of blog traffic. The rise of Twitter and other “microblogging” systems helps integrate MABs and single-author blogs into the news media. Blog can also be used as a verb, meaning to maintain or add content to a blog.