插下面视频白屏那一刻，问题往往不在播放器
先说一个编辑部里反复出现的场景：你在自己的页面上「插下面视频」，本地打开一切正常，上传到线上就变成一块空白。刷新、换浏览器、清缓存，都没有用。打开开发者工具，控制台里躺着几行英文报错，Network 面板里那条请求的状态是 (blocked) 或者干脆没有响应体。
这类故障有个共同特征：它不是播放器坏了，而是浏览器在请求真正发出之前就把这次跨域访问拦下了。拦截发生在浏览器的安全策略层，源站、你的页面、用户浏览器三方关系没理顺，视频地址再正确也放不出来。所以排查的第一步不是换源、不是换播放器，而是先读懂浏览器到底在抱怨什么。
我们把过去一年里读者反馈和站内工单中出现的跨域类问题做了归拢，剔除掉「源站已下线」「地址写错」这类非跨域因素后，剩下的大致落在六种形态里：CORS 预检失败、X-Frame-Options 拒绝嵌入、CSP frame-ancestors 未放行、混合内容降级、Referer 校验拒绝、Cookie/SameSite 导致的鉴权失败。前三种占了绝大多数，也最容易和「绕过方案」这四个字扯上关系。
有一点需要先把话说在前面：所谓「绕过」，在这个语境里指的是通过合法配置让浏览器放行，比如在源站补一个响应头、在你的服务端做一次转发、改用官方提供的嵌入代码。我们没有、也不会提供跳过版权校验、破解鉴权、伪造来源这类做法——那既不稳定，也不值得你拿站点信誉去赌。下面所有方案都建立在一个前提上：你对所嵌入的内容有使用权限。
跨域问题最磨人的地方，不是它难，而是它不告诉你「谁该改」。浏览器只知道拒绝，不知道你和源站之间谁说了算。搞清楚权限边界，比记住十个报错原文有用得多。
本文速览 · 一图看懂
- 症状分层：白屏可能是三种不同原因——请求被 CORS 拦、帧被 X-Frame-Options 拦、资源被混合内容拦，报错各不相同。
- 能自己改的：你页面侧的嵌入方式、Referer 策略、是否需要服务端中转，这些在你手里的部分可以立刻调整。
- 必须对方改的：CORS 响应头、X-Frame-Options、CSP frame-ancestors 三样，只有源站能加，你改再多前端也没用。
- 最容易走错的：把「加个代理」当成万能药，结果代理层没设缓存、没设超时，反而拖慢整站。
- 判断口径：以浏览器控制台报错原文 + Network 面板状态码为准，不靠猜，不以「别人说这样能行」为依据。
插下面视频跨域报错的六种形态，先认清是哪一类
把跨域问题当成一个整体去查，效率很低。更快的做法是先分类：看报错原文落在哪个关键词上，基本就能锁定责任方。浏览器给出的报错其实相当精确，只是它们通常被淹没在几十行日志里。
第一类：CORS 相关的三句典型原文
控制台里带 CORS 字样的报错，最常见的三句是「No 'Access-Control-Allow-Origin' header is present on the requested resource」「The 'Access-Control-Allow-Origin' header contains multiple values」「Request header field X is not allowed by Access-Control-Allow-Headers in preflight response」。第一句说明源站压根没返回跨域许可头；第二句通常是源站和中间层（CDN、网关）各加了一次，值重复了；第三句是预检请求（OPTIONS）被拒，多发生在你带了自定义请求头或用了非简单方法时。
这三句的共同点是：只有源站能解决。你在前端加多少代码都没用，因为浏览器在收到响应后会先检查这个头，没有就直接把响应体丢掉。有些第三方服务在文档里明确写了「不提供 CORS 支持，请使用服务端调用」，遇到这种说明就别硬碰了。
第二类：帧策略相关的拒绝
如果报错里出现「Refused to display ... in a frame because it set 'X-Frame-Options' to 'deny'」或者「Refused to frame ... because an ancestor violates the following Content Security Policy directive」，那问题不在数据交换，而在对方不允许自己的页面被装进别人的 iframe。这是两种不同的头：老的 X-Frame-Options，新的 CSP 里的 frame-ancestors 指令。两者可能同时存在，也可能只有其一。
判断方法很直接：在开发者工具里选中那个 iframe 元素，看它的请求响应头里有没有这两个字段之一。有，就是它拦的，没有，再往 CORS 方向查。
第三类：容易被忽略的混合内容与凭据问题
混合内容（Mixed Content）指的是 HTTPS 页面里加载了 HTTP 资源，浏览器会主动拦截或降级提示，报错通常写成「Mixed Content: The page at 'https://...' was loaded over HTTPS, but requested an insecure resource」。这类问题在 2026 年已经越来越少，因为主流浏览器基本默认阻止，但老站点、老图床、内网地址仍会踩到。
还有一类更隐蔽：请求本身通过了，但因为 credentials 配置和源站的 Access-Control-Allow-Credentials 对不上，返回的是 401 或空体。这种情况下控制台不一定有红字，但视频就是不出来，需要看 Network 面板的响应状态和响应头才能发现。
插下面视频 X-Frame-Options 拒绝嵌入，到底是谁在拒绝
X-Frame-Options 是一个比 CORS 更老、也更简单的机制。它只有三个有效值：DENY、SAMEORIGIN、以及已经基本被淘汰的 ALLOW-FROM。DENY 表示任何人都不许嵌；SAMEORIGIN 表示只有同源页面可以嵌；ALLOW-FROM 本来想解决「只允许某个域嵌」，但主流浏览器支持度一直很差，现在普遍改用 CSP 的 frame-ancestors。
为什么很多视频站默认就设了 DENY
这通常不是针对你。设这个头的动机一般有两个：一是防止自己的页面被恶意站点嵌套，做成「点击劫持」的载体；二是控制分发渠道，把播放页的访问留在自己的域名下，保证广告、统计、会员体系正常运转。从这个角度看，对方设 DENY 是合理的产品决策，不是技术疏漏。
所以当你遇到「插下面视频」时被 X-Frame-Options 挡下，先别急着找漏洞。正确的做法是去看对方有没有提供官方的嵌入方式——很多平台会单独给一个 embed 域或 embed 路径，那个地址的帧策略是放开给嵌入用的。用官方嵌入地址，比想办法绕过主站策略要稳得多。
CSP frame-ancestors 与 X-Frame-Options 的关系
两者功能重叠，但优先级不同：当 CSP 的 frame-ancestors 存在时，浏览器会忽略 X-Frame-Options。这就是为什么有些站点两个头都发了，实际生效的是 CSP 那条。frame-ancestors 的写法支持通配和具体域名列表，比如 frame-ancestors 'self' https://example.com，表达力比老头强很多。
如果你的站点是被允许嵌入的白名单之一，那就没问题；如果不在，也不要去猜「是不是加个 Referer 就能混过去」——现代浏览器对帧策略的检查不看 Referer，只看发起页面的源。这个方向走不通。
一个可核对的判断动作
把你要嵌入的地址单独开一个新标签页打开。如果能正常播放，说明内容存在、权限在你这边；然后回到你的页面，打开控制台看具体报错。两相对照，你就能确认到底是「内容拿不到」还是「拿到了但不让装进帧里」。这两个结论对应完全不同的处理路径，混在一起查只会浪费时间。
插下面视频如果对方只允许同源嵌入
那你手上能做的事情其实只剩两件：一是找对方要一个官方嵌入地址，二是改用跳转而非嵌入——在页面上放一张封面图加链接，用户点击后到对方站点观看。后者体验上打了折扣，但完全合法、零维护成本，对内容型站点来说往往是最实际的选择。
插下面视频 CORS 报错怎么读：把每一句翻译成人话
CORS 报错之所以让人烦躁，是因为它把「谁的问题」藏在了协议细节里。我们把最常见的几句原文逐条翻译，配上对应的责任方和可执行动作。
「No 'Access-Control-Allow-Origin' header is present」
直译：响应里没有跨域许可头。责任方：源站。可执行动作：联系源站确认是否提供跨域接口；如果对方明确不支持，就不要继续在前端尝试，转服务端代理方案。需要注意的是，这条报错在 Network 面板里那条请求可能显示 200，因为没有许可头时浏览器仍可能收到响应，只是不交给页面。所以「状态码 200」不代表成功。
「The 'Access-Control-Allow-Origin' header contains multiple values」
直译：许可头出现了多个值。常见成因是源站应用层加了一次，CDN 或反向代理又加了一次，于是变成 https://a.com, https://a.com 这种。浏览器只认单一值或通配符，多值一律判失败。责任方通常在源站的运维层，你这边改不了，但可以把这个报错原文连同响应头截图一起提交，对方定位会快很多。
「Response to preflight request doesn't pass access control check」
这条说明请求触发了预检。浏览器在发送真正的请求前，会先发一个 OPTIONS 请求问「我能不能这么干」。触发预检的条件包括：使用了 PUT/DELETE 等方法、带了自定义请求头、Content-Type 是 application/json 之类。预检失败往往是源站没处理 OPTIONS 方法，或者没在预检响应里返回正确的 Allow-Methods、Allow-Headers。
如果你控制不了源站，能做的优化是降低请求的「复杂度」：把方法改成简单请求（GET/POST/HEAD），把 Content-Type 换成 text/plain、application/x-www-form-urlencoded、multipart/form-data 三者之一，去掉自定义头。这样浏览器就不发预检，直接发请求，绕开了预检这一关。这属于协议允许的正常做法，不是投机。
凭据相关的报错
当你在请求里带了 credentials: 'include'，浏览器会额外要求源站返回 Access-Control-Allow-Credentials: true，而且此时 Access-Control-Allow-Origin 不允许写通配符 *，必须回具体的源。这两条同时满足才行。很多站点图省事写了 *，结果带凭据的请求全挂，报错会写成「The value of the 'Access-Control-Allow-Origin' header in the response must not be the wildcard '*' when the request's credentials mode is 'include'」。
如果你的场景确实需要带 Cookie（比如内网系统嵌入自己的视频服务），正确做法是在源站把允许的源写全，而不是把 credentials 关掉——关掉之后鉴权就失效了，视频照样出不来。
插下面视频白屏了怎么定位？四步法照着走一遍
前面讲的是分类，这一节讲动作顺序。顺序错了会浪费大量时间，比如先怀疑播放器、先换源地址，多数情况下都是无用功。
-
第一步：确认地址本身能不能独立打开
把嵌入地址复制到新标签页直接访问。打不开说明是源站问题或地址失效，跟跨域无关，先去处理源站。能打开再往下走。这一步花 10 秒，能排除掉大约三成的问题。
-
第二步：看控制台报错的关键词
只扫关键词：带
CORS的往响应头方向查，带X-Frame-Options或frame-ancestors的往帧策略方向查，带Mixed Content的往协议方向查。不要在没分类的情况下逐行读日志。 -
第三步：在 Network 面板核对响应头
找到那条被拦的请求，看 General 里的状态、Response Headers 里有没有 Allow-Origin、X-Frame-Options、Content-Security-Policy。这一屏信息基本能定案。如果请求根本没发出去（Network 里看不到），那可能是被页面自身的前置逻辑阻止了，回去看 JS 报错。
-
第四步：判断责任方，决定是改自己还是找对方
能在你手里的：嵌入方式、请求方法、是否走服务端中转、Referer 策略。只能在对方的：Allow-Origin、帧策略、CSP。分清楚之后，要么动手改，要么把报错原文和响应头截图整理好去沟通——后者往往比自己折腾三天更快。
这套顺序的价值在于「先排除、后深挖」。跨域问题里，真正需要深挖的比例并不高，大部分在第一步和第二步就能定性。
插下面视频跨域合法配置对照表：能改什么、不能改什么
下面这张表把六种形态的责任方、可执行动作和代价列在一起，方便你按自己的处境对号入座。表中「代价」一栏指的是实施该方案需要付出的额外工作量和长期维护负担。
| 报错形态 | 责任方 | 合法可行动作 | 代价 |
|---|---|---|---|
| CORS 无许可头 | 源站 | 请求对方开放跨域；或改由服务端转发 | 中，需服务端资源 |
| 许可头多值 | 源站 / CDN | 提交报错原文与响应头，由对方去重 | 低，沟通成本 |
| 预检失败 | 源站 | 降低请求复杂度，改用简单请求；或对方补 OPTIONS 处理 | 低，改前端即可 |
| X-Frame-Options: DENY | 源站 | 改用官方 embed 地址；或改为跳转观看 | 低到中 |
| CSP frame-ancestors 限制 | 源站 | 确认自己是否在白名单；不在则同上 | 低 |
| 混合内容 | 你自己 | 把资源地址升级为 HTTPS，或整页迁移到 HTTPS | 低 |
| 凭据与通配符冲突 | 源站 | 请对方把 Allow-Origin 写成具体源，或去掉 credentials | 低 |
看表的时候容易忽略一点：「代价低」不等于「优先做」。比如混合内容那条，改起来最快，但它只在 HTTPS 页面上出现，如果你的站点本来就跑在 HTTP 上，改了也没意义。先确认前提条件，再选动作。
插下面视频服务端中转：什么时候值得做
中转的适用条件其实比较窄：你确实需要那份数据、对方确实不开放跨域、并且你有可用的服务端环境。三个条件缺一个都不建议做。中转本身会带来带宽成本、缓存策略问题、以及一旦对方地址变更就要跟着改的维护负担。如果只是偶尔嵌入一两个视频，跳转观看的性价比通常更高。
真要做中转，有两个细节值得提前想清楚：一是设置合理的超时和重试，避免源站慢的时候把你的服务拖住；二是明确缓存策略，视频类资源如果每次请求都回源，流量账单会很难看。这两点属于工程细节，但恰恰是「能跑起来」和「能长期跑」的分界线。
插下面视频替代方案怎么选：iframe、video 标签还是跳转
嵌入方式的选择会直接影响你会不会踩上跨域。同样的内容，用 iframe 嵌可能被帧策略拦，用 video 标签直连可能被 CORS 拦，用跳转则什么都不会拦但体验打折。没有一种方式在所有场景下都最优。
iframe：最省事，也最依赖对方
iframe 的优势是把播放器的复杂度全交给对方，你只需要一个地址。代价是它完全受制于对方的帧策略和 CSP。如果对方提供了官方嵌入地址，iframe 通常是最优解；如果没有，这条路基本走不通。另外 iframe 在移动端的横竖屏切换、全屏行为上偶有兼容问题，需要单独测。
video 标签直连：可控但要过 CORS
用 <video src="..."> 直接指向视频文件，不涉及帧策略，但会触发 CORS——而且视频元素还有一个额外要求：如果你想读取视频的时长、分辨率等信息，或者做画中画、截图之类的操作，源站必须允许跨域。只是播放的话，不带 crossorigin 属性的 video 标签可以在没有 CORS 许可的情况下播放，但你就拿不到那些元数据。
判断依据很简单：只播放，不加 crossorigin；要读数据，就得加，然后必须过 CORS。后者失败的表现是视频能播但 JS 报错，或者干脆不播。
插下面视频跳转观看：体验最差但最稳
封面图加外链，点开新窗口。这种做法在纯技术指标上没有任何优势，但它零依赖、零维护、永远不会因为对方改策略而失效。对内容型站点、教程类文章来说，如果不涉及「必须留在本页」的交互，这是很务实的选择。编辑部自己的判断是：能嵌就嵌，嵌不了就跳，不要为了「留在本页」去折腾一周。
移动端要额外留一个心眼
移动端浏览器对帧策略和 CORS 的处理与桌面端大体一致，但横竖屏切换、全屏播放、以及省流模式下的加载行为差异明显。同一段嵌入代码在桌面端正常，在手机上可能表现为「点了没反应」。测试时至少覆盖一个 iOS 浏览器和一个安卓浏览器，别只看桌面。
插下面视频那些看起来很聪明的弯路，编辑部劝你别走
跨域排查里有一些流传很广的「技巧」，短期看似有效，长期一定出问题。列出来不是为了批评谁，而是省下你试错的那几个晚上。
在本地起个代理就以为解决了
开发阶段用本地代理转发请求，控制台确实不红了。但这个代理只存在于你的开发环境，上线之后浏览器面对的还是真实源站，报错照旧。判断方法：把页面部署到真实域名下再测一次，如果问题复现，说明之前的「解决」只是开发环境的假象。
盲目加通配符许可头
有些教程会建议「在源站加 Access-Control-Allow-Origin: * 就好了」。如果你恰好是源站的维护者，这条在不带凭据的场景下成立；但一旦涉及 Cookie、Token 这类凭据，通配符是明令禁止的，加了反而会让原本能用的请求失败。而且对所有来源开放，本身也不是一个负责任的默认设置。
用图片或截图代替视频
遇到帧策略拦截时，有人会退而求其次，把视频截成一张图放在页面上。这确实能显示，但用户点开之后什么也没有，属于把问题从「技术故障」变成「体验欺骗」。与其如此，不如老老实实放一个跳转链接，至少用户知道下一步该去哪。
插下面视频反复清缓存、换浏览器
清缓存能解决的问题是「旧响应被缓存了」，属于缓存类故障，跟跨域是两回事。跨域拦截是每次请求都会发生的策略判断，清一百次缓存也不会变。把时间花在读报错上，比花在清缓存上有用得多。
信息以官方公开文档和浏览器实际行为为准。我们不在文章里给出未经核实的第三方平台具体政策条款或时间节点，因为那些东西变化太快，写死了反而误导人。遇到拿不准的情况，以你当下的实测结果为准。
插下面视频跨域排查的量化参考与口径说明
这一节给出一些区间性的参考数据，来源是本站编辑部的实测记录与读者反馈归拢。这些数字只描述我们观察到的范围，不代表任何第三方平台的官方指标，也不构成对你的场景的承诺。
以上数字仅用于描述本站内容的整理范围与更新节奏，不代表真实用户量、访问量、排名或任何第三方背书。
几个值得记住的判断阈值
预检请求的缓存时长由源站返回的 Access-Control-Max-Age 决定，常见配置在 600 秒到 86400 秒之间，也就是 10 分钟到 24 小时。这个值设得太小，每次请求都要多一轮往返；设得太大，策略变更后生效慢。多数场景下取中间值比较省心。
帧策略白名单通常按域名粒度配置，一个源站一般允许 1 到 10 个嵌入来源，超过这个数量级说明对方是在做开放嵌入，通常也会配套提供官方嵌入地址。如果你发现对方的白名单里有几十个域名，那基本可以判断它对外是开放的，只是可能没写在显眼位置。
视频资源的首包时间受源站和网络共同影响，跨境访问时波动尤其大。跨域失败属于「请求被拒」，跟「请求慢」是两码事——前者在 Network 面板里看不到响应体，后者能看到但耗时长。分清楚这两个，能避免把性能问题当权限问题查。
插下面视频跨域 FAQ：六个最常被问到的问题
下面这些问题来自站内留言和读者邮件，按出现频率排序。答案里的数据为区间性参考，具体以你的实测为准。
插下面视频出现白屏，一定是跨域问题吗？
不一定。白屏至少有四类成因：跨域被拦、源站地址失效、播放器初始化失败、以及资源被混合内容策略降级。区分方法看控制台：如果有 CORS 或 X-Frame-Options 字样，是跨域；如果请求返回 404 或 5xx，是源站问题；如果没有任何报错但画面空白，多半是播放器初始化或尺寸问题。按我们归拢的数据，跨域类大概占白屏反馈的六成左右。
插下面视频时，我能不能自己在前端绕过 X-Frame-Options？
不能，也没有必要尝试。X-Frame-Options 和 CSP 的 frame-ancestors 由浏览器在渲染阶段判断，判断依据是发起页面的源，前端 JS 无法改变这个事实。可行的路径是使用对方提供的官方嵌入地址，或改为跳转观看。需要说明的是，主流浏览器对这两个头的支持率目前都在 98% 以上，指望某个浏览器不检查是不现实的。
Access-Control-Max-Age 设成多少比较合适？
常见配置区间是 600 秒到 86400 秒。取值偏小（比如 600 秒，约 10 分钟）的好处是策略调整后生效快，代价是预检请求更频繁，多一轮网络往返；取值偏大（比如 86400 秒，约 24 小时）反过来。如果接口调用量不大，取中间值 3600 秒左右是比较省心的折中。注意这个值只影响预检结果的缓存，不影响实际请求。
用 video 标签直连视频文件，为什么有时候能播有时候不能？
差别通常在 crossorigin 属性上。不带这个属性时，video 元素可以播放没有 CORS 许可的资源，但你就读不到视频时长、分辨率等元数据，也无法做画中画或截图；带上之后，源站必须返回正确的跨域许可，否则连播放都会失败。如果你只是播放，去掉这个属性往往就能解决；如果需要读取数据，就得让源站配合开放跨域。这个属性的行为在主流浏览器上已经统一多年，不是兼容性问题。
服务端中转会不会拖慢页面加载？
会有一定影响，但可控。多一层转发意味着多一次网络往返，典型情况下会增加几十到几百毫秒的首包延迟，具体取决于你的服务器位置和源站响应速度。缓解手段包括：设置合理的缓存策略（视频类静态资源可缓存数小时到数天）、开启压缩、以及选择离源站较近的转发节点。如果只是偶尔嵌入，跳转观看的体验损失其实比中转带来的延迟更小。
跨域问题解决了，为什么手机上还是打不开？
跨域和移动端兼容是两个独立维度。跨域通过只说明浏览器放行了请求，不代表播放链路在移动端可用。移动端常见的新增问题有三个：省流模式下视频被延迟加载、横竖屏切换导致容器尺寸计算错误、以及部分浏览器对全屏播放的权限要求更严格。建议在至少一个 iOS 和一个安卓浏览器上实测，桌面端正常不能作为移动端可用的依据。
插下面视频专题活动与资源目录
编辑部每周会挑一个和嵌入、跨域、播放链路相关的小主题做集中整理，下面是近期在做的几个。专题内容会随实际排查记录滚动更新，不设结束日期。
插下面视频跨域报错对照手册
把六类常见报错的原文、责任方、可执行动作收在一页里，随浏览器版本更新修订。
帧策略白名单观察
记录常见视频平台是否提供官方嵌入地址、嵌入地址与主站策略的差异。
插下面视频白屏排查四步法
从独立打开地址到看响应头，四步定性，附每一步的判断依据。
移动端嵌入兼容夜话
横竖屏、省流、全屏权限，手机上那些桌面端遇不到的小问题。
资源与内容目录
下面这张目录列出站内与本文主题相关的几篇内容，每条标注了类型、适合的阅读场景和最近一次核对时间。状态列里的「可用」指该页内容当前有效、无已知失效段落。
状态与核对时间仅描述本站内容的维护情况，不代表任何第三方平台的服务状态。
插下面视频维护这支内容的编辑们
插下面视频·入口导航由一支不做内容生产、只做工具聚合和步骤拆解的小编辑部维护。我们自己的定位很清楚：把嵌入、播放、排查这条链路上的坑，用可核对的方式记录下来。下面几位是这篇内容相关板块的主要维护者。
- 跨域排查
- 指标口径
- 响应头分析
- iframe 策略
- 移动适配
- 实测记录
- 播放器选型
- 浏览器差异
- 版本追踪
以上人物为本站编辑部虚拟角色，不代表真实个人履历。
插下面视频合作与内容共建计划
如果你长期处理嵌入、播放链路或前端兼容问题，手上有可复现的报错场景和实测结论，欢迎把这些记录整理给我们。我们不生产内容，但很愿意做那个把散落经验汇编成可查手册的角色。
我们能提供什么
你给原始记录，我们负责统一口径、核对表述、补上适用边界，避免结论被误用。
被采用的实测记录会在对应板块标注贡献者，随文章一起长期保留。
与你方向匹配的专题内容会优先排进更新计划，跟着专题一起迭代。
读者在站内提出的同类疑问，会汇总给你，作为后续实测方向的参考。
我们希望你是
- 手上有可复现的跨域、帧策略或播放链路故障场景，能说清复现步骤。
- 愿意把结论限定在实测范围内，不夸大适用范围，不编造数据。
- 尊重版权与平台规则，所提供的内容不涉及未授权资源的获取方式。
- 能接受我们按统一口径做文字整理，保留结论、调整表述。
怎么加入
把场景描述、复现步骤、控制台报错原文和响应头信息整理成一段文字，发送到编辑部邮箱 editor@chaxiamianshipin.com.cn。我们会在每周的整理会上过一遍，采用与否都会回复。也可以直接从 工具入口 页面看看我们正在整理的方向。
看看我们在整理什么 →相关文章
写这篇的人
读者评论
留言区不做筛选，只做整理。下面几条来自站内和读者邮件，均已获得授权展示。
按四步法走了一遍，第二步就定案了，是对方 frames 策略不允许嵌入。之前一直在改前端代码，白折腾两天。
预检那一段讲得清楚。我们把请求改成简单请求之后，OPTIONS 那一轮就没了，首屏快了一截，算是意外收获。
想请教一下，如果源站愿意配合，Allow-Origin 写具体域名和写通配符在性能上有区别吗？我们内部为这个争了半天。
那几条「看起来很聪明的弯路」我全踩过。特别是本地代理那条，上线才发现根本没用，现在想起来还挺好笑的。
跨域和移动端兼容分开讲这一点很实用。我们之前一直把手机打不开当成跨域没解决，方向完全错了。
Max-Age 那个建议很中肯，我们之前设得太短，每次都在等预检，调成 3600 之后体感明显顺了一些。