Cloudflare/OpenNext 发布前最容易误判的一点，是把本地 Next.js build 当成最终 readiness。对 MakePlans 这种内容站来说，真正的发布检查必须同时覆盖 npm run build、npm run build:cf、公开路由、RSS、sitemap 和未来日期草稿。
这篇是发布门禁主文下的 Cloudflare/OpenNext 平台附录，专门补目标平台差异检查，不重复讲整套发布哲学。
本地绿灯不等于目标平台绿灯
一个项目在本地能构建，并不等于它在 Cloudflare 的运行时、适配层、静态资源、动态路由和环境变量上都已经准备好。尤其是同时有内容页、API、OAuth、支付回调时，检查面会被放大。
所以这篇的第一条规则很简单：npm run build 和 npm run build:cf 证明的是两件事。前者证明 Next.js 应用能在本地完成构建，后者证明 OpenNext/Cloudflare 目标链路没有被运行时差异打断。
先把两个构建结果分开记录
发布记录里要同时写下本地构建和 Cloudflare 目标构建的结果。一个证明应用代码能过 Next.js 构建，另一个证明 Workers 运行时、OpenNext 适配层和静态资产输出没有在目标平台断掉。
检查面要分成构建、路由、环境和内容
- 构建层：本地 build 和目标平台 build 都要通过。
- 路由层：静态内容、动态 API、回调路径、404、RSS 和 sitemap 都要确认。
- 环境层：生产变量、密钥、回调地址和 feature flag 要逐项核对。
- 内容层：
content/posts/*.mdx、src/content/public-site.generated.ts和未来日期草稿不能误公开。
只看首页能不能打开，是最容易制造安全感的检查。真正需要确认的是：哪些页面静态生成，哪些路径动态执行，哪些生成文件会影响公开索引。
内容生成逻辑也属于发布风险
内容站改了 MDX 生成逻辑以后，Cloudflare 发布前不只要看文章页，还要看 generated data、static params、sitemap、RSS 和搜索索引是否一致。
这次六关优化就必须把日期固定到 PUBLIC_SITE_CURRENT_DATE=2026-04-29 来验证：未来日期草稿不能进入 public collections、详情页、RSS 或 sitemap。任何一个暴露未来草稿，都是发布质量问题。
Checklist 要记录观察结果，不只是命令
把发布检查分成“本地能不能过”和“目标平台能不能过”两张表。每一项后面都写它证明什么：构建证明什么，路由证明什么，RSS/sitemap 证明什么，失败时如何暂停。
如果第二张没有跑完，就不要用第一张的绿灯说服自己可以发布。Cloudflare/OpenNext 的风险常常在适配层和运行时差异里，不在命令名字本身。
不要写成部署命令摘录
这篇如果写成部署命令摘录，会让读者以为跑过命令就等于发布安全。Cloudflare/OpenNext 的风险常常在命令之外：运行时适配、环境变量、动态回调、静态生成和内容公开边界。
质量门是：读者能不能用它检查目标平台上的真实发布路径。如果文章只复述命令，不解释每个命令后面要观察什么，它就不够用。