不用服务器，也能认真做一个网站

很多个人网站一开始就背上了不必要的负担：购买云主机、安装系统补丁、维护 Nginx，再为一篇偶尔更新的文章守着数据库。问题不在于这些技术不好，而在于它们解决的是另一类问题。

如果网站的输出可以提前确定，那么运行时服务器并不是必需品。文章、文档、作品集和许多浏览器工具，都可以在发布前生成 HTML，再交给 CDN 直接分发。这就是 Cloudflare Pages 最适合的场景。

一次访问发生了什么

传统动态网站收到请求后，通常要执行程序、查询数据库，再拼出 HTML。静态网站把这些工作提前到构建阶段：

Markdown + 模板 → 构建 → HTML/CSS/JS → CDN 节点 → 浏览器

访问者拿到的是已经完成的结果。少了运行时计算和数据库连接，故障面明显缩小；文件可以被边缘节点长期缓存，世界各地的访问延迟也更稳定。

这里的“静态”不等于页面不能交互。搜索、图片压缩、格式转换和 Markdown 预览都能通过浏览器 JavaScript 完成。静态描述的是部署产物，不是视觉或行为。

为什么选择 Pages

Cloudflare Pages 把几个常见环节组合在一起：构建、部署、HTTPS、CDN、预览地址与自定义域名。对内容站来说，它的价值不是某一个惊艳功能，而是把日常运维压缩成一次可重复的发布动作。

一个稳妥的首发配置通常只有这些：

项目	建议
构建命令	npm run build
输出目录	dist
Node 版本	固定在项目配置中
正式域名	使用自己的主域名
预览部署	保留，用于上线前检查

不要只在控制台里记住配置。Node 版本应写进 .nvmrc，构建命令应写进 package.json，响应头应放在 _headers。这样换一台电脑或半年后重新部署，项目仍然能说明自己需要什么。

Direct Upload 与 Git 集成

Pages 有两种常用发布方式。Git 集成适合持续写作：推送代码后自动构建，每个变更都有预览。Direct Upload 则适合不想绑定代码托管平台，或需要由本地脚本控制发布的场景。

使用 Wrangler 时，核心命令很短：

npx wrangler pages deploy dist --project-name your-project

真正重要的是命令之前的检查。部署脚本应先选择约定的 Node 版本、安装锁定依赖、完成类型检查和生产构建；任何一步失败都要停止，而不是把半成品推到线上。

哪些情况不适合纯静态

当功能依赖私密 API 密钥、需要可靠地写入数据库、处理持续连接或执行长时间后台任务时，纯静态页面就不够了。可以把少量动态能力放进 Cloudflare Workers 或其他 API 服务，但不要为了“保持纯静态”而把秘密塞进前端代码。

判断方法很直接：如果所有访问者拿到相同的页面骨架，且计算可以在构建时或用户浏览器中完成，静态优先通常值得。如果每次请求都必须根据私有数据产生不同结果，就需要服务端参与。

好架构不是使用最少的技术，而是让每一项技术都承担清楚、必要的职责。

从内容站开始，先让发布流程简单到愿意持续更新。等真正出现动态需求，再增加对应能力。这比一开始为想象中的规模购买复杂度，更接近长期可维护的网站。