HTML本身无法配置CORS，必须由后端服务返回Access-Control-Allow-Origin等响应头；meta标签和crossorigin属性仅是前端触发信号，不生效于无对应响应头的服务器。
HTML 本身无法配置 CORS，所谓“在线运行器的跨域访问权限”必须由该运行器后端服务返回正确的 Access-Control-Allow-Origin 等响应头，前端 HTML 页面加任何 <meta>、<script> 或属性都无效。
为什么在 HTML 里写 crossorigin 或 meta 标签完全没用
浏览器只校验 HTTP 响应头，不解析 HTML 内容。常见错误包括：
-
<meta http-equiv="Access-Control-Allow-Origin" content="*">：浏览器明确忽略，CORS 相关头不在http-equiv支持列表中 -
<script src="https://run.example.com/code.js" crossorigin="anonymous"></script>：加了只是“要求”服务端返回对应头；若服务端没配，脚本仍加载失败或内容不可读 - 本地改完 HTML、硬刷缓存、换浏览器重开——只要响应头没变，CORS 错误照旧
哪些操作会真正触发 CORS 校验（针对在线运行器场景）
只有脚本主动发起、且跨域的请求才走完整流程。典型情况有：
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
-
fetch('https://run.example.com/execute', { method: 'POST', credentials: 'include' })：一定触发，且要求服务端返回Access-Control-Allow-Credentials: true和精确匹配的Access-Control-Allow-Origin（不能是*） -
XMLHttpRequest提交代码到运行器 API：同上，预检OPTIONS必须成功返回允许的方法和头 -
<iframe src="https://run.example.com/sandbox.html"></iframe>：不触发 CORS，但 JS 访问其window会被同源策略拦截；需目标页自己返回Content-Security-Policy: frame-ancestors -
<img src="https://run.example.com/output.png">：默认不触发；但若后续用canvas.drawImage()读像素，就必须加crossorigin="anonymous"且服务端配头
前端能做的唯一有效动作：确认请求模式并匹配服务端配置
你无法“配”CORS，但可以检查并调整前端行为，避免触发浏览器拦截：
立即学习“前端免费学习笔记（深入）”；
- 用
fetch时显式声明mode: 'cors'，尤其搭配credentials: 'include'—— 不写mode可能被降级为no-cors，导致响应体不可读 - 若运行器 API 允许匿名调用，优先用
credentials: 'omit'，这样服务端可安全返回Access-Control-Allow-Origin: * - 开发调试阶段，若运行器未开放 CORS，可用 Vite/Webpack 的
server.proxy把/api/run代理到运行器地址 —— 注意这只是本地绕过，上线必须依赖运行器后端配好头 - 检查 Network 面板里 OPTIONS 请求是否 200：如果预检失败（403/405/500），主请求根本不会发出，此时问题 100% 在运行器后端的预检处理逻辑（如 Nginx 未透传 OPTIONS，Spring Boot 未注册全局 CorsConfigurationSource）
最容易被忽略的一点：CORS 规则生效前提是服务端真实返回对应响应头；所有前端标签、属性、JS 调用都只是“触发器”或“协商信号”，不是开关。
