| 失效链接处理 |
|
FastAPI + Vue3 前后端分离项目 最佳实践
相关截图：
 主要内容：
一、我们到底在分离什么
很多人把“前后端分离”理解成技术栈拆分，但更关键的是职责拆分：
前端对“用户体验与交互状态”负责：路由、表单、权限展示、加载与错误反馈、性能体验（懒加载、缓存策略等）。
后端对“业务规则与数据一致性”负责：鉴权、授权、事务、审计、集成外部系统、对外暴露稳定的 API。
分离之后，团队并行开发的代价是：你必须额外投资在契约与工程化上。如果契约含糊，前后端就会用“口头约定 + 临时兼容”把复杂度推给未来；如果工程化不足，联调、发布、排障都会变得昂贵。
所以本文的“最佳实践”并不是炫技清单，而是一组让系统长期可维护的默认选项：你可以根据团队规模与交付节奏做裁剪，但最好不要在没理由的情况下跳过安全、契约与可观测性这几块。
二、推荐的整体架构（高清示意图） 下面这张图描述的是一种最常见、也最容易运维的拓扑：浏览器只面对一个入口（通常是 Nginx 或同类反向代理），由它把静态资源与 API 流量分开；后端以 ASGI 方式运行 FastAPI，再连接数据库、缓存与外部服务。
读图时建议抓住三条主线：
入口统一：线上尽量别让浏览器直接跨域访问“裸后端端口”，而是用同源路径（例如 /api）转发，减少 CORS 与 Cookie 策略的复杂度（并非所有项目都必须，但默认更省心）。
契约显式：FastAPI 天然产出 OpenAPI；前端把它当作“接口真相来源”之一，能显著降低联调摩擦。
配置外置：前后端的 base URL、允许的源、密钥与连接串都应来自环境变量或密钥管理，而不是写死在代码里。
三、仓库形态：单体仓库还是多仓库 没有绝对正确，只有更匹配组织协作方式的选项：
单仓（monorepo）：frontend/ 与 backend/ 同仓库，适合小团队或强协同团队。优点是改动联动清晰、CI 可以一次性跑全链路检查；缺点是要约定好边界，避免“顺手跨目录引用”导致耦合。
多仓：前后端各自独立发布，适合组织上本就分离的团队。优点是权限与发布节奏更独立；缺点是契约漂移风险更高，更需要 OpenAPI 归档、版本管理与变更沟通。
无论哪种，都建议把“接口变更”当成一次小型发布：至少更新文档、示例请求、以及前端的类型/客户端封装。
|
苏公网安备 32061202001004号
