路线图与设计取舍

已经完成的

• 动静分离：单页静态 + 列表动态；
• 三级降级生成；
• 独立 Worker CMS（文章、分类、媒体、设置、用户、评论）；
• 风格系统：目录即风格、在线切换、可视化编辑；
• 评论闭环：提交、审核、回写 WordPress；
• 缓存治理：KV 只留站点设置，列表走 Cache API；
• 多出口：S3 / R2 / GitHub / Netlify / Vercel / FTP / WebDAV / 本地。

明确的取舍

不做整站静态化

整站静态意味着每次发文都要重建首页、分类、标签、归档、分页。文章一多，组合爆炸。

这里只静态化"发布后基本不变"的单页，列表交给 D1。代价是列表页每次请求要查库，但有了边缘缓存，成本可以接受。

不拆成三个项目

插件里其实有三条线：Worker CMS 对接、WP 静态化本体、通用托管。理论上可以拆成三个插件。

但不拆的理由是：用户装一个插件就能跑通全链路。拆开之后，版本兼容、配置传递、升级顺序都会变成用户的问题。

现在的做法是在插件内部做分层，对外保持一体化。

不做双向实时同步

WordPress 在内网、CMS 在 Cloudflare，两边都可能离线。做双向实时同步的复杂度远高于收益。

现在的规则是：

• WordPress → CMS：自动推送（md 文章除外）；
• CMS → WordPress：手动拉取 / 导出；
• 冲突时以 content_format='md' 作为"线上托管"标记，WP 不覆盖。

不做评论验证码

验证码会显著降低评论转化率。现在用蜜罐 + 最小停留时间 + 内容规则 + IP 限流，对个人站够用。垃圾评论多了再考虑接第三方。

接下来想做的

• 单篇新建性能：目前逐条 D1 往返，目标是把创建耗时压到 1 秒内；
• 多站点托管：一个 Worker 服务多个域名；
• 更好的迁移工具：documents → posts、WP → CMS 的一键迁移；
• 插件发布流程：版本号、更新日志、下载页自动化。

怎么参与

• 用这个演示站的后台提问题（评论会进审核队列）；
• 把你抓的风格包分享出来；
• 报告 bug 时带上：页面 URL、操作步骤、预期与实际结果。