这个博客：从迁移笔记到持续发布

要解决什么问题

这个项目把原有 WordPress 文章迁移为 Markdown，同时保留旧链接，并逐步加入学习线路、交互实验、个人记录和作者编辑后台。它需要兼顾两种节奏：长文适合构建后稳定分发，随心记与日报则需要随时修改或撤回。

本文描述仓库中的实现结构。涉及本次新增代码的能力，需要构建和部署后才会在线上生效；这里不把本地实现等同于已上线，也不提供没有测量依据的性能增幅、访问量或业务收益。

部分	职责	代码入口
Astro 静态站点	文章、学习线路、实验、项目案例与搜索页面	`src/pages/`
Markdown 内容	文章和案例正文，构建时校验元数据	`src/content/`、`src/content.config.ts`
作者工作台	编辑、草稿恢复、媒体和发布操作	`studio/public/studio/`
Worker API	作者认证、公开内容接口、评论与阅读助手	`studio/src/worker.mjs`
D1 与 R2	结构化记录、用量计数与媒体文件	`studio/migrations/`、`studio/src/media.mjs`
Pagefind	构建后生成站内全文搜索索引	`package.json`、`src/scripts/search.js`

文章访问主要读取静态 HTML；动态记录由浏览器调用公开接口获取。作者工作台通过后台接口处理草稿和发布。两种内容沿不同路径交付，减少了每次修改短记录都重建全站的需要。

仓库把作者的编辑状态与公开内容分开维护。文章发布涉及代码仓库、构建和部署，后台保留任务状态以便跟踪结果。候选构建成功后再切换发布入口，使失败任务可以保留诊断信息。

工作台编辑器同时保留按作者和文章隔离的本机恢复副本；满足字段要求时再自动保存服务端草稿。慢请求完成时，通过编辑版本判断期间是否发生了新输入，避免把更新的正文误判为已保存。

相关实现可以从 studio/public/studio/editor.js、studio/public/studio/draft-recovery.js 和 .github/workflows/ 查起。部署凭据只属于运行环境，不进入公开文章和静态产物。

动态列表不打包为静态快照，也不把正文存入浏览器的持久缓存。边缘缓存使用数据库维护的公开内容版本作为缓存键的一部分，内容变更后读取新版本。媒体读取先检查当前可见性，再使用缓存的文件字节。

这套设计的重点是：修改公开状态时，旧缓存不应继续决定访问权限。代价是公开接口仍需要查询当前版本或可见性，而不能完全依赖文件缓存。已经显示在读者屏幕上或被读者自行保存的内容，不可能由服务端远程收回。

相关入口是 studio/src/worker.mjs、studio/src/media.mjs 和 studio/migrations/0013_public_versions_and_chat_usage.sql。该迁移必须先于依赖它的 Worker 版本部署。

学习线路按知识依赖整理文章，并在本机记录阅读完成状态和小节位置。“我的学习”汇总最近阅读、收藏与稍后读；记录使用浏览器存储，默认不会跨设备同步。目录映射只展示当前已公开的文章，并兼容文章元数据中的历史 slug。

前台阅读达到最低时间且到达正文末尾后，文章才会自动记为已读；读者也可手动调整。收藏与稍后读由读者主动操作，不会因为点开文章就自动加入。

实验室把梯度、卷积、广播、编码以及 HTTP、会话和 SQL JOIN 放进同一个交互工作台。JavaWeb 实验使用固定演示数据与确定性计算，帮助观察请求、权限和连接条件的差别，不接入真实业务数据库。

站内搜索使用构建时生成的 Pagefind 索引。客户端按请求序号处理结果，输入变化时立即使旧请求失效，分页继续加载直到展示全部命中项。

阅读助手从公开内容生成知识包，动态记录与静态文章分别检索。模型请求通过 D1 原子计数限制用量，避免 Worker 重启或多实例让进程内计数失效。接口故障时返回明确的失败状态。