Nuxt 部署到 Cloudflare Pages
本站采用 Nuxt 4 混合部署：公开页面预渲染到 dist，Pages Function 只把 /api 请求交给 Nitro。这样可以减少运行时工作，但也意味着 404.html、robots.txt、重定向和响应头都属于应用正确性的一部分。
1. 为什么选择 Cloudflare Pages 部署 Nuxt？
仓库使用 Nitro 的 cloudflare-pages 预设构建。路由规则预渲染公开页面，并让服务端 API 保持动态。生成的 Pages Function 只声明 /api 和 /api/*，普通 HTML 与哈希资源直接作为静态文件交付。
- 静态交付：HTML、JavaScript、CSS、站点地图和政策文件来自
dist。 - 动态 API：身份、支付、AI 等服务端接口经过 Function，并计入适用的 Workers 限制。
- 运行时绑定：D1 等变量来自 Cloudflare 请求上下文，生产环境不能只假设
process.env一定存在。
2. 边缘缓存与 Cache-Control
带哈希的 Nuxt 资源适合长期缓存，因为内容变化会产生新文件名；HTML 和政策文件则需要更短、更明确的缓存。本项目为 /robots.txt 设置一小时缓存并要求重新验证，预渲染 HTML 采用 Pages 静态资源行为。
🚀 优化技巧
不要把同一个缓存头套到所有路由。账户状态、结账响应和 API 输出与不可变资源有不同的隐私和新鲜度要求。发布后应分别检查唯一部署 URL 与自定义域名的响应头。
3. 404 与 robots.txt 陷阱
Cloudflare Pages 文档说明：如果没有顶层 404.html，项目会按单页应用处理，未知路径回退首页并返回 200。这会让缺失的 /robots.txt 变成 HTML，也让不存在的 URL 看起来可索引。修复方式是发布真正的顶层 404、把 robots 预渲染到输出，并在 _redirects 中显式声明旧路径跳转。
4. 发布验证清单
- 构建后检查
dist/404.html、dist/robots.txt、dist/_headers和dist/_redirects。 - 使用普通 UA、Googlebot 和 Mediapartners 核对 robots 返回 200、
text/plain、有效规则和站点地图地址。 - 确认旧的
/en/...以 301 跳到默认英文路径，任意未知路径返回 404。 - 对比部署 URL 和自定义域名的状态、当前资源哈希与真实工具交互。
- 完成后再做 Search Console 实时检查和代表页面索引请求。
5. 边缘安全
Cloudflare 提供网络安全能力，但部署本身并不保证可用性。WAF 功能、限流、身份验证、密钥管理和应用层校验都需要根据套餐主动配置并测试。
结论
Cloudflare Pages 与 Workers 是 Nuxt 的一种部署选择。应根据应用需求评估构建限制、Worker 配额、绑定、可观测性、区域依赖和成本。