Junius 的博客

经典蛋黄莲蓉月饼

Tue, 08 Sep 2026 11:33:00 GMT

非常经典的广式月饼——蛋黄莲蓉月饼。

转化糖浆 + 花生油 + 碱水 + 中筋粉做柔软饼皮，裹白莲蓉和咸蛋黄。皮馅 3:7，165°C 烤 20 分钟，密封回油 2-3 天后吃，饼皮回软、蛋黄流油。

饼皮

原料	用量	备注
转化糖浆	110g	广式月饼核心糖浆，提供回油
花生油	40g	无味植物油，忌菜籽油/芝麻油等重味油
碱水	2g	约 1/4 小勺；家用：食用碱 1 : 水 3
奶粉	7g	一大勺约 15ml；无奶粉可等量换中筋面粉
中筋面粉	150g	过筛使用

馅料

原料	用量
白莲蓉	500g
咸蛋黄	20 个

真空咸蛋黄把不规则边剪掉可变圆。可白酒清洗去腥，180°C 烤约 5 分钟到微微出油就停；烤到发白就过了，包时易碎。

做法

饼皮：碱水倒入糖浆+花生油混合液，搅至完全乳化（先分离后均匀发白）→ 加奶粉拌匀 → 筛入中筋粉，切拌成团（勿过度出筋）
松弛：装保鲜袋常温 30 分钟 ~ 1 小时
馅料：咸蛋黄 180°C 烤 5 分钟微微出油；白莲蓉揉匀
包：皮馅比 3:7（皮 15g + 馅 35g/50g 月饼）；蛋黄横放（竖放饼皮易破）
压模：顶部拍面粉防粘；花纹简单易脱模
烤：165°C 约 20 分钟，中途第 5 分钟取刷薄全蛋液
回油：出炉色浅质硬；密封 2-3 天回油变深变软、皮馅蛋黄味相融

重量换算速查

成品	皮	馅+蛋黄
50g	15g	35g
75g	23g	52g
100g	30g	70g

保存

阴凉密封 7-10 天；勿放冰箱（冷凝水回潮变软）；回油后再吃风味最佳。

坑

🥮 不要自己炒莲蓉馅——新手炒馅含水量难控、失败率高，用市售白莲蓉
🥮 烘烤时间按自家烤箱调整（18/20/25 分钟）
🥮 蛋液要薄刷，厚了糊花纹

零成本自建网站访问统计（Umami + NAS）

Tue, 08 Sep 2026 10:00:00 GMT

这套东西能给你什么

装完之后你会得到两样：

后台分析面板：PV/UV、来源、国家、设备、实时在线，都有现成图表
前台数字：在自己网站底部显示「本站总浏览量 X 次」这种计数

数据全部存在你自己的设备上，不经第三方。Umami 不用 cookie，所以也不用给网站加隐私弹窗。

一个 Umami 实例能管多个网站，每个站分一个 ID，各贴一段 JS 就行。

做完之后，网站底部会显示这样一行实时计数（数字到秒在跳）：

整体结构

访客浏览器
   ↓ 加载 Umami 统计脚本
统计域名（比如 stats.你的域名.com）
   ↓ Cloudflare Tunnel 反代
NAS：Umami 容器 + PostgreSQL（数据在硬盘上）

Cloudflare 在这里只当网络通道，不碰你的数据内容。

第 1 步：在 NAS 上跑起 Umami

我用 Docker Compose 一次起两个容器：Umami 本体 + PostgreSQL 数据库。

新建一个 docker-compose.yml，内容类似这样（按你的实际情况改端口和密码）：

services:
  umami:
    image: ghcr.io/umami-software/umami:postgresql-latest
    ports:
      - "36439:3000"   # 左边是宿主机（NAS）端口，右边是容器内端口
    environment:
      DATABASE_URL: postgresql://umami:你的密码@db:5432/umami
      DATABASE_TYPE: postgresql
      APP_SECRET: 换成随机字符串
    depends_on:
      db:
        condition: service_healthy   # 等数据库就绪再启动 Umami
  db:
    image: postgres:15-alpine
    environment:
      POSTGRES_DB: umami
      POSTGRES_USER: umami
      POSTGRES_PASSWORD: 你的密码
    volumes:
      - ./data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U umami"]
      interval: 10s
      timeout: 5s
      retries: 5

healthcheck 那段建议留着。不加的话，PostgreSQL 还没完全启动 Umami 就去连，容易启动失败或者连上又断——重启 NAS 后尤其容易遇到。

在 NAS 的 Docker 管理界面里粘贴这段（各家 NAS 都有"项目 / Compose"这种入口），启动。

端口别记混：上面把容器的 3000 映射成了 36439，所以内网访问要开 http://NAS的IP:36439。直接按 3000 打开是打不开的，那是容器内部的端口。

启动后浏览器打开这个地址，用默认账号登录（Umami 默认 admin / umami），进去第一件事是改密码。

第 2 步：让它能从外网访问

家里或内网的 NAS 没有公网 IP，用 Cloudflare Tunnel 穿出来：

进 Cloudflare Zero Trust 后台，创建一个 Tunnel，会拿到一串 Token
在 NAS 上跑 cloudflared（Docker 或装二进制都行），把 Token 配上
给这个 Tunnel 加一条 Public Hostname，比如 stats.你的域名.com，回源指向 http://localhost:36439（或容器名 http://umami:3000）

配好之后，你从任何地方打开 stats.你的域名.com 就能进后台了，而且是 HTTPS，不用自己申请证书。

第 3 步：给网站加上统计脚本

在 Umami 后台添加你的网站，会生成一段 tracking 代码和一个 website ID。把这段脚本贴到网站的 <head> 里：

<script defer src="https://stats.你的域名.com/script.js" data-website-id="你的websiteID"></script>

静态博客一般贴在公共布局文件里（我的是 BaseLayout.astro），全站页面就都带上了。

脚本文件名有两种：新版本是 script.js，老一点的版本叫 umami.js，功能一样。不确定就直接复制后台给你生成的那段代码，别自己拼。

等几分钟回后台看，有访客进来就能看到数据了。

第 4 步：在页面底部显示访问数

后台有了，前台也想显示个总数。Umami 支持"公开分享"——在后台给网站开一个分享链接，会得到一个 share ID，靠它就能调接口拿数字。

流程是两步：

① 用 share ID 换一个临时 token：

GET https://stats.你的域名.com/api/share/{shareId}

返回里有个 token 和 websiteId。

② 带这个 token 去查统计：

GET https://stats.你的域名.com/api/websites/{websiteId}/stats?startAt=0&endAt=当前时间戳

请求头带上：

x-umami-share-token: 刚才换到的 token
x-umami-share-context: share

返回的是访问量和访客数，前端渲染成「本站总浏览量 X 次」就行。

我博客上是个 Astro 组件做这件事：进页面时先显示上次缓存在 localStorage 的数字（不等接口），后台同时去拉最新值，拉到再更新。这样访客不会看到空白或者等半天才出数字。

分享 ID 本来就是只读的，拿它只能查统计，改不了数据也进不了后台，所以放在前端代码里没问题。

第 5 步：记得备份

数据都在 PostgreSQL 里，定期导出一下比较稳妥。我是每天跑一次 pg_dump 并保留 7 天：

pg_dump -U umami umami > backup_$(date +%F).sql

丢进定时任务里就行。NAS 一般都有"计划任务"功能，配个每天凌晨执行。

关于速度

这套架构下，访客的请求路径是：浏览器 → Cloudflare 边缘 → Tunnel → 你的 NAS。国内访问因为要绕一圈，加载统计脚本会比纯 CDN 慢一些，但对统计这种后台数据来说影响不大（它不阻塞页面显示）。

如果你特别在意国内打开速度，可以再租个国内轻量云做反代，或者用 DNS 分线路解析——不过那是后话了，先用起来再说。

写在最后

自己搭统计最有价值的地方不是省多少钱，而是数据在自己手上：想查什么自己写 SQL，想导出去随时能导，也不用担心哪天第三方服务关停就没了。

装好之后我每天会瞄一眼后台的实时在线，看到有人正在读自己写的东西，那种感觉还挺实在的。你要是也想给自己的站点加一套，可以照着这个流程走一遍。

零成本给静态博客加评论区（Twikoo + Cloudflare）

Tue, 08 Sep 2026 04:00:00 GMT

为什么选 Twikoo

静态站加评论，说白了就是借个后端存数据，页面上嵌个前端组件。我筛过一轮，最后留下 Twikoo 的原因很实际：

访客不用注册。填昵称 + 邮箱就能评，不会劝退读者（Giscus 和 utterances 都要 GitHub 账号，对普通读者太重）
和我的博客在同一张网。博客跑在 Cloudflare Pages，评论后端也在 Cloudflare，不会出现页面秒开但评论区一直转圈
数据在手。评论存在自己的 D1 库里，想查想导都方便

其他方案各有各的问题：Waline 放 NAS 要绕 Cloudflare Tunnel，慢；Disqus 在大陆基本打不开。这篇不打算做选型对比，只讲怎么落地上线。

整体结构

博客页面（Cloudflare Pages）
        │  嵌一段前端脚本
        ▼
   Twikoo 前端组件
        │  发请求
        ▼
 Cloudflare Worker（Twikoo 后端）
        │
        ▼
   D1 数据库（存评论）

域名这块有个坑，得单独说。

先看一眼做完的效果。文章底部会出现评论区，访客填昵称邮箱就能留言：

第 1 步：部署后端

Twikoo 官方有现成的 Cloudflare 模板，拉下来就能用，全程大概二十分钟。

① 装 wrangler 并登录（Cloudflare 的命令行工具）：

npm install -g wrangler
npx wrangler login   # 会弹浏览器让你授权

② 克隆官方模板 + 装依赖：

git clone https://github.com/twikoojs/twikoo-cloudflare.git
cd twikoo-cloudflare && npm install

③ 清掉 3 个不兼容的包。CF 免费版单个 Worker 代码上限 1MiB，这几个包在 Worker 里用不上（Node 兼容问题），清空能压到限制内：

echo "" > node_modules/jsdom/lib/api.js
echo "" > node_modules/tencentcloud-sdk-nodejs/tencentcloud/index.js
echo "" > node_modules/nodemailer/lib/nodemailer.js

第一次部署我忘了这步，bundle 超限直接失败。后面 D1 和 R2 的命令都依赖它，别漏。

④ 建数据库（存评论）：

npx wrangler d1 create twikoo

输出里有个 database_id，填进 wrangler.toml 替换占位值。

⑤ 建表 + 建存储：

npx wrangler d1 execute twikoo --remote --file=./schema.sql
npx wrangler r2 bucket create twikoo   # R2 存评论里的图片，暂时不需要传图也可以跳过

建 R2 桶报 code 10042，是账号还没开通 R2，去后台点一下就行。

⑥ 部署：

npx wrangler deploy --minify

成功后会给你一个 https://twikoo-cloudflare.<你的用户名>.workers.dev。浏览器打开，看到 {"code":100,"message":"Twikoo 云函数运行正常..."} 就是后端活了。这个地址就是前端要用的 envId——但别急着用，先做第 2 步。

第 2 步：绑自定义域名（别跳过）

我被这个坑卡了最久，单独拎出来讲。

CF 给的 *.workers.dev 域名在大陆时通时不通。我的症状是：评论时有时无，头像一片空白，刷新几次又好了。一开始以为是头像配置错了，折腾半天才反应过来——评论数据根本没拉回来，那个域名不通。

解法是给 Worker 绑你自己的域名。wrangler.toml 加一行：

routes = [
  { pattern = "评论.你的域名.com", custom_domain = true }
]

再 npx wrangler deploy 一次，workers.dev 的路由会自动停用，之后前端 envId 就用你自己的域名。绑完之后再没出过加载问题。

第 3 步：接入前端

① 装 Twikoo 前端：

npm install twikoo

② 建 Comments.astro 组件（我博客用的 Astro，其他框架思路一样：放个容器 + 调 twikoo.init）：

---
const path = Astro.url.pathname;
---
<section class="comments" id="comments">
  <h2>评论</h2>
  <div id="tcomment" data-path={path}></div>
</section>

<script>
  import twikoo from 'twikoo';
  const container = document.getElementById('tcomment');
  if (container) {
    const path = container.dataset.path || location.pathname;
    twikoo.init({
      envId: 'https://评论.你的域名.com', // 填第 2 步绑的域名
      el: '#tcomment',
      path, // 每篇传自己的 URL，评论就按篇分开了
    });
  }
</script>

View Transitions 的坑：博客如果开了 Astro 的站内切页动画，切到新文章时评论区不会自己刷新（第一篇能显示，点别的文章就空白）。要监听 astro:page-load，每次先把容器清空再重新 init，不然会重复渲染。没开的话不管它，init 一次就行。

③ 挂到文章页：在文章详情页 <Content/> 后面引入，放上 <Comments />。

④ 样式贴合主题：给 .comments 补点间距、用上站点的强调色。评论区底部那排 Markdown 提示图标和 “Powered by Twikoo” 页脚，我直接用 CSS 藏了，看着干净些。

第 4 步：管理评论

Twikoo 没有独立后台，管理入口就在评论窗口右下角那个小齿轮图标（不是点头像，我一开始也找错地方）：

第一次设密码：点小齿轮，会让你设管理员密码，设完存到后端
日常管理：再点小齿轮输密码，能置顶、加精、删除、把评论标成博主

想藏得更深，可以用 HIDE_ADMIN_CRYPT 设个暗号：之后只有在昵称栏输入暗号的人，点齿轮才看得到管理入口。不过暗号只是藏界面，真正挡人的还是密码，两个别设成一样的。

踩过的坑

头像空白、评论时有时无：先查 workers.dev 通不通。大多是那个域名的问题，按第 2 步绑域名解决，别像我一样先去折腾头像配置。
同一篇文章的评论分成两处：CF 版不自动归一化 URL 尾斜杠，/post/1/ 和 /post/1 会被当成两篇。前端 path 统一格式就行，别直接裸用 location.pathname。
默认头像服务是坏的：Twikoo 默认的 weavatar.com 已经 500 了。换的时候注意 cravatar.cn 会无视 d= 参数，一直返回它家那个卡皮巴拉吉祥物，想要按邮箱生成几何图案得换尊重参数的镜像（我用的 sdn.geekzu.org）。管理面板里配 GRAVATAR_CDN 和 DEFAULT_GRAVATAR 两项。
邮箱格式要写全：QQ 邮箱只认 @qq.com，少个 .com 会被当普通邮箱，头像就查不对。
管理密码是双重 md5：前端先 md5 一次发给后端，后端再 md5 一次比对。要是直接改库重置密码，存 md5(md5(明文))，只存单层会一直提示密码错误。
配置改完要点保存：管理面板填的配置存数据库，每项改完得点保存按钮才落库。
前端锁版本：用 CDN 引 Twikoo 建议锁死版本号（比如 twikoo@1.7.22），国内访问可以走 npmmirror 或 zstatic 镜像，避免升级带出不兼容变更。

实际用下来

评论功能该有的都有：发、读、回复、嵌套、Markdown、表情
评论区内容自动做 XSS 过滤（CF 版用 xss 替代不兼容的 dompurify），不用自己配
成本为零，CF 免费额度对个人博客的评论量来说绰绰有余
唯一受限的是邮件通知：常规 SMTP 用不了（nodemailer 不兼容 Worker），要接 SendGrid 之类的 API。我没配，不影响使用

写在最后

这套东西真正省心的地方是后端几乎不用管——模板官方在维护，评论躺在我自己的库里随时能查。要说有什么非记不可的，就一条：一定绑自己的域名，别直接用 workers.dev。

你要是也在用静态框架搭博客、还没想好评论区怎么做，可以试试这个组合。这篇底下就是现成的评论区，能留言就说明它真的跑通了。

零成本搭建个人静态网站（Astro + Pagefind）

Fri, 04 Sep 2026 07:30:00 GMT

这套方案好在哪

很多人一听“搭个人网站”就觉得得买服务器、搞备案、写后端，其实纯静态网站这些都不需要。

不用服务器：页面都是提前生成好的 HTML，丢到免费托管平台就能跑，没有后端程序要养。
不用花钱：框架是开源的，托管平台有免费额度，还会自动送你一个 <项目名>.pages.dev 子域名，域名都不用买就能先上线。
不用给访客背 JS 包袱：默认只下发纯 HTML，打开快，流量省。
自带全文搜索：用 Pagefind，构建的时候顺手把全站文字做成索引，访客在浏览器里就能搜，不靠任何搜索服务器。

这套东西适合个人博客、作品集、简历页、知识库这类“展示为主、内容不大动”的站。反过来，如果你要的是登录、评论、实时数据这种，那静态站就不合适了。

做完大概长这样——深色主题（默认）：

点右上角的按钮还能一键切成浅色主题：

技术选型（为什么是这几样）

组件	选择	为什么
框架	Astro	用 Markdown 写文章很顺手；内容集合帮你把文章的标题、日期这些元信息管起来；默认产出的就是零 JS 静态页面
搜索	Pagefind	纯静态的全文搜索：构建时生成索引，浏览器端检索，没有服务器
托管	Cloudflare Pages	免费额度够用、自带全球 CDN、还能接 Git 自动部署；国内打开速度一般，但免费站已经很值了
样式	手写 CSS	静态站的样式不复杂，用几个 CSS 变量当“设计 token”就够，不必上重型框架

提前提醒一个坑：纯静态站别装 Cloudflare 的 Astro 适配器（@astrojs/cloudflare），原因见文末「常见坑 1」。

第 1 步：准备本地环境

其实只要装两样东西：

Node.js——装 LTS 版就行，去官网下个安装包
一个代码编辑器——VS Code 挺好，你用别的顺手的也完全没问题

装完在终端里敲两下，确认没装错：

node -v   # 能打印出版本号就是装好了
npm -v    # npm 会跟着 Node 一起装

第 2 步：创建项目

用 Astro 官方的脚手架来建。先 cd 进一个你想放项目的空文件夹，然后跑（把 my-site 换成你想起的名字）：

npm create astro@latest my-site

中途会问几个问题，新手照下面选就行（没列到的直接回车用默认）：

How would you like to start? → Empty（空白模板，最干净）
Install dependencies? → Yes
Initialize a git repository? → Yes（后面接自动部署要用）
TypeScript → Strict

这些提问的文案会随 Astro 版本变，你只要对上大意就行，不用抠字眼。

接着进到项目里，把本地预览跑起来：

cd my-site
npm run dev

浏览器打开 http://localhost:4321，能看到页面、也没有报错，说明环境没问题，可以继续了。

第 3 步：先看懂项目结构

先认识下这个项目最后会长成什么样（src/ 下的 content/、layouts/、styles/ 这些子目录，空白模板一开始是没有的，是你后面几步自己加出来的）：

my-site/
├── src/
│   ├── content/          # 文章放这（博客/项目等分目录）
│   ├── content.config.ts # 内容集合的格式定义（schema，见第 4 步）
│   ├── layouts/          # 页面外壳（头部/页脚/主题）
│   ├── pages/            # 一个 .astro 文件 = 一个页面
│   │   ├── index.astro   # 首页
│   │   └── blog/         # 博客相关页面
│   └── styles/           # 全局样式
├── astro.config.mjs      # Astro 配置（站点地址等）
└── package.json          # 依赖与命令

心里记着一条就行：pages/ 管“有哪些页面”，content/ 管“文章放哪”。把 Markdown 丢进 content/blog/，它就成了能写的文章。

第 4 步：告诉 Astro 你的文章长什么样

去 src/content.config.ts 里定义一下文章格式（这玩意儿叫 schema）。拿博客举例，规定每篇文章得有标题、日期，描述和标签可有可无：

import { defineCollection, z } from 'astro:content';
import { glob } from 'astro/loaders';

// 博客文章集合：扫描 src/content/blog/ 下所有 .md
const blog = defineCollection({
  loader: glob({ pattern: '**/*.md', base: './src/content/blog' }),
  schema: z.object({
    title: z.string(),                          // 标题（必填）
    description: z.string().optional(),         // 摘要（可选）
    date: z.coerce.date(),                      // 发布日期（必填）
    updated: z.coerce.date().optional(),        // 更新日期（可选）
    tags: z.array(z.string()).default([]),      // 标签（默认空）
    draft: z.boolean().default(false),          // 草稿标记（默认发布）
  }),
});

export const collections = { blog };  // 用到的集合都要在这登记

再写一篇测试文章试试，src/content/blog/hello.md：

---
title: 你好，世界
description: 我的第一篇文章
date: 2026-09-04
tags: [随笔]
---

这是我的第一篇文章。欢迎来到我的网站。

第 5 步：建列表页和详情页

要让文章能被点开，需要两个页面：一个列表页（罗列文章标题），一个详情页（点进去看正文）。

下面贴的是核心逻辑（取数据 + 循环渲染）。一个完整页面还要有站点自己的头部、页脚这些外壳，套进你项目里现成的布局就行，这里先省略，免得干扰你理解重点。

列表页 src/pages/blog/index.astro 的核心：

---
// 取出所有非草稿文章，按日期倒序
import { getCollection } from 'astro:content';

const posts = (await getCollection('blog', ({ data }) => !data.draft))
  .sort((a, b) => b.data.date - a.data.date);
---

{posts.length > 0 ? (
  <ul>
    {posts.map((post) => (
      <li><a href={`/blog/${post.id}/`}>{post.data.title}</a></li>
    ))}
  </ul>
) : (
  <p>还没有文章。</p>
)}

详情页 src/pages/blog/[slug].astro 的核心——[slug] 是 Astro 的动态路由，一篇 Markdown 就对应一个网址：

---
import { getCollection, render } from 'astro:content';

// 为每一篇文章生成一个静态详情页
export async function getStaticPaths() {
  const posts = await getCollection('blog', ({ data }) => !data.draft);
  return posts.map((post) => ({ params: { slug: post.id }, props: { post } }));
}

const { post } = Astro.props;
const { Content } = await render(post);
---

<h1>{post.data.title}</h1>
<time>{post.data.date.toISOString().slice(0, 10)}</time>
{post.data.tags.map((t) => <span>{t}</span>)}

<Content />  {/* 文章正文会自动渲染到这里 */}

存盘后 npm run dev 刷新一下，/blog/ 就能看到文章列表，点进去是正文。

第 6 步：加全文搜索（Pagefind）

Pagefind 的思路是：构建的时候扫一遍生成好的 HTML，把文字建成索引，访客在浏览器里搜，全程不碰后端。

装依赖：

npm install pagefind

再往 package.json 里加一条 postbuild 命令——这样每次 npm run build 建完站，会自动顺手跑 Pagefind 生成索引：

"scripts": {
  "build": "astro build",
  "postbuild": "pagefind --site dist"
}

这里容易踩坑，重点看：dist 是 Astro 默认的构建输出目录，Pagefind 就是扫它、把索引生成到 dist/pagefind/ 里。

接着往页面里放搜索框。以官方默认 UI 为例，在你想放搜索的那个页面（比如 src/pages/search.astro）里加：

<link href="/pagefind/pagefind-ui.css" rel="stylesheet" />
<script src="/pagefind/pagefind-ui.js" defer></script>
<div id="search"></div>
<script>
  window.addEventListener('DOMContentLoaded', () => {
    new PagefindUI({ element: '#search' });
  });
</script>

再控制一下什么内容进搜索（这步很关键）。 Pagefind 默认把整张页面都收进索引，导航、页脚这些每页都重复的文字也会混进去，搜出来一堆没用的。正确做法：

给正文容器打个 data-pagefind-body，告诉 Pagefind“只索引这一块”。
只要全站有任意一个 data-pagefind-body，Pagefind 就会自动跳过没打标记的页面——首页、列表页、搜索页这些导航类页面就都被排除了。
正文里还有个别不想收的局部（比如“返回列表”的链接、日期那行 meta），单独打 data-pagefind-ignore。

<article data-pagefind-body>   <!-- 只索引正文 -->
  <h1>文章标题</h1>
  <div class="meta" data-pagefind-ignore>2026-09-04</div>  <!-- 排除 meta -->
  正文内容……
</article>

怎么在本地试搜索：Pagefind 的索引和搜索框资源，只有 npm run build 之后才生成（落在 dist/pagefind/），而 npm run dev 的开发服务器并不服务 dist/，所以开发模式里搜不到是正常的，别慌。想本地看效果，先 npm run build 再 npm run preview（preview 服务的是构建产物），打开预览地址就能搜了。上线之后一切正常。

上线后的搜索页长这样（输入关键词，纯浏览器端实时检索）：

第 7 步：部署上线（Cloudflare Pages）

两种方式任选，推荐第一种，省心、一次配好。

方式 A：接 Git，自动部署

先把项目推到 GitHub（私有仓库就行；还没有仓库的话，先在 GitHub 新建一个空的，再 git push 上去）。
打开 Cloudflare Dashboard，进 Workers & Pages（新版界面可能写作 Workers，入口在侧边栏）→ Create → Pages → Connect to Git。
选中你的仓库，构建配置填这几项：
- Framework preset：Astro
- Build command：npm run build
- Build output directory：dist
- （可选）环境变量 NODE_VERSION 设成 24
点 Save and Deploy。等一两分钟，Cloudflare 会给你一个 https://你的项目名.pages.dev 的免费子域名，打开就是你的站了。

以后每次 git push，Cloudflare 都会自动重新构建部署——写完文章 → push → 自动上线，全程不花一分钱。

方式 B：命令行直接传（不接 Git）

npx wrangler pages deploy dist --project-name=my-site

适合你本地已经 build 好、想直接传上去、不想折腾 Git 的情况。

想绑自己的域名（可选）：去 Pages 项目设置里加自定义域，按提示在 DNS 加一条 CNAME 指到 <项目名>.pages.dev 就行。不绑也没关系，Cloudflare 送的那个免费地址已经能用了。

常见坑（都是我踩过的）

1. 纯静态站别装 Cloudflare 的 Astro 适配器

@astrojs/cloudflare 是给“在 Workers 上跑动态逻辑”准备的。纯静态项目装上反而会拖进来一堆多余的本地模拟，构建变慢还可能报些莫名其妙的错。纯静态根本用不着它，把构建产物直接托管给 Pages 就行。

2. Astro 的样式是有作用域范围的

Astro 每个 .astro 文件里的 <style> 默认只作用于当前文件（它会自动加随机属性做隔离）。所以用普通写法，是匹配不到 JS 动态生成的内容的（比如 Pagefind 搜出来的结果 DOM）。要让样式管到动态内容，得用 :global() 把选择器包起来。

3. 记得限定搜索范围

不标 data-pagefind-body 的话，Pagefind 会把每页的导航、页脚全收进索引。记得给正文打标记（见第 6 步）。另外注意：当全站还没有任何内容页时（比如刚建站、一篇文章都还没写），Pagefind 会退回去索引整页——等你写了第一篇带 data-pagefind-body 的文章，导航页自然就被排除掉了。

4. 列表没内容时记得兜底

文章还没写、集合是空的时候，直接去遍历会渲染成一片空白。用条件渲染判断一下再输出就行（写法看第 5 步列表页里那个 posts.length > 0 ? … : …）。

5. Pagefind 的中文搜索，能用但别指望完美

Pagefind 对中文的支持不如英文：它不做词根折叠（搜“部署”不会顺带匹配到“部署中”），个别词还可能因为浏览器分词和建索引时分词对不上而搜不到。这是 Pagefind 的老毛病，不是你配错了。英文内容它表现很好；要是你的中文站特别看重模糊搜索，就得自己再接一套中文分词方案。一般个人博客，能做到“按标题、按关键词搜到主要文章”就够用了。

小结

到这儿，你就白捡了一个能搜全文的个人网站：

内容：写 Markdown，丢进 src/content/
搜索：构建时自动生成索引，访客在浏览器里就能搜
部署：push 一下自动上线，全程零成本
扩展：框架的内容集合是开放的，以后想加作品集、摄影、知识库，照葫芦画瓢再开几个集合就行

先别想太远，把它当成“一个带全文搜索的静态博客”，往里填东西就对了。碰到问题，多翻翻 Astro 文档、Pagefind 文档和 Cloudflare Pages 文档。

Junius 的博客

经典蛋黄莲蓉月饼

饼皮

馅料

做法

重量换算速查

保存

坑

零成本自建网站访问统计（Umami + NAS）

这套东西能给你什么

整体结构

第 1 步：在 NAS 上跑起 Umami

第 2 步：让它能从外网访问

第 3 步：给网站加上统计脚本

第 4 步：在页面底部显示访问数

第 5 步：记得备份

关于速度

写在最后

零成本给静态博客加评论区（Twikoo + Cloudflare）

为什么选 Twikoo

整体结构

第 1 步：部署后端

第 2 步：绑自定义域名（别跳过）

第 3 步：接入前端

第 4 步：管理评论

踩过的坑

实际用下来

写在最后

零成本搭建个人静态网站（Astro + Pagefind）

这套方案好在哪

技术选型（为什么是这几样）

第 1 步：准备本地环境

第 2 步：创建项目

第 3 步：先看懂项目结构

第 4 步：告诉 Astro 你的文章长什么样

第 5 步：建列表页和详情页

第 6 步：加全文搜索（Pagefind）

第 7 步：部署上线（Cloudflare Pages）

常见坑（都是我踩过的）

1. 纯静态站别装 Cloudflare 的 Astro 适配器

2. Astro 的样式是有作用域范围的

3. 记得限定搜索范围

4. 列表没内容时记得兜底

5. Pagefind 的中文搜索，能用但别指望完美

小结

参考文献