本文详解如何通过 Express 的 cors 中间件精准配置 Access-Control-Allow-Origin，解决 example.com 与 sub.example.com 之间因跨域限制导致的音频文件（如 WAV）请求失败问题。
本文详解如何通过 express 的 cors 中间件精准配置 `access-control-allow-origin`，解决 `example.com` 与 `sub.example.com` 之间因跨域限制导致的音频文件（如 wav）请求失败问题。
在前后端分离或微服务架构中，同一主域下的不同子域（如 example.com 与 sub.example.com）虽属同一家族，但仍被浏览器视为不同源（origin），触发 CORS（跨域资源共享）校验。你遇到的错误：
Access to XMLHttpRequest at 'https://sub.example.com/app/listen/1.wav' from origin 'https://www.example.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present...
根本原因在于：CORS 响应头必须由被请求方（即资源提供者）显式声明。也就是说，sub.example.com 服务器必须在响应 GET /app/listen/1.wav 时返回合法的 Access-Control-Allow-Origin: https://www.example.com，浏览器才允许前端 JavaScript 读取该响应。
你当前的配置存在两个关键问题：
- 回调函数无效：origin: (origin, callback) => callback(null, true) 实际上等价于 origin: true，它会忽略传入的 origin，并无条件允许所有来源——但 cors 模块在 credentials: true 启用时*禁止使用通配符 `或true` 作为 origin 值**，否则将静默失效（不设置响应头），导致 CORS 报错。
- 配置位置错位：CORS 中间件必须部署在提供资源的服务器上（即 sub.example.com），而非调用方（example.com）。example.com 侧配置 CORS 对解决该跨域请求完全无效。
✅ 正确做法如下：
✅ 步骤一：在 sub.example.com 服务器（资源提供方）启用精确 CORS 策略
const express = require('express');
const cors = require('cors');
const app = express();
// ✅ 允许指定来源（注意：必须与前端实际 origin 完全一致，含协议、子域、端口）
app.use(cors({
origin: ['https://www.example.com'], // ← 关键：此处是请求发起方的 origin
methods: ['GET', 'HEAD', 'OPTIONS'], // 仅需支持 GET 即可访问静态文件
credentials: true // 若需携带 cookie 或认证头，才设为 true；本例中通常不需要
}));
// 静态文件中间件（确保在 cors 之后）
app.use('/app/listen', express.static('./public/audio'));
app.listen(3000);? 提示：https://www.example.com 与 https://example.com 是不同 origin，请严格匹配前端页面的实际地址（可通过浏览器地址栏或 document.origin 确认）。
✅ 步骤二：如需双向通信，再在 example.com 服务器配置（非必需）
若 example.com 也需对外提供 API 给 sub.example.com 调用，则在其服务端做对称配置：
// 在 example.com 服务器中（仅当它也需被 sub.example.com 调用时才需）
app.use(cors({
origin: ['https://sub.example.com'],
methods: ['GET', 'POST']
}));⚠️ 注意事项与最佳实践
*避免滥用 `origin: ''**：虽然origin: '*'可快速测试，但它与credentials: true` 不兼容。若需鉴权（如带 Cookie 或 Bearer Token），必须指定明确 origin 列表。
静态文件也要受 CORS 控制：Express 的 express.static() 默认不加 CORS 头。务必确保 cors() 中间件位于 static() 之前，否则静态资源响应将无 CORS 头。
预检请求（OPTIONS）自动处理：cors 中间件默认处理 OPTIONS 预检请求，无需额外路由。确保 methods 包含实际使用的 HTTP 方法（如 GET）。
-
生产环境建议白名单校验：可升级为动态白名单函数，增强安全性：
const allowedOrigins = ['https://www.example.com', 'https://staging.example.com']; app.use(cors({ origin: (origin, callback) => { if (!origin || allowedOrigins.includes(origin)) { callback(null, true); } else { callback(new Error('Not allowed by CORS')); } } }));
✅ 验证是否生效
部署后，使用浏览器开发者工具 → Network 标签页，查看对 https://sub.example.com/app/listen/1.wav 的请求响应头，确认包含：
Access-Control-Allow-Origin: https://www.example.com Vary: Origin
此时前端 fetch() 或 XMLHttpRequest 即可成功读取音频资源。
总结：CORS 是浏览器施加的安全策略，其控制权在被请求方服务器。精准配置 origin 白名单、确保中间件顺序、区分调用方与提供方角色，是解决跨子域资源访问问题的核心三要素。
