cors 错误是浏览器因响应头缺失（如 access-control-allow-origin）主动拦截响应，前端无法修复，必须由后端正确配置对应响应头。

fetch 报 CORS 错误，不是请求发不出去，而是浏览器收到响应后，发现缺少关键响应头（如 Access-Control-Allow-Origin），主动拒绝把响应内容暴露给 JavaScript。前端无法补全这些头，必须由后端返回——这是浏览器强制执行的安全机制，不存在“前端加几行代码就能修复”的方案。

为什么响应头缺失会导致 fetch 失败

浏览器在跨域请求中会检查服务端返回的 HTTP 响应头。若以下任一情况发生，fetch 就会报错且不进入 .then()：

• 响应中完全没出现 Access-Control-Allow-Origin
• Access-Control-Allow-Origin 的值是 *，但前端设置了 credentials: 'include'
• 请求触发预检（比如用了 PUT、带 Authorization header 或 Content-Type: application/json），但服务端对 OPTIONS 请求没返回 Access-Control-Allow-Methods 或 Access-Control-Allow-Headers
• 后端写了响应头，但写在了错误中间件位置（例如 Express 中放在 next() 之后），导致实际未生效

确认是否真缺响应头：三步定位法

别猜，直接看 Network 面板：

Feishu calendar sync, local ics to json data for AI agent

将ICS日历文件转为JSON格式，用于飞书日历导入导出及数据集成。

下载

• 在浏览器开发者工具的 Network 标签页中，找到失败的请求，点开它
• 切换到 Headers → Response Headers 区域，逐行查找：Access-Control-Allow-Origin、Access-Control-Allow-Credentials（如果用了 cookie）、Access-Control-Allow-Methods（如果非 GET/POST）
• 如果是预检失败，要专门找 OPTIONS 请求的响应头，而不是主请求的

前端能做的有效配合

你不能让后端“必须改”，但可以调整请求方式，降低对响应头的要求：

• 用 GET 发送简单查询，不带自定义 header，Content-Type 保持默认（即不设），可避开预检
• 需要传 token？改用 URL 参数或 Authorization header 前，先确认后端已声明 Access-Control-Allow-Headers: Authorization
• 要带 cookie？前端必须写 credentials: 'include'，同时确保后端返回 Access-Control-Allow-Credentials: true 且 Access-Control-Allow-Origin 是具体域名（如 https://your-app.com），不能是 *
• 开发时用代理：Vite 中配 server.proxy，Vue CLI 中配 devServer.proxy，把 /api 请求转发到后端地址，让浏览器认为是同源

后端必须补上的响应头（供你和后端对齐）

以下头必须由服务端在每次响应中设置（不能只在 OPTIONS 中设）：

• Access-Control-Allow-Origin：开发可用 http://localhost:5173；生产环境禁用 *（尤其涉及登录态）
• Access-Control-Allow-Credentials：仅当需 cookie/session 时设为 true
• Access-Control-Allow-Methods：明确列出用到的方法，如 GET, POST, PUT，不要写 *
• Access-Control-Allow-Headers：列出前端实际发送的 header，如 Content-Type, Authorization, X-Request-ID

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南