技术选型全景图：一张图看懂前端/后端/数据库/部署/AI
建立全栈技术栈的全局视野，理解每一层的主流选项、各自的优缺点和适用场景，学会根据产品类型做合理选型
- 全栈技术栈的五层模型：前端 → 后端 → 数据库 → 部署 → AI 能力
- 了解每一层的主流技术选项，以及它们的核心优缺点和适用产品类型
- 没有最好的技术，只有最合适的技术。选型就是权衡。
- 就用「产品类型 → 技术栈」的映射思维。别盲目追新，别搞过度工程。
全栈技术栈的五层模型
一款现代 App，从用户点击到数据存储再到 AI 响应，通常经过五层。每一层都有多种技术可选，选型就是在每一层选一个最合适的，然后把它们组合起来。
每一层独立选型，再组合成完整技术栈
这五层是逻辑分层，不是物理分层——小团队的一个 Node.js 服务可能同时承担「后端」和「AI 代理」两层，一个 PostgreSQL 可能同时存「业务数据」和「向量数据」（通过 pgvector 插件）。分层是为了帮你想清楚「每个问题该在哪一层解决」，而不是强迫你每层都用不同的技术。
第1层：前端——用户直接接触的界面
前端决定了用户「看到什么、怎么操作」。选型主要看你的产品是跑在什么设备上：
前端技术选型详解
Web 前端（浏览器里跑）
选前端框架就按需求来：React 生态最大、就业最多，适合复杂交互项目；Vue 上手简单、中文文档全，适合中小项目；Svelte 是编译时框架，包体积小、性能好，适合追求极致性能的项目；Solid 是细粒度响应式，性能接近原生，适合高交互场景。
适用产品：官网、后台管理系统、SaaS工具、内容社区、需要「一次开发多端运行」的产品。优势是开发快、更新无需审核、跨平台。劣势是移动端体验不如原生、无法调用部分系统能力。
原生移动端（iOS / Android）
iOS 用 Swift + SwiftUI，Android 用 Kotlin + Jetpack Compose。优势：性能最好、能调用全部系统能力（相机、蓝牙、推送、HealthKit）、用户体验最流畅。劣势：两套代码、两套团队、上架审核慢、更新需要用户手动升级。适用产品：对性能和系统能力要求极高的 App（游戏、AR、健康、金融交易）。
跨平台（一套代码跑 iOS+Android）
Flutter（Dart 语言、自绘引擎、性能接近原生、UI 一致性好、适合 2-5 人团队）、React Native（JS/React 生态、热更新快、适合已有 Web 团队）、Capacitor/Ionic（把 Web 代码打包成 App、开发最快、适合内容型和工具型 App，本课程的朋友好学 App 就是 Capacitor 方案）。一套代码多端，省人省钱。性能和系统能力不如原生，复杂动画可能卡顿。
桌面端
Electron 是用 Web 技术打包桌面 App 的方案，生态成熟，VS Code、Figma、Notion 都是它做的，但包体积大、内存占用高。Tauri 是 Rust 加 WebView 的方案，包体积小、性能好，是 Electron 的现代替代。适用产品：开发者工具、内容创作工具、需要本地文件系统访问的桌面应用。
第2层：后端——业务逻辑和数据处理
后端是「看不见的大脑」：处理用户请求、执行业务逻辑、读写数据库、调用第三方服务（支付、短信、AI）。选型主要看你的团队熟悉什么语言、产品的性能要求、生态需求。
除非有明确的性能瓶颈或生态需求，否则「团队最熟悉的语言」就是最好的选择。我见过太多团队为了「用 Go 更酷」「用 Rust 更现代」而放弃熟悉的 Node/Python，结果开发效率下降 3 倍、Bug 率上升 2 倍。语言只是工具，能快速稳定地把产品做出来才是目标。对于 AI 产品，Python 几乎是默认选择——因为 PyTorch、LangChain、所有 AI 库都是 Python 优先。
第3层：数据库——数据的家
数据库选型最容易过度工程。新手一上来就想「我要 MySQL 存业务数据 + Redis 缓存 + MongoDB 存日志 + Elasticsearch 做搜索 + 向量库存 embedding」——一个 MVP 根本不需要这么多。90% 的产品，一个 PostgreSQL 就能搞定全部。
一个 PostgreSQL 就够了。它能做：关系型存储（默认）、JSON 字段（当 NoSQL 用）、全文搜索（tsvector）、时序数据（TimescaleDB 插件）、向量检索（pgvector 插件）、地理空间（PostGIS 插件）。等你的产品真的遇到性能瓶颈（比如 QPS 过万、数据量过亿），再考虑引入 Redis/MongoDB/ES 做专项优化。过早引入多种数据库，只会增加运维复杂度和数据一致性问题。
第4层：部署——让产品跑在互联网上
开发完了，要让用户能访问到，就需要部署。部署选型主要看你的团队规模、运维能力、预算和流量预期。
部署方案选型详解
全托管 PaaS（最省心）
Vercel，前端+Serverless函数，Next.js亲儿子，免费额度大，适合前端为主的产品；Netlify，类似Vercel，静态站+函数；Railway，一键部署后端+数据库，适合小团队；Fly.io，全球边缘部署，适合需要低延迟的应用。这些平台的特点：不用管服务器，自动扩缩容，内置CI/CD。这些平台的问题：流量大了贵，定制化受限。
云服务器（最灵活）
阿里云/腾讯云/AWS 的 ECS/EC2，你拿到一台完整的虚拟机，自己装环境、部署代码、配 Nginx、做监控。优势：完全可控、成本可预测、适合中大型项目。劣势：需要运维能力、要自己处理安全补丁、监控告警、扩容。
Serverless（按量付费）
AWS Lambda、阿里云函数计算、Cloudflare Workers。你只写函数，平台自动扩缩容，按调用次数付费，没流量不花钱。冷启动可能慢。执行时间有限制，不适合长连接、大文件。
容器化与 K8s（规模化）
Docker 打包应用 → Kubernetes 编排。适合微服务架构、多环境、大规模团队。环境一致性、自动扩缩容、滚动更新是它的优势。学习曲线陡、运维复杂度高，小团队用 K8s 是典型的过度工程。
第5层：AI 能力——让产品「智能」
选型就看三个点：你要的AI能力类型（对话/生成/检索/语音/图像）、延迟和成本要求、数据隐私要求。
盲目追求「最强模型」：GPT-4o 很强，但贵 10 倍。80% 的场景（分类、摘要、简单问答）用 DeepSeek/豆包就够了，成本差 10-50 倍。不做缓存和限流：AI API 按 token 计费，不做缓存会被重复请求烧钱，不做限流会被恶意调用刷爆账单。把密钥写在前端：AI API Key 绝对不能写在前端代码里（会被反编译提取），必须通过后端代理调用。本课程的朋友好学 App 用了「后端优先 + 服务端级联中继」混合方案：前端零密钥、内置作者托管后端地址，Key 只在服务端，就是为了平衡安全和可用性。
产品类型 → 技术栈映射
用一张映射表把「产品类型」和「推荐技术栈」对应起来，帮你建立直觉。
2人团队做AI写作助手SaaS，Web端为主，用户付费订阅，选什么技术栈？
本节小结
全栈五层模型：前端（用户界面）→ 后端（业务逻辑）→ 数据库（数据存储）→ 部署（上线运行）→ AI 能力（智能化）。每一层都有多种选项，选型的本质是权衡——没有最好的技术，只有最合适的技术。核心原则：用团队最熟悉的语言；MVP 阶段尽量简化（一个 PostgreSQL 搞定 90%）；避免盲目追新和过度工程；AI Key 必须走后端代理，不能写前端。下一节开始，深入每一层的具体选型和实战——先从前端开始。
资深工程师加餐
底层原理 · 大厂视角 · 工程经验，点卡片展开
独立开发者选栈的第一标准是“能不能一个人最快稳定交付”，而不是哪个框架最新。Next.js 这类全栈框架把路由、构建、静态导出、服务端接口收敛到一套工具链里，配合静态导出 + WebView 原生壳，能让一个人同时覆盖 Web 与移动端；选型时先验证最不确定的环节（离线运行、原生能力、AI 流式），跑通原型再全面投入，避免做到一半发现关键能力不成立。