- 学习结果
- 确定前端框架、数据库、认证、部署、监控和 AI 编程工具组合。
- 时长
- 90-120 分钟
- 难度
- 开发准备
- 核验
- 已核验 2026-10-01 · 下次复核 2026-10-31
正文
技术栈从交付形态倒推。公开内容和目录可在构建时生成页面；频繁更新的个性化数据需要运行时处理。先列用户动作、更新频率和敏感信息，再决定静态、服务端或混合渲染，不要因为框架流行就为普通介绍页增加数据库。
前端框架应与维护能力匹配。Astro适合以内容为主的页面并按需加入交互；其他框架也能交付内容站，差异在于团队熟悉度、路由、部署适配和依赖。先做列表、详情和一次数据更新，实际比较构建与调试过程，而不是只比较下载量。
数据库与认证共同决定权限边界。仅保存公开资料时可先用版本管理中的数据文件；用户私有记录、并发写入和订单通常需要持久存储。使用托管数据库也要理解访问策略、迁移、备份和服务端密钥，不能把管理员权限放进浏览器。
部署环境限制运行能力。静态托管、函数和长驻进程的执行时间、文件系统及网络能力不同。选平台前检查框架适配、环境变量、定时任务和日志；Cloudflare既有Pages项目按对应文档维护，新项目评估Workers等方案，不把其他平台配置原样搬过去。
外部服务减少开发量也增加依赖。认证、邮件、支付、搜索分别记录费用、配额、出口格式和故障影响。早期只保留当前路径必需的服务；若账号不是交付前提，不必先接认证。评估退出时能否导出数据，而不是只看免费额度。
选型记录保留取舍与切换条件。为每个组件写选择理由、替代方案、月成本和何时需要升级。先跑通一次构建与部署，再确认日志和备份位置。技术栈不是一次性完美决策，后续根据真实性能和维护问题调整，避免每月迁移框架。
学习步骤
- 内容站、目录站、工具站优先 Astro/Next.js 静态或混合渲染。
- SaaS 产品优先选择熟悉框架，不要为了流行度频繁换栈。
- 数据库和认证要一起考虑，Supabase 适合快速做 Postgres + Auth。
- 部署选择要能持续排障。Cloudflare 目前建议新项目优先 Workers；既有 Pages 项目可继续按对应文档维护，其他平台也应按实际架构判断。
- 把 AI 编程工具纳入流程：需求拆解、代码生成、测试、重构、文档都可以交给 AI 辅助。
场景拆解
为公开目录站选技术栈
模拟产品包含公开项目列表、详情、分类筛选和投稿审核。展示内容按天更新，投稿需要保存，首版不提供用户账号或订阅。
- 以静态页面展示公开目录，用独立接口接收投稿。
- 保留现有审核流程，明确投稿记录存储与管理员权限。
- 用一条测试投稿跑通保存、审核、更新与部署，确认日志位置。
最终选择必须解释静态展示与写入接口各负责什么；无数据库的展示层不意味着提交数据无需持久存储。平台适配与实际构建结果比框架口号更重要。
补充材料
思维导图、练习、清单和参考资料可按需展开。
01 思维导图和离线文件
适合读完后下载到自己的知识库里继续整理。
按产品形态选择技术栈
- 内容、目录、工具：静态或混合渲染
- SaaS：熟悉框架与核心业务
- 数据库与认证：联合设计
- 部署与日志：支持持续排障
- 备份与维护：控制长期成本
技术选型表的关键字段
- 前端框架与渲染方式
- 数据库、认证与权限方案
- 部署平台、环境与日志
- AI 工具与验收方式
快速交付与复杂度的取舍
- 流行度不等于维护能力
- 过早微服务增加运维成本
- 自建认证增加安全与维护责任
- 平台建议需要结合现有架构判断
02 实践练习
根据文章内容记录自己的判断与依据。
为公开目录站选技术栈
将公开页面、投稿写入与人工审核分别匹配到运行环境，跑通一条垂直路径，并留下费用、日志和退出办法。
练习场景
模拟产品包含公开项目列表、详情、分类筛选和投稿审核。展示内容按天更新，投稿需要保存，首版不提供用户账号或订阅。
准备材料
- 准备页面与数据流清单。
- 阅读候选平台与框架对应部署文档。
检查点
- 哪个服务不是首版交付必需，移除后是否仍能完成用户任务？
练习步骤
01 / 分类运行需求
时间： 20-30 分钟
目标： 分开页面生成与用户写入
操作：
- 标注公开、私有、只读和写入数据。
- 列出每种数据的更新频率。
参考结果： 列表可构建生成，投稿在请求时保存。
预期产出： 渲染与存储需求表。
检查： 没有把静态站误认为无需处理写入。
02 / 跑一条垂直路径
时间： 20-30 分钟
目标： 用真实适配验证选型
操作：
- 生成列表和详情并部署预览。
- 通过接口保存测试投稿并查接收记录。
参考结果： 提交→保存→审核→重建公开列表。
预期产出： 可访问路径与服务清单。
检查： 平台支持全部必要执行能力。
03 / 记录维护成本
时间： 20-30 分钟
目标： 形成可解释的选择
操作：
- 记录构建、日志、备份和费用。
- 为新增认证写明确触发条件。
参考结果： 只有需要私有记录时才引入登录。
预期产出： 选型决策与升级条件。
检查： 能说明各服务用途和退出办法。
完成检查
- 没有把静态站误认为无需处理写入。
- 平台支持全部必要执行能力。
- 能说明各服务用途和退出办法。
03 清单、模板和关键词
用于项目记录和自查。
项目记录
框架选择：____数据库方案：____认证方案：____部署平台：____日志监控：____AI 编程工具：____备份策略：____
技术决策单
页面类型：公开目录；更新频率：每日；写入：投稿接口；私有数据：提交者联系方式；框架：；托管：；存储：；日志：；备份：；选择理由：；替代方案：；退出与导出办法：；需要重新评估的条件：。
依赖预算表
服务：；用途：；免费额度：；预计月成本：；敏感密钥位置：；配额耗尽行为：；导出格式：；替代路径：。例如邮件服务故障不应丢失投稿，保存成功与通知成功应是两个可追踪结果。
关键概念
- 框架选择
- 数据库方案
- 认证方案
- 部署平台
- 日志监控
- AI 编程工具
- 备份策略
容易误判
- 过早微服务
- 过早自建用户系统
- 没有 staging 环境
- 没有日志和错误追踪
- 依赖 AI 写代码但不验收
04 工具和参考资料
本篇涉及的工具和参考链接。
可参考工具
- Astro
- Next.js
- Supabase
- Cloudflare Pages
- Vercel
- Codex
- Cursor