- 学习结果
- 为自己的产品写出一份选型记录：前端、数据与认证、部署、外部服务和 AI 编程工具各选什么、为什么、什么时候考虑更换。
- 时长
- 90-120 分钟
- 难度
- 开发准备
- 核验
- 已核验 2026-10-01 · 下次复核 2026-10-31
正文
技术选型最容易陷入两个极端：一种是纠结哪个框架最好，研究了两周还没开始写代码；另一种是看到什么流行就用什么，一个简单的介绍页也接上数据库、认证和三个云服务。
对独立开发者来说，好的技术栈只有一个标准：你能把它做出来、部署上线，出了问题能自己查出原因。这篇讲怎样从产品的交付形态倒推出技术栈，并把选择的理由记下来。
先看交付形态，再选技术
先回答三个问题：
- 页面内容多久变一次，是否因人而异？ 公开的文章、目录、产品介绍，所有人看到的都一样，可以在构建时提前生成成静态页面。每个用户看到的都不同（比如“我的订单”），就需要在请求时生成。
- 有没有需要保存的用户数据？ 表单提交、订单、用户设置，需要能长期保存和并发写入的存储。
- 有没有需要保密的规则或密钥？ 支付校验、调用付费 API、管理员操作，必须放在服务器端执行。
| 产品类型 | 常见形态 | 需要的部分 |
|---|---|---|
| 介绍页、作品集、博客 | 纯静态 | 前端框架 + 静态托管 |
| 目录站、资料库，加投稿 | 静态页面 + 少量写入接口 | 上面的基础上，加一个函数和一个数据库 |
| SaaS、会员产品 | 页面 + 账号 + 订单 | 数据库、认证、支付、服务器端逻辑 |
| 长时间任务、实时连接 | 长驻服务 | 能常驻运行的服务器或容器 |
不要因为“以后可能要”提前加东西。一个介绍页加数据库，只会多一个要维护、可能出错的部分。
前端框架：选你能维护的
以内容为主的网站，Astro 是很顺手的选择：默认生成静态页面，需要交互的地方再按需加入组件。应用型的产品，Next.js 的生态和资料更多。但比框架名气更重要的，是你和你的 AI 助手对它熟不熟悉。
判断方法很简单：用候选框架做一个最小的列表页和详情页，改一次数据，构建并部署。走完这一圈，你对它的路由、构建和调试方式会有比看对比文章更真实的感受。
数据和认证要一起考虑
只有公开内容的话，数据可以就放在代码仓库的文件里，改完重新构建即可。一旦有用户的私有数据、多人同时写入或者订单，就需要数据库。托管数据库（比如 Supabase，或者 Cloudflare 的 D1）省去了自己运维服务器的麻烦，但你仍然要弄懂几件事：谁能读写哪些数据（访问策略）、表结构怎么改（迁移）、数据怎么备份，以及哪些密钥只能放在服务器端。管理员权限的密钥，绝不能出现在浏览器能拿到的代码里。
认证和数据库通常是一起决定的：用户是谁，决定了他能看到哪些数据。如果第一版根本不需要账号，就先别接认证。
部署平台：看清它能跑什么
不同的托管方式，能力差别很大：静态托管只分发文件；函数（serverless）能处理请求，但有执行时长和运行环境的限制；长驻服务能跑后台任务和实时连接，但要自己管更多东西。选平台前，确认它对你的框架有官方支持，并检查环境变量、定时任务和日志在哪里看。
平台的推荐路线也会变。以 Cloudflare 为例，它的 Pages 文档首页现在明确写着“Workers 支持大多数 Pages 的使用场景，功能更全”，建议新项目从 Workers 开始，并提供了从 Pages 迁移的指南。已经在 Pages 上运行的项目可以继续按对应文档维护，新项目则应该先看 Workers 的方案。这类建议以选型当天的官方文档为准，不要照搬旧教程。
图：Cloudflare Pages 官方文档首页截图，截取于 2026-10-24，内容以官方当前页面为准。
用 Astro 部署到 Cloudflare Workers 时，纯静态站点不需要适配器，构建后直接部署产物；需要服务端渲染时才加入 Cloudflare 适配器。这正是“交付形态决定配置”的例子。
外部服务：省开发量，也增加依赖
认证、邮件、支付、搜索、错误监控，每接一个外部服务，都能少写很多代码，但也多了一个依赖。每个服务记下四件事：费用和免费额度、超出额度后会怎样、数据能否导出、它出故障时你的产品会受什么影响。
早期只保留当前必需的服务。选服务时，不要只看免费额度，还要看将来想离开时，数据能不能完整导出。
AI 编程工具：选一个主力
Cursor、Codex、Claude Code 这类工具差别在于工作方式：有的在编辑器里配合你写，有的在终端里独立完成整块任务。选一个作为主力，熟悉它的用法，比来回切换效率高。在项目里写一份简短的说明文件，交代项目结构、常用命令和约定，AI 每次都能按同样的规矩工作。
把选择写下来
为每个组件写一行记录：选了什么、为什么、考虑过什么替代、每月大概花多少钱、遇到什么情况才考虑更换。这样几个月后回头看，你知道当初的取舍；有人推荐“更好的框架”时，你也能判断现在的问题是不是真的需要换。
技术栈不需要一次就完美。先跑通一次完整的构建和部署，确认日志和备份在哪里，后面根据真实遇到的性能和维护问题再调整。最怕的是每个月都在迁移框架，产品却没有进展。
学习步骤
- 列出产品的主要页面和用户动作，标出哪些内容所有人都一样、哪些因人而异。
- 标出需要保存的数据和需要保密的规则，判断是否需要数据库和服务器端逻辑。
- 选一个你或你的 AI 助手熟悉的前端框架，做一个最小的列表页和详情页。
- 查阅候选部署平台对该框架的官方指南，确认环境变量、日志和定时任务的位置。
- 跑通一次完整的构建和部署，并找到线上日志在哪里看。
- 为每个组件写一行选型记录，包括更换条件。
场景拆解
为一个带投稿的目录站选型
小许要做一个独立开发工具目录：公开的列表、详情和分类筛选，每天更新几条；访客可以投稿，管理员审核后公开。第一版没有用户账号，也不收费。
- 交付形态：列表和详情所有人都一样，可以构建时生成静态页面；投稿需要在请求时保存。
- 数据：公开的工具资料放在仓库的数据文件里；投稿记录要存在数据库里，因为它要被写入、被审核，而且包含投稿人的联系方式，不能公开。
- 组合：Astro 生成静态页面；一个函数接收投稿，写入托管数据库；管理员审核后更新数据文件并重新构建。
- 部署：查阅官方文档后，新项目选择 Workers 方案；确认了函数日志和数据库备份的位置。
- 验证：用一条测试投稿跑通保存、审核、更新和部署的全过程。
静态展示不等于不需要存储：页面是静态的，但投稿必须持久保存。选型说明里要讲清楚这两部分各由谁负责。
补充材料
思维导图、练习、清单和参考资料可按需展开。
01 思维导图和离线文件
适合读完后下载到自己的知识库里继续整理。
从交付形态倒推
- 内容是否因人而异
- 有没有要保存的用户数据
- 有没有要保密的规则
各部分怎么选
- 前端：选你能维护的
- 数据与认证：一起考虑
- 部署：看清平台能跑什么
- 外部服务：记录费用与导出
选型的习惯
- 先跑通一次完整路径
- 以当天的官方文档为准
- 写下理由和更换条件
- 不频繁迁移框架
02 实践练习
根据文章内容记录自己的判断与依据。
为你的产品写一份选型记录
用你自己的产品或上面的目录站，完成一份选型记录，并跑通一条完整路径。
准备材料
- 产品的页面清单和用户动作清单。
- 候选框架和部署平台的官方文档。
练习步骤
01 / 判断交付形态
时间： 20 分钟
操作：
- 给每个页面标上“所有人一样”或“因人而异”。
- 列出所有需要保存的数据和需要保密的规则。
产出： 一张交付形态表。
检查： 每一项需要保存的数据都有明确的去处。
02 / 跑通一条路径
时间： 60 分钟
操作：
- 用选定的框架做一个最小页面，部署到选定的平台。
- 如果有写入，跑通一次写入，并在线上找到对应的日志。
产出： 一个线上可访问的地址和一条日志记录。
检查： 知道构建失败、函数报错时分别去哪里看。
03 / 写选型记录
时间： 30 分钟
操作：
- 为每个组件写下选择、理由、替代方案、月成本和更换条件。
- 标出哪个服务不是第一版必需的，考虑先去掉。
产出： 一份选型记录。
检查： 每个外部服务都写了数据能否导出。
完成检查
- 能说明每个组件为什么在这里，去掉它会怎样。
- 至少跑通过一次完整的构建和部署。
- 知道日志和备份的位置。
03 清单、模板和关键词
用于项目记录和自查。
选型记录模板
| 组件 | 选择 | 理由 | 替代方案 | 月成本 | 数据能否导出 | 更换条件 |
|---|---|---|---|---|---|---|
| 前端框架 | ||||||
| 部署平台 | ||||||
| 数据库 | ||||||
| 认证 | ||||||
| 邮件 | ||||||
| 支付 | ||||||
| 错误监控 | ||||||
| AI 编程工具 |
关键概念
- 静态生成：构建时提前生成页面，所有人看到的都一样
- 服务端渲染：请求时生成页面，可以因人而异
- 函数：按请求运行的服务器端代码，有时长和环境限制
- 托管数据库：服务商负责运维的数据库，访问策略和备份仍需你管理
- 环境变量：存放配置和密钥，区分公开和机密
- 选型记录：写下选择、理由和更换条件
容易误判
- 为了“以后可能要”提前加数据库和认证
- 只比较框架热度，不亲手跑一遍
- 把管理员密钥放进浏览器能拿到的代码
- 照搬旧教程，没有核对平台当前的推荐路线
- 只看免费额度，不看数据能否导出
- 频繁迁移框架，产品没有进展
04 工具和参考资料
本篇涉及的工具和参考链接。
可参考工具
- Astro
- Next.js
- Supabase
- Cloudflare Workers
- Vercel
- Cursor
- Codex