21 - 前后端如何拼在一个域名下

前端在 CDN、后端在 Serverless，它们是两个独立的服务。用户访问网站、前端又要调后端 API，这两者怎么在一个域名体系下协作？跨域问题怎么处理？这一章讲清。

现状：前后端是”分开住”的

在我们的方案里：

前端静态文件 → 在 OSS + CDN
后端 API → 在 Serverless

它们是两个不同的服务、两个不同的地址。所以要设计好”用户和前端用哪个地址、前端调后端用哪个地址”。

两种常见的域名组织方式

方式一：子域名分开（推荐，最清晰）

前端：www.yourapp.com → CNAME 到 CDN
后端：api.yourapp.com → CNAME 到 Serverless

前端代码里，把 API 请求都发到 https://api.yourapp.com。

优点：清晰、各自独立、互不影响。这是最常用、最推荐的方式。

方式二：同域名不同路径

www.yourapp.com/ → 前端
www.yourapp.com/api/ → 后端

这需要在最前面加一层统一入口（如 CDN 的路径路由规则，或一个网关）把 /api 的请求转发给 Serverless，其余给 CDN。

优点：对浏览器来说是同一个域名，天然没有跨域问题。缺点：要多配一层路由规则。

[配图：两种方式对比——左边子域名（www 和 api 两个盒子）；右边同域名（一个盒子内部按路径 / 和 /api 分流）]

跨域（CORS）是怎么回事

如果用方式一（子域名分开），就会遇到跨域问题，必须理解它。

跨域：浏览器出于安全，默认禁止一个网页向”不同源”的地址发请求。www.yourapp.com 和 api.yourapp.com 域名不同，算不同源，所以前端调后端会被浏览器拦下来，报 CORS 错误。

注意：跨域是浏览器的安全限制，不是你代码写错了。它是为了防止恶意网站偷偷拿你的数据。

怎么解决：后端声明”我允许这个来源”

解决办法是在后端加上 CORS 响应头，明确告诉浏览器”我允许 www.yourapp.com 来调我”。FastAPI 里：

from fastapi.middleware.cors import CORSMiddleware

app.add_middleware(
    CORSMiddleware,
    allow_origins=["https://www.yourapp.com"],  # 只允许你自己的前端，别用 "*" 图省事
    allow_methods=["*"],
    allow_headers=["*"],
)

要点：

allow_origins 写你前端的确切域名，不要在生产环境用 "*"（等于门户大开）
浏览器在真正请求前，可能先发一个 预检请求（OPTIONS） 问后端”我能来吗”，后端要正确响应

如果用方式二（同域名），前后端同源，就没有跨域问题，不用配 CORS。这也是方式二的一个好处。

把整条访问链路串起来

以子域名方式为例，用户访问的完整链路：

用户打开 https://www.yourapp.com → DNS 解析到 CDN → 加载前端页面（HTTPS）
前端页面里的 JS 向 https://api.yourapp.com/xxx 发请求
请求到 Serverless 后端，后端带着正确的 CORS 头响应
浏览器验证 CORS 通过 → 前端拿到数据 → 渲染给用户

小结

前端（CDN）和后端（Serverless）是分开的服务，用域名把它们组织起来。
两种方式：子域名分开（www / api，推荐、清晰）或同域名不同路径（无跨域，但要配路由）。
子域名方式会遇到跨域（CORS）：这是浏览器的安全限制，解决办法是后端声明允许你的前端来源，别用 "*"。
同域名方式天然无跨域。

到这里，现代部署的所有零件——CI/CD、前端、后端、数据库、AI、域名、HTTPS——都讲全了。第七部分，我们把它们合到一起做一个完整实战。

下一章 → 22 - 目标与最终架构图