Rakazo Pages

一个 Worker、一个域名、路径即页面。聊天里生成的每个页面都是一个 slug，不再占用新的 Pages 项目。

域名 ‑ 运行时 Cloudflare Workers 存储 Workers KV 页面数 ‑

为什么不是一个页面对应一个 project

每个 Cloudflare Pages 项目 = 一次独立部署 + 一个子域 + 一份构建记录。发几十个页面就会把项目列表塞满，而且每页都要重新走一遍部署流程。 这里改成：Worker 只部署一次，页面正文存进 KV，用 /<slug> 路由。新增页面 = 一次 KV 写入，秒级生效，Worker 不动。

请求路径

1
GET /索引页：一次 KV list() 读出所有页面的标题/描述/标签，自带搜索框。
2
GET /<slug>读 page:<slug> → 返回 HTML，自动注入左下角「← Rakazo Pages」返回徽标。
3
GET /_list.json机器可读的页面清单，方便其他 bot 或脚本发现页面。
4
GET /<slug>?json=1返回该页原始记录（标题、标签、HTML 源）。

发布一个页面

PUT /accounts/{account}/storage/kv/namespaces/{ns}/bulk
[{
  "key": "page:my-report",
  "metadata": { "title": "周报", "description": "…", "updatedAt": "2026-11-01T06:00:00Z", "tags": ["report"] },
  "value": "{\"title\":\"周报\",\"html\":\"<!doctype html>…\"}"
}]

Worker 本身没有任何写接口 —— 它只读 KV，所以页面内容无法被外部篡改；发布动作由持有 Cloudflare 凭据的一侧完成。

实时检查

下面这段是页面里真实运行的 JS，直接请求本站 /_list.json：

加载中…

性能与缓存

环节行为
边缘缓存页面 300s，索引 30s，命中 Cache API 直接返回
KV 读冷路径一次读；索引只读 metadata，不读正文
失效改写 KV 后最多 300s 生效（ETag 随 updatedAt 变化）
← Rakazo Pages