全栈应用架构
全栈不等于“前后端都写一点”
Section titled “全栈不等于“前后端都写一点””全栈应用要把用户流程、页面、接口、业务规则、数据、权限、部署和运维连起来。最小的关系可以画成：
浏览器 ↓ HTTPS前端页面 / SSR 层 ↓ API 或 Server Action后端业务服务 ├─ 数据库 ├─ 文件存储 ├─ 队列/定时任务（需要时再加） └─ 模型、支付、邮件等第三方服务三种渲染方式
Section titled “三种渲染方式”| 方式 | 页面在哪里生成 | 适合 |
|---|---|---|
| 静态生成（SSG） | 构建时 | 官网、文档、博客、内容页 |
| 服务端渲染（SSR） | 每次请求或缓存时 | 个性化页面、需要即时数据和 SEO 的页面 |
| 客户端渲染（SPA） | 浏览器加载 JavaScript 后 | 复杂后台、频繁交互的应用 |
实际项目常常混合使用：公开内容静态生成，登录后的后台由浏览器请求 API。
数据和权限的边界
Section titled “数据和权限的边界”前端可以保存页面状态，但不能信任前端传来的用户 ID、价格、角色或权限。后端要根据会话重新识别用户，并在查询和写入时检查资源归属。
把 API Key、数据库密码、支付密钥和内部服务地址放在服务器环境变量或安全存储，不要打进前端构建产物。
同构框架和分离式架构
Section titled “同构框架和分离式架构”- 同构/全栈框架：Next.js、Nuxt、SvelteKit、Django 模板等，页面和服务端代码可以在同一项目；
- 前后端分离：React/Vue/Svelte 前端 + 独立 API 服务，边界清楚，团队可分别部署；
- 静态前端 + 托管后端：适合小项目和快速上线，减少服务器维护。
没有“永远正确”的方式。需要考虑团队、部署平台、数据隐私、扩展和迁移。
一次完整请求应该考虑什么
Section titled “一次完整请求应该考虑什么”点击提交→ 前端校验→ 发送请求（认证、超时、请求 ID）→ 服务端校验和权限判断→ 调用数据库/第三方服务→ 记录结果和错误→ 返回可处理的状态码与 JSON→ 前端展示成功、失败或重试不要只实现“成功路径”。网络断开、重复点击、过期会话、限流、第三方超时和数据库失败都要有明确表现。
从单体开始，按问题扩展
Section titled “从单体开始，按问题扩展”一个前端、一个后端服务、一个数据库通常足以验证第一版。出现真实需求后，再增加缓存、队列、搜索、对象存储、读副本或服务拆分。每个新增组件都意味着新的部署、监控、备份和费用。
用 AI 梳理全栈方案
Section titled “用 AI 梳理全栈方案”请根据以下用户流程画出最小架构：用户：[谁]核心动作：[从进入到完成]需要保存的数据：[对象和字段]第三方服务：[模型/支付/邮件等]约束：[预算、地区、隐私、团队能力]请输出：页面、API、数据库表、权限边界、失败路径、部署方式和未来扩展点。把已知事实、假设和待确认问题分开。