cors 多租户需后端动态校验 origin 并反射合法域名到 access-control-allow-origin，禁用 *，启用 credentials 且预检请求需正确响应，生产推荐网关层统一管控。
CORS 本身不直接“支持多租户独立域名互访”，而是由后端根据请求的 Origin 动态判断并返回对应许可的响应头。在多租户场景（如每个租户拥有自己的子域或独立域名：tenant-a.example.com、tenant-b.example.com、client123.com），关键在于服务端不能硬写死单个域名，也不能盲目用 *（尤其当需携带凭证时）。
后端必须动态反射 Origin 或白名单校验
浏览器每次跨域请求都会带上 Origin 请求头（如 Origin: https://acme.corp）。后端应：
- 读取请求头中的
Origin值 - 检查该域名是否属于合法租户（例如查数据库、配置中心或预设白名单）
- 若匹配，将该
Origin值原样回写到Access-Control-Allow-Origin响应头中 - 禁止直接返回
*（否则credentials: 'include'会失效）
必须开启凭证支持且前后端保持一致
多租户应用通常需共享登录态（如 SSO Token、租户 Cookie），因此：
Comprehensive Three.js 3D graphics reference
下载
详细的 Three.js 3D 图形参考，涵盖场景设置、相机、几何体、材质、光照、动画、控制器、加载器、数学工具和调试。
- 前端 fetch / axios 请求中要显式设置
credentials: 'include' - 后端响应头必须包含
Access-Control-Allow-Credentials: true - 此时
Access-Control-Allow-Origin不能为*，只能是具体域名（如https://tenant-x.myapp.com）
预检请求（OPTIONS）必须被正确处理
带自定义 header（如 X-Tenant-ID）、非简单方法（PUT/DELETE）或含 credentials 的请求，会触发预检。后端需：
- 对所有
OPTIONS请求快速响应（状态码 204 或 200），不走业务逻辑 - 在 OPTIONS 响应中同样返回正确的
Access-Control-Allow-Origin和Access-Control-Allow-Headers（如包含X-Tenant-ID） - 确保
Access-Control-Allow-Methods包含实际要用的动词（如GET, POST, PUT, OPTIONS）
生产环境建议配合反向代理统一管控
在网关层（如 Nginx、Azure Front Door、Spring Cloud Gateway）做统一 CORS 处理更安全可控：
- 避免每个微服务重复实现 Origin 校验逻辑
- 可集中管理租户域名白名单与租户路由映射（如
tenant-a.api.example.com → /api/tenant-a/） - Nginx 示例片段（支持动态 Origin 反射）：
# 允许来自租户域名的请求，并反射 Origin
set $cors_origin "$http_origin";
>if ($http_origin ~* "^https?://([a-zA-Z0-9.-]+\.(tenant|corp)\.example\.com)$") {
set $cors_origin "$http_origin";
}
>add_header 'Access-Control-Allow-Origin' "$cors_origin" always;
add_header 'Access-Control-Allow-Credentials' 'true' always;
add_header 'Access-Control-Allow-Methods' 'GET, POST, PUT, DELETE, OPTIONS' always;
add_header 'Access-Control-Allow-Headers' 'Content-Type, Authorization, X-Tenant-ID' always;
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
