技术选型怎么做
技术选型不是选最热门的
Section titled “技术选型不是选最热门的”技术选型是在约束下做取舍。对新手或小项目，最重要的通常不是“理论上最强”，而是能快速完成、容易理解、资料多、出问题有人能帮你。
先回答七个问题
Section titled “先回答七个问题”- 用户是谁，主要在手机还是桌面使用？
- 是静态内容、表单，还是需要登录和多人协作？
- 数据是否需要保存，数据之间有什么关系？
- 是否需要实时消息、文件上传、支付或第三方 API？
- 谁来维护，能接受多少服务器和依赖管理？
- 预算、地区、合规和可用性要求是什么？
- 如果项目失败，怎样迁移或停止？
| 场景 | 适合的起点 | 说明 |
|---|---|---|
| 官网、文档、博客 | 静态 HTML / Astro / Next.js 静态输出 | 速度快、成本低、维护简单 |
| 交互式单页应用 | React、Vue 或 Svelte + 托管平台 | 适合表单、后台和复杂交互 |
| 有登录、数据和业务规则 | 前端 + 后端 API + 托管数据库 | 先明确数据和权限，再选框架 |
| 需要长期运行的服务 | 容器或云服务器 | 需要日志、备份、监控和升级计划 |
不要为了一个简单表单先引入微服务、消息队列和复杂部署；也不要在有真实用户和数据时只靠本地文件。
用“最小可行架构”开始
Section titled “用“最小可行架构”开始”先画出用户、页面、接口和数据的最小关系，确定一个能让真实用户完成核心任务的版本。等真实问题出现，再增加缓存、异步任务、搜索或拆分服务。
让 AI 做技术比较
Section titled “让 AI 做技术比较”要求它使用统一维度：学习成本、开发速度、生态、性能、部署复杂度、费用、可迁移性、团队能力。让它列出“不选择某方案的理由”，可以减少只听优点的偏差。
最终至少留下：
- 一页方案说明；
- 关键假设和不确定性；
- 选择与备选方案；
- 第一个可验证里程碑；
- 未来可能更换的边界。