跨域这个老生常谈的话题几乎每次前端面试都会被翻出来但真要上手调接口的时候很多人还是被CORS报错、代理失效折腾得焦头烂额。而WebSocket和SSE这两兄弟一个负责双向实时通信一个擅长服务端单向推送要是搞不清选哪个代码写得再漂亮也白搭。这篇文章我尝试把跨域方案、SSE、WebSocket从原理到实战一次性理顺配合我这些年踩过的坑和排查思路希望能给正在写前端或者准备面试的朋友一点实实在在的帮助。1. 跨域问题浏览器的一道红线1.1 同源策略到底在保护什么先别急着背解决方案理解同源策略的本质比记住一堆配置项重要。同源指的是协议、域名、端口三者完全一致。只要有一个不一致浏览器就会视为跨域。比如http://localhost:8080请求http://localhost:3000虽然都是localhost但端口不同依然是跨域。浏览器之所以要设这道坎核心是为了保护用户的登录状态和敏感数据。设想一下如果你在A网站登录了银行账户浏览器里存了登录Cookie。这时候打开B网站B网站上有一段恶意脚本悄悄向银行的接口发请求。如果没有同源策略限制这个请求会被浏览器正常携带Cookie发送银行服务器拿到合法凭证就可能返回用户隐私数据B网站的脚本就能读取并盗走。所以同源策略本质上是浏览器的安全边界页面里的脚本只能访问同源资源跨域请求必须经过服务器的明确允许。这也是为什么跨域问题只出现在浏览器环境中——服务端之间的HTTP请求完全没有这个限制Node、Python后端互相调接口一点事都没有。理解了这一点你再看各种跨域方案思路就很清晰了所有方案的本质都是想办法让浏览器相信这个跨域请求是安全的或者绕过浏览器的这个限制。1.2 跨域方案全景对比前端可选的跨域方案并不算多但每种方案的适用场景差异很大。我把常见的几类方案做了整理方案原理适用场景缺点CORS服务器在响应头中声明允许跨域前后端分离的主流方案需要后端配合配置JSONP利用script标签不受同源限制的特性老接口、只能GET请求只支持GET有安全隐患反向代理通过同源的代理服务器转发请求开发环境和生产环境均可用需要额外维护代理配置postMessage通过窗口消息机制跨窗口通信iframe嵌套页面通信需要双方页面配合WebSocket协议本身不受同源策略限制实时双向通信场景需要服务端支持其中CORS和反向代理是日常开发中用得最多的方案JSONP在老旧系统里偶尔还能见到postMessage在处理iframe嵌入场景时会用到。事到如今JSONP这套方案我基本不推荐新项目用了安全性问题多能力也有限能用CORS解决就不要给自己找麻烦。2. CORS配置实战从原理到错误排查2.1 CORS核心响应头与预检机制CORS全称Cross-Origin Resource Sharing跨域资源共享它做的事情是服务器在响应中带上特定的请求头告诉浏览器这个源可以访问我。最基础的响应头就三四个Access-Control-Allow-Origin允许的源可以指定具体域名也可以用*通配但*和携带凭证Cookie不能共存Access-Control-Allow-Methods允许的请求方法如GET、POST、PUT、DELETEAccess-Control-Allow-Headers允许的请求头如Content-Type、AuthorizationAccess-Control-Allow-Credentials是否允许携带凭证Cookie等设为true时前端还需要在XHR中设置withCredentials true这里有个关键机制叫预检请求Preflight Request。当你的请求不是简单请求时浏览器会先发一个OPTIONS请求探路服务器需要正确响应这个OPTIONS请求真正的请求才会发出。那什么算简单请求满足以下条件的基本算请求方法是GET、HEAD、POST之一请求头只包含常见的简单字段Accept、Accept-Language、Content-Language、Content-Type等Content-Type的值是application/x-www-form-urlencoded、multipart/form-data或text/plain也就是说如果你用Content-Type: application/json发POST请求就已经不满足简单请求了浏览器会先发OPTIONS预检。这一点在实际开发中经常踩坑明明后端接口已经写好了CORS配置但还是报跨域错误一查发现预检请求压根没被处理。注意预检请求本身是不带业务参数的它就是一个探测请求。后端处理的时候只需要返回CORS响应头不需要执行业务逻辑。很多人上来就加一个全局拦截器处理OPTIONS请求这是个省事但也容易出问题的做法后面会细说。2.2 Vue开发环境代理与nginx生产环境代理的配合开发环境很多人用的是Vue CLR或Vite自带的代理功能。原理很简单你让前端开发服务器接收同源请求然后由这个开发服务器去转发到真实后端地址。比如Vite配置// vite.config.js export default { server: { proxy: { /api: { target: http://localhost:3000, changeOrigin: true, rewrite: (path) path.replace(/^\/api/, ) } } } }这段配置的意思是凡是请求/api开头的接口Vite开发服务器都会把它转发给http://localhost:3000并把/api前缀去掉。浏览器看到的是请求http://localhost:8080/api/xxx跟自己同源根本不触发跨域限制。但要注意开发环境代理只是骗过了浏览器的检查并没有真正解决生产环境的跨域问题。如果你把前端打包后部署到nginx上而接口在另一个域名下照样跨域。生产环境同样需要nginx反向代理server { listen 80; server_name your-domain.com; location /api/ { proxy_pass http://backend-server:3000/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }这里proxy_pass后面带不带斜杠有讲究http://backend-server:3000/会把/api之后的部分拼接到后端地址后面不带斜杠则会把整个/api/xxx拼上去具体用哪种要看后端实际的路由设计。我见过很多人开发环境用代理一切正常一上生产就报跨域最后发现是nginx配置漏了。建议从一开始就按开发环境代理生产环境nginx代理双方案来设计避免临上线了手忙脚乱。2.3 常见CORS配置错误排查实录我在实际项目里排查跨域问题总结出一套比较固定的排查顺序分享给大家第一步看浏览器控制台的报错信息。报错会明确说是CORS policy哪一项不通过是Allow-Origin不存在还是请求头不被允许还是凭证问题。第二步看Network面板里有没有OPTIONS请求。如果浏览器发了预检请求但服务器没响应说明后端没处理OPTIONS或者CORS配置没生效。第三步检查响应头。看一眼服务器的响应里有没有Access-Control-Allow-*这些头。没有的话问题一定在后端配置有的话核对Content-Type、Authorization这些请求头是否在允许列表里。第四步如果涉及Cookie确认是否同时满足三件事浏览器请求带了withCredentials、服务器返回了Access-Control-Allow-Credentials: true、Access-Control-Allow-Origin必须是具体域名而不能是*。四步走下来80%的CORS问题都能定位。这里分享一个我踩过很深的坑后端配置了Access-Control-Allow-Origin: *但前端需要携带认证Cookie结果浏览器直接说Cannot use wildcard... credentials。这两者天然矛盾必须改成具体源。如果你做了登录功能或者任何需要识别的用户身份的场景*一律不可取要配置为白名单机制。另外一个常见的误解是有些人觉得只要前端配了代理后端就不需要配CORS了。实际上如果代理只在开发环境生效生产环境前端和后端不是同源后端依然要配CORS否则生产环境必现跨域错误。3. SSE轻量级的服务端推送方案3.1 SSE协议的工作机制SSEServer-Sent Events的全称是服务端发送事件。它通过HTTP协议提供了一种服务端向客户端单向推送数据的能力。这里的关键词是单向——只能是服务端推送到客户端客户端不能通过这个通道往服务端发消息。如果需要客户端反馈得另发普通HTTP请求。SSE的工作方式不算复杂客户端通过EventSource接口发起一个HTTP请求服务端收到后不立即结束响应而是以text/event-stream格式持续输出数据。连接一旦建立服务端可以随时把事件推送下来。用一段简单的Node.js代码做演示const http require(http); http.createServer((req, res) { if (req.url /events) { res.writeHead(200, { Content-Type: text/event-stream, Cache-Control: no-cache, Connection: keep-alive, Access-Control-Allow-Origin: http://localhost:8080 }); let id 0; const timer setInterval(() { res.write(id: ${id}\n); res.write(data: ${JSON.stringify({ time: new Date().toISOString() })}\n\n); id; }, 1000); req.on(close, () clearInterval(timer)); } }).listen(3000);前端使用const eventSource new EventSource(http://localhost:3000/events); eventSource.onopen () console.log(连接已建立); eventSource.onmessage (event) { const data JSON.parse(event.data); console.log(收到消息:, data); }; eventSource.onerror (err) console.error(发生错误:, err);SSE还有个很好用的特性是自动重连。当连接意外断开EventSource会自动尝试重新连接而且可以通过响应中的retry字段指定重连间隔。这是WebSocket需要自己实现心跳和重连逻辑所不具备的便捷性。3.2 SSE关键实现细节断线重连与鉴权SSE在使用中真正容易踩坑的其实是两个点断线重连的体验和鉴权问题。先说话断线重连。浏览器原生EventSource确实会自动重连但默认行为有时并不友好。比如服务器正常重启或者发生网络抖动客户端可能一直重试但一直失败用户侧表现为数据停住不动了。这时候需要通过lastEventId字段实现断点续传服务端在推送数据时带上id客户端在断线重连时自动把最后收到的id通过Last-Event-ID请求头发给服务端服务端据此决定从哪里开始继续推送。服务端代码示例// 读取客户端传来的 Last-Event-ID const lastEventId req.headers[last-event-id]; // 从该ID之后开始推送新数据 res.write(id: ${currentId}\n); res.write(data: ${JSON.stringify(newData)}\n\n);再说鉴权。使用原生的EventSource无法自定义请求头因为它的规范里不支持Authorization头部。这就比较尴尬了——很多后端接口都用JWT这种放在请求头里的token来鉴权SSE连不上头、没法带token怎么办我实践下来有几种可行方案URL带token把token放进查询字符串new EventSource(/events?tokenxxx)。优点是实现方便缺点是比较容易留在日志里不安全。短时凭证先请求一个接口换取短期有效的SSE专用凭证再带着这个凭证建立连接。Cookie鉴权如果系统和域名同源可以用Cookie鉴权配合HTTP请求头会一并携带的特性。我自己一般倾向方案2安全性最好代码也还算可控登录后先POST /api/sse-token获取一个短期token然后带着它去建立EventSource连接。这样即使token泄露有效期很短影响面可控。3.3 SSE的局限性与适用场景判断SSE好用的地方显而易见基于HTTP天然兼容各种网关和代理工具断线自动重连省了很多事文本数据直接就能用不需要额外的协议解析。不过它的局限性也比较明显单向通信。服务端推数据很舒服客户端要回传业务数据还得另发HTTP请求。连接数限制。浏览器对同域HTTP/1.1并发连接数有限制通常是6个如果页面里开了多个SSE连接很容易占满。数据格式限制。SSE走的是一条文本流二进制数据不是它的强项。老版本IE支持性差。不过现在还用IE的项目已经很少了可以忽略这个问题。适用场景也很清晰服务端需要定时或者按事件持续给前端推消息而且不需要前端额外发送控制指令的场景。典型如行情推送、告警通知、日志实时输出、AI生成内容的流式返回。这里额外提一句最新的fetch API也可以处理SSE流可以把EventSource换成fetch加ReadableStream来做更复杂的事件处理比如按消息类型分发不同的回调。4. WebSocket真正的双向实时通信4.1 从HTTP Upgrade握手的原理说起WebSocket设计的初衷就是实现浏览器与服务端之间的全双工通信。它最初通过HTTP发起一个握手请求服务器返回101 Switching Protocols之后连接协议升级为WebSocket此后双方都不再受HTTP请求-响应模式的限制可以随时随地互相发数据。完整的握手过程大家应该不陌生GET /chat HTTP/1.1 Host: example.com Upgrade: websocket Connection: Upgrade Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ Sec-WebSocket-Version: 13服务端返回HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbKxOo注意这里有个关键点WebSocket连接不受同源策略限制。为什么因为WebSocket不是XHR那种标准请求浏览器的同源策略主要约束document、XHR等资源访问WebSocket的跨域验证逻辑不同交由服务端通过Sec-WebSocket-Protocol等请求头自行判断是否接受连接。所以在网络层面WebSocket天然就是跨域的不需要配CORS。但这不代表你可以随便跨域连接WebSocket服务器。服务端需要做Origin校验如果是浏览器客户端发来的连接请求务必检查请求头里的Origin字段阻断来自未知来源的连接。4.2 前端WebSocket使用实践心跳、重连、二进制前端使用WebSocket非常直接const ws new WebSocket(ws://localhost:8080/ws); ws.onopen () { console.log(连接已建立); ws.send(JSON.stringify({ type: auth, token: your-jwt-token })); }; ws.onmessage (event) { const data JSON.parse(event.data); console.log(收到消息:, data); }; ws.onclose (event) { console.log(连接关闭code:, event.code, reason:, event.reason); }; ws.onerror (error) { console.error(WebSocket错误:, error); };看起来简单但实际生产环境中需要重点处理以下三件事心跳机制、自动重连、消息队列。先说心跳机制。WebSocket连接可能因为网络波动、中间代理超时等原因在双方都不知道的情况下悄悄断掉。最明显的表现是连接看起来还开着但消息已经发不出去了。解决思路是客户端定时发送ping消息比如每30秒服务端收到后返回pong如果在N秒内没收到pong就判定连接失效主动关闭并触发重连。let heartbeatTimer null; function startHeartbeat(ws) { stopHeartbeat(); heartbeatTimer setInterval(() { if (ws.readyState WebSocket.OPEN) { ws.send(ping); } }, 30000); } function stopHeartbeat() { if (heartbeatTimer) { clearInterval(heartbeatTimer); heartbeatTimer null; } }再说自动重连。原生WebSocket没有自动重连机制连接关闭后Game Over。你需要在onclose里写重连逻辑。但重连不能是简单的setTimeout new WebSocket必须处理一个经典陷阱服务端重启或者网络恢复期间如果持续重连失败会造成大量无效请求。建议采用指数退避策略第一次1秒后重试第二次2秒第三次4秒以此类推直到达到上限比如30秒。let retryCount 0; function connect() { const ws new WebSocket(ws://localhost:8080/ws); ws.onopen () { retryCount 0; console.log(WebSocket连接已建立); }; ws.onclose (event) { console.log(连接关闭准备重连...); const delay Math.min(1000 * Math.pow(2, retryCount), 30000); retryCount; setTimeout(connect, delay); }; ws.onerror (error) { ws.close(); }; } connect();最后说消息队列。WebSocket连接建立之前所有业务发送请求都会失败。我的习惯是维护一个本地队列在onopen之前有send操作就先进队列onopen之后统一发送。同时给消息加自增ID发送失败时可以重发重发时避免重复执行。4.3 踩坑实录H5调试正常但打包APP连不上这个问题在热搜词里频繁出现我单独拿出来讲。现象是H5页面在浏览器里开着WebSocket一切正常打包成App之后连接不上报各种连接错误。根因往往是网络权限或域名白名单问题。第一如果是Android原生WebView需要在manifest里声明INTERNET权限很多打包框架默认不给开导致WebSocket请求被系统拦截浏览器里正常App里直接失败。第二如果用了.NET或者uni-app这类跨端框架打包时的域名白名单/网络配置可能限制了WebSocket连接的地址。比如微信小程序里wss://协议和对应域名必须在后台配置为合法域名开发工具里可以关闭校验合法域名才连得上正式环境漏配就直接失败。第三检查是不是混用了ws和wss。线上环境不允许明文WebSocket连接浏览器可能默认允许但App原生网络栈可能要求必须TLS加密所以开发环境用ws://上线必须换成wss://。第四还有可能是局域网地址问题。让WebSocket连接192.168.x.x这种局域网地址浏览器在PC端可能可以但手机上、App里对外访问不一定可达需要确认网络环境是否同一局域网。排查建议打包后先抓包看错误日志和网络请求确认是权限问题、域名问题还是网络问题再针对处理。千万别在浏览器里调通就默认App一定没问题。4.4 鉴权与安全WebSocket的token怎么带WebSocket鉴权跟在HTTP里带token有点不一样。因为WebSocketAPI不支持自定义请求头所以带token主要是两种方式URL查询参数new WebSocket(ws://domain/ws?token token)子协议字段new WebSocket(ws://domain/ws, [auth, token])第一种简单直接但token可能出现在日志里有泄露风险。第二种稍微安全一点但也仅在握手阶段做了认证后续消息的加密和校验还是需要应用层配合。后端鉴权时Gin框架的中间件或Netty的ChannelInboundHandlerAdapter里提前校验握手请求的token校验不通过直接拒绝连接。这块几乎成了WebSocket面试的必问题如何对WebSocket请求做鉴权。核心在于握手阶段完成身份校验后续消息就不需要重复验证了——因为连接已经建立信道是唯一的。此外要注意不要迷信WebSocket框架自带的鉴权配置。底层库往往只管连接和消息转发业务token校验必须自己在中间件里写。我有一次遇到线上安全扫描报告网关居然允许直接连接WebSocket服务端跳过登录排查发现是默认配置完全没校验只是前端代码里看似要求了token。5. 选型建议SSE还是WebSocket还是混着来5.1 核心场景对比很多人在SSE和WebSocket之间纠结我先给一个直观对比维度SSEWebSocket通信方向服务端单向推送双向全双工协议基于HTTP独立协议ws/wss自动重连原生支持需要自己实现二进制数据不支持支持鉴权方式EventSource不能自定义请求头握手时通过URL/子协议带token实现复杂度简单相对复杂典型场景AI流式输出、通知推送聊天、协同编辑、实时游戏我个人的经验是能选SSE就不要轻易上WebSocket。WebSocket虽然能力强大但能力强通常意味着要自己处理的事情多——心跳、重连、消息有序性、并发限制、鉴权、代理配置每个环节都可能埋坑。SSE基于HTTP天然兼容现有网关、代理、日志体系实现成本低很多。5.2 混合方案AI流式输出场景下的SSE普通HTTP现在的AI对话应用大量使用SSE做流式输出。原因也很简单大模型生成内容需要时间如果等全部生成完再一次性返回用户等得难受。SSE可以逐字逐句把生成结果推下来体验接近打字机效果。有些场景还会把SSE和普通HTTP请求混着用。比如用户发送消息普通HTTP POST消息进入队列AI开始处理SSE连接推送处理进度和最终结果这种设计的好处是发送消息不需要长时间占用连接出错重试也简单推送消息用SSE断线自动重连体验好。如果你用的是FastAPI或Django、Express这类框架SSE实现起来成本很低本质上就是开个长连接流式写响应。但要注意一下SSE连接在大部分服务器网关里仍然占用一个worker或连接槽位并发量特别高的时候要评估资源开销。6. 面试高频题与团队实战中踩过的坑6.1 我常问团队候选人的几个问题自己带前端团队这几年回答过也提问过很多跨域和WebSocket相关的问题。有几个问题我几乎每次面试都会问大家也可以拿来自测讲一下JSONP的原理和为什么只能GET——考察基础。JSONP通过动态创建script标签来加载跨域内容script标签请求只有GET一种方式所以JSONP只能GET。CORS预检请求在什么情况下会发——考察对简单请求的理解。很多人会漏掉Content-Type为application/json会触发预检这一点这是最容易被忽略的业务场景。开发环境配置了代理为什么生产环境还要配CORS——考察对代理和CORS本质的理解。代理只是把请求转发到同源地址生产环境如果前端资源域名和API域名不一致依然跨域。SSE和WebSocket你会怎么选——考察方案选型能力。这里没有标准答案重点看候选人是否了解两种方案的差异和各自坑位。WebSocket断线了怎么办——考察工程经验。只回答重连不够还得说清心跳检测、指数退避、消息补偿这些细节。WebSocket安全上需要注意什么——考察安全认知。至少要说清Origin校验、token鉴权、wss加密传输、消息内容校验这几个点。6.2 问题定位速查表与工具推荐最后给大家整理一份我在实际项目中反复使用的速查表按症状倒查原因症状可能原因排查方向浏览器报CORS错误但接口能通预检请求未通过或响应头配置不全查看OPTIONS请求的响应头开发环境正常生产环境跨域nginx代理未配置或后端CORS未配置检查生产环境请求是否同源Cookie始终带不上Access-Control-Allow-Credentials未配置或*通配冲突核对三个条件是否同时满足EventSource一直断开重连服务端未发送合理的重连间隔或ID检查SSE响应头和lastEventIdWebSocket握手200非101服务端未正确响应Upgrade请求查看服务端日志检查反向代理配置App连不上WebSocketH5正常权限、白名单或wss没配抓包看App内的网络请求WebSocket连接1006异常关闭网络断开、服务端异常、代理超时抓包确认是否有RST查看服务端日志调试工具方面我常用的有浏览器DevTools的Network面板看预检请求和响应头Postman/Apifox测试后端接口的CORS配置是否返回正确响应头在线WebSocket测试工具快速验证服务端是否正常工作Charles/Fiddler抓包看App内的WebSocket帧跨域和实时通信这块其实没有太多绝招可言更多的还是底层原理得吃透工程细节踩一遍就有感觉了。我这些年最大的体会就是做前端不能只看怎么让页面跑起来还要理解每一次请求在浏览器、服务器、网络层经历了什么。跨域报错、WebSocket莫名掉线这种问题表面上是配置问题本质上都是对协议细节理解不够。搞懂原理再去调配置、写代码就顺手多了。
跨域这个老生常谈的话题几乎每次前端面试都会被翻出来但真要上手调接口的时候很多人还是被CORS报错、代理失效折腾得焦头烂额。而WebSocket和SSE这两兄弟一个负责双向实时通信一个擅长服务端单向推送要是搞不清选哪个代码写得再漂亮也白搭。这篇文章我尝试把跨域方案、SSE、WebSocket从原理到实战一次性理顺配合我这些年踩过的坑和排查思路希望能给正在写前端或者准备面试的朋友一点实实在在的帮助。1. 跨域问题浏览器的一道红线1.1 同源策略到底在保护什么先别急着背解决方案理解同源策略的本质比记住一堆配置项重要。同源指的是协议、域名、端口三者完全一致。只要有一个不一致浏览器就会视为跨域。比如http://localhost:8080请求http://localhost:3000虽然都是localhost但端口不同依然是跨域。浏览器之所以要设这道坎核心是为了保护用户的登录状态和敏感数据。设想一下如果你在A网站登录了银行账户浏览器里存了登录Cookie。这时候打开B网站B网站上有一段恶意脚本悄悄向银行的接口发请求。如果没有同源策略限制这个请求会被浏览器正常携带Cookie发送银行服务器拿到合法凭证就可能返回用户隐私数据B网站的脚本就能读取并盗走。所以同源策略本质上是浏览器的安全边界页面里的脚本只能访问同源资源跨域请求必须经过服务器的明确允许。这也是为什么跨域问题只出现在浏览器环境中——服务端之间的HTTP请求完全没有这个限制Node、Python后端互相调接口一点事都没有。理解了这一点你再看各种跨域方案思路就很清晰了所有方案的本质都是想办法让浏览器相信这个跨域请求是安全的或者绕过浏览器的这个限制。1.2 跨域方案全景对比前端可选的跨域方案并不算多但每种方案的适用场景差异很大。我把常见的几类方案做了整理方案原理适用场景缺点CORS服务器在响应头中声明允许跨域前后端分离的主流方案需要后端配合配置JSONP利用script标签不受同源限制的特性老接口、只能GET请求只支持GET有安全隐患反向代理通过同源的代理服务器转发请求开发环境和生产环境均可用需要额外维护代理配置postMessage通过窗口消息机制跨窗口通信iframe嵌套页面通信需要双方页面配合WebSocket协议本身不受同源策略限制实时双向通信场景需要服务端支持其中CORS和反向代理是日常开发中用得最多的方案JSONP在老旧系统里偶尔还能见到postMessage在处理iframe嵌入场景时会用到。事到如今JSONP这套方案我基本不推荐新项目用了安全性问题多能力也有限能用CORS解决就不要给自己找麻烦。2. CORS配置实战从原理到错误排查2.1 CORS核心响应头与预检机制CORS全称Cross-Origin Resource Sharing跨域资源共享它做的事情是服务器在响应中带上特定的请求头告诉浏览器这个源可以访问我。最基础的响应头就三四个Access-Control-Allow-Origin允许的源可以指定具体域名也可以用*通配但*和携带凭证Cookie不能共存Access-Control-Allow-Methods允许的请求方法如GET、POST、PUT、DELETEAccess-Control-Allow-Headers允许的请求头如Content-Type、AuthorizationAccess-Control-Allow-Credentials是否允许携带凭证Cookie等设为true时前端还需要在XHR中设置withCredentials true这里有个关键机制叫预检请求Preflight Request。当你的请求不是简单请求时浏览器会先发一个OPTIONS请求探路服务器需要正确响应这个OPTIONS请求真正的请求才会发出。那什么算简单请求满足以下条件的基本算请求方法是GET、HEAD、POST之一请求头只包含常见的简单字段Accept、Accept-Language、Content-Language、Content-Type等Content-Type的值是application/x-www-form-urlencoded、multipart/form-data或text/plain也就是说如果你用Content-Type: application/json发POST请求就已经不满足简单请求了浏览器会先发OPTIONS预检。这一点在实际开发中经常踩坑明明后端接口已经写好了CORS配置但还是报跨域错误一查发现预检请求压根没被处理。注意预检请求本身是不带业务参数的它就是一个探测请求。后端处理的时候只需要返回CORS响应头不需要执行业务逻辑。很多人上来就加一个全局拦截器处理OPTIONS请求这是个省事但也容易出问题的做法后面会细说。2.2 Vue开发环境代理与nginx生产环境代理的配合开发环境很多人用的是Vue CLR或Vite自带的代理功能。原理很简单你让前端开发服务器接收同源请求然后由这个开发服务器去转发到真实后端地址。比如Vite配置// vite.config.js export default { server: { proxy: { /api: { target: http://localhost:3000, changeOrigin: true, rewrite: (path) path.replace(/^\/api/, ) } } } }这段配置的意思是凡是请求/api开头的接口Vite开发服务器都会把它转发给http://localhost:3000并把/api前缀去掉。浏览器看到的是请求http://localhost:8080/api/xxx跟自己同源根本不触发跨域限制。但要注意开发环境代理只是骗过了浏览器的检查并没有真正解决生产环境的跨域问题。如果你把前端打包后部署到nginx上而接口在另一个域名下照样跨域。生产环境同样需要nginx反向代理server { listen 80; server_name your-domain.com; location /api/ { proxy_pass http://backend-server:3000/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }这里proxy_pass后面带不带斜杠有讲究http://backend-server:3000/会把/api之后的部分拼接到后端地址后面不带斜杠则会把整个/api/xxx拼上去具体用哪种要看后端实际的路由设计。我见过很多人开发环境用代理一切正常一上生产就报跨域最后发现是nginx配置漏了。建议从一开始就按开发环境代理生产环境nginx代理双方案来设计避免临上线了手忙脚乱。2.3 常见CORS配置错误排查实录我在实际项目里排查跨域问题总结出一套比较固定的排查顺序分享给大家第一步看浏览器控制台的报错信息。报错会明确说是CORS policy哪一项不通过是Allow-Origin不存在还是请求头不被允许还是凭证问题。第二步看Network面板里有没有OPTIONS请求。如果浏览器发了预检请求但服务器没响应说明后端没处理OPTIONS或者CORS配置没生效。第三步检查响应头。看一眼服务器的响应里有没有Access-Control-Allow-*这些头。没有的话问题一定在后端配置有的话核对Content-Type、Authorization这些请求头是否在允许列表里。第四步如果涉及Cookie确认是否同时满足三件事浏览器请求带了withCredentials、服务器返回了Access-Control-Allow-Credentials: true、Access-Control-Allow-Origin必须是具体域名而不能是*。四步走下来80%的CORS问题都能定位。这里分享一个我踩过很深的坑后端配置了Access-Control-Allow-Origin: *但前端需要携带认证Cookie结果浏览器直接说Cannot use wildcard... credentials。这两者天然矛盾必须改成具体源。如果你做了登录功能或者任何需要识别的用户身份的场景*一律不可取要配置为白名单机制。另外一个常见的误解是有些人觉得只要前端配了代理后端就不需要配CORS了。实际上如果代理只在开发环境生效生产环境前端和后端不是同源后端依然要配CORS否则生产环境必现跨域错误。3. SSE轻量级的服务端推送方案3.1 SSE协议的工作机制SSEServer-Sent Events的全称是服务端发送事件。它通过HTTP协议提供了一种服务端向客户端单向推送数据的能力。这里的关键词是单向——只能是服务端推送到客户端客户端不能通过这个通道往服务端发消息。如果需要客户端反馈得另发普通HTTP请求。SSE的工作方式不算复杂客户端通过EventSource接口发起一个HTTP请求服务端收到后不立即结束响应而是以text/event-stream格式持续输出数据。连接一旦建立服务端可以随时把事件推送下来。用一段简单的Node.js代码做演示const http require(http); http.createServer((req, res) { if (req.url /events) { res.writeHead(200, { Content-Type: text/event-stream, Cache-Control: no-cache, Connection: keep-alive, Access-Control-Allow-Origin: http://localhost:8080 }); let id 0; const timer setInterval(() { res.write(id: ${id}\n); res.write(data: ${JSON.stringify({ time: new Date().toISOString() })}\n\n); id; }, 1000); req.on(close, () clearInterval(timer)); } }).listen(3000);前端使用const eventSource new EventSource(http://localhost:3000/events); eventSource.onopen () console.log(连接已建立); eventSource.onmessage (event) { const data JSON.parse(event.data); console.log(收到消息:, data); }; eventSource.onerror (err) console.error(发生错误:, err);SSE还有个很好用的特性是自动重连。当连接意外断开EventSource会自动尝试重新连接而且可以通过响应中的retry字段指定重连间隔。这是WebSocket需要自己实现心跳和重连逻辑所不具备的便捷性。3.2 SSE关键实现细节断线重连与鉴权SSE在使用中真正容易踩坑的其实是两个点断线重连的体验和鉴权问题。先说话断线重连。浏览器原生EventSource确实会自动重连但默认行为有时并不友好。比如服务器正常重启或者发生网络抖动客户端可能一直重试但一直失败用户侧表现为数据停住不动了。这时候需要通过lastEventId字段实现断点续传服务端在推送数据时带上id客户端在断线重连时自动把最后收到的id通过Last-Event-ID请求头发给服务端服务端据此决定从哪里开始继续推送。服务端代码示例// 读取客户端传来的 Last-Event-ID const lastEventId req.headers[last-event-id]; // 从该ID之后开始推送新数据 res.write(id: ${currentId}\n); res.write(data: ${JSON.stringify(newData)}\n\n);再说鉴权。使用原生的EventSource无法自定义请求头因为它的规范里不支持Authorization头部。这就比较尴尬了——很多后端接口都用JWT这种放在请求头里的token来鉴权SSE连不上头、没法带token怎么办我实践下来有几种可行方案URL带token把token放进查询字符串new EventSource(/events?tokenxxx)。优点是实现方便缺点是比较容易留在日志里不安全。短时凭证先请求一个接口换取短期有效的SSE专用凭证再带着这个凭证建立连接。Cookie鉴权如果系统和域名同源可以用Cookie鉴权配合HTTP请求头会一并携带的特性。我自己一般倾向方案2安全性最好代码也还算可控登录后先POST /api/sse-token获取一个短期token然后带着它去建立EventSource连接。这样即使token泄露有效期很短影响面可控。3.3 SSE的局限性与适用场景判断SSE好用的地方显而易见基于HTTP天然兼容各种网关和代理工具断线自动重连省了很多事文本数据直接就能用不需要额外的协议解析。不过它的局限性也比较明显单向通信。服务端推数据很舒服客户端要回传业务数据还得另发HTTP请求。连接数限制。浏览器对同域HTTP/1.1并发连接数有限制通常是6个如果页面里开了多个SSE连接很容易占满。数据格式限制。SSE走的是一条文本流二进制数据不是它的强项。老版本IE支持性差。不过现在还用IE的项目已经很少了可以忽略这个问题。适用场景也很清晰服务端需要定时或者按事件持续给前端推消息而且不需要前端额外发送控制指令的场景。典型如行情推送、告警通知、日志实时输出、AI生成内容的流式返回。这里额外提一句最新的fetch API也可以处理SSE流可以把EventSource换成fetch加ReadableStream来做更复杂的事件处理比如按消息类型分发不同的回调。4. WebSocket真正的双向实时通信4.1 从HTTP Upgrade握手的原理说起WebSocket设计的初衷就是实现浏览器与服务端之间的全双工通信。它最初通过HTTP发起一个握手请求服务器返回101 Switching Protocols之后连接协议升级为WebSocket此后双方都不再受HTTP请求-响应模式的限制可以随时随地互相发数据。完整的握手过程大家应该不陌生GET /chat HTTP/1.1 Host: example.com Upgrade: websocket Connection: Upgrade Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ Sec-WebSocket-Version: 13服务端返回HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbKxOo注意这里有个关键点WebSocket连接不受同源策略限制。为什么因为WebSocket不是XHR那种标准请求浏览器的同源策略主要约束document、XHR等资源访问WebSocket的跨域验证逻辑不同交由服务端通过Sec-WebSocket-Protocol等请求头自行判断是否接受连接。所以在网络层面WebSocket天然就是跨域的不需要配CORS。但这不代表你可以随便跨域连接WebSocket服务器。服务端需要做Origin校验如果是浏览器客户端发来的连接请求务必检查请求头里的Origin字段阻断来自未知来源的连接。4.2 前端WebSocket使用实践心跳、重连、二进制前端使用WebSocket非常直接const ws new WebSocket(ws://localhost:8080/ws); ws.onopen () { console.log(连接已建立); ws.send(JSON.stringify({ type: auth, token: your-jwt-token })); }; ws.onmessage (event) { const data JSON.parse(event.data); console.log(收到消息:, data); }; ws.onclose (event) { console.log(连接关闭code:, event.code, reason:, event.reason); }; ws.onerror (error) { console.error(WebSocket错误:, error); };看起来简单但实际生产环境中需要重点处理以下三件事心跳机制、自动重连、消息队列。先说心跳机制。WebSocket连接可能因为网络波动、中间代理超时等原因在双方都不知道的情况下悄悄断掉。最明显的表现是连接看起来还开着但消息已经发不出去了。解决思路是客户端定时发送ping消息比如每30秒服务端收到后返回pong如果在N秒内没收到pong就判定连接失效主动关闭并触发重连。let heartbeatTimer null; function startHeartbeat(ws) { stopHeartbeat(); heartbeatTimer setInterval(() { if (ws.readyState WebSocket.OPEN) { ws.send(ping); } }, 30000); } function stopHeartbeat() { if (heartbeatTimer) { clearInterval(heartbeatTimer); heartbeatTimer null; } }再说自动重连。原生WebSocket没有自动重连机制连接关闭后Game Over。你需要在onclose里写重连逻辑。但重连不能是简单的setTimeout new WebSocket必须处理一个经典陷阱服务端重启或者网络恢复期间如果持续重连失败会造成大量无效请求。建议采用指数退避策略第一次1秒后重试第二次2秒第三次4秒以此类推直到达到上限比如30秒。let retryCount 0; function connect() { const ws new WebSocket(ws://localhost:8080/ws); ws.onopen () { retryCount 0; console.log(WebSocket连接已建立); }; ws.onclose (event) { console.log(连接关闭准备重连...); const delay Math.min(1000 * Math.pow(2, retryCount), 30000); retryCount; setTimeout(connect, delay); }; ws.onerror (error) { ws.close(); }; } connect();最后说消息队列。WebSocket连接建立之前所有业务发送请求都会失败。我的习惯是维护一个本地队列在onopen之前有send操作就先进队列onopen之后统一发送。同时给消息加自增ID发送失败时可以重发重发时避免重复执行。4.3 踩坑实录H5调试正常但打包APP连不上这个问题在热搜词里频繁出现我单独拿出来讲。现象是H5页面在浏览器里开着WebSocket一切正常打包成App之后连接不上报各种连接错误。根因往往是网络权限或域名白名单问题。第一如果是Android原生WebView需要在manifest里声明INTERNET权限很多打包框架默认不给开导致WebSocket请求被系统拦截浏览器里正常App里直接失败。第二如果用了.NET或者uni-app这类跨端框架打包时的域名白名单/网络配置可能限制了WebSocket连接的地址。比如微信小程序里wss://协议和对应域名必须在后台配置为合法域名开发工具里可以关闭校验合法域名才连得上正式环境漏配就直接失败。第三检查是不是混用了ws和wss。线上环境不允许明文WebSocket连接浏览器可能默认允许但App原生网络栈可能要求必须TLS加密所以开发环境用ws://上线必须换成wss://。第四还有可能是局域网地址问题。让WebSocket连接192.168.x.x这种局域网地址浏览器在PC端可能可以但手机上、App里对外访问不一定可达需要确认网络环境是否同一局域网。排查建议打包后先抓包看错误日志和网络请求确认是权限问题、域名问题还是网络问题再针对处理。千万别在浏览器里调通就默认App一定没问题。4.4 鉴权与安全WebSocket的token怎么带WebSocket鉴权跟在HTTP里带token有点不一样。因为WebSocketAPI不支持自定义请求头所以带token主要是两种方式URL查询参数new WebSocket(ws://domain/ws?token token)子协议字段new WebSocket(ws://domain/ws, [auth, token])第一种简单直接但token可能出现在日志里有泄露风险。第二种稍微安全一点但也仅在握手阶段做了认证后续消息的加密和校验还是需要应用层配合。后端鉴权时Gin框架的中间件或Netty的ChannelInboundHandlerAdapter里提前校验握手请求的token校验不通过直接拒绝连接。这块几乎成了WebSocket面试的必问题如何对WebSocket请求做鉴权。核心在于握手阶段完成身份校验后续消息就不需要重复验证了——因为连接已经建立信道是唯一的。此外要注意不要迷信WebSocket框架自带的鉴权配置。底层库往往只管连接和消息转发业务token校验必须自己在中间件里写。我有一次遇到线上安全扫描报告网关居然允许直接连接WebSocket服务端跳过登录排查发现是默认配置完全没校验只是前端代码里看似要求了token。5. 选型建议SSE还是WebSocket还是混着来5.1 核心场景对比很多人在SSE和WebSocket之间纠结我先给一个直观对比维度SSEWebSocket通信方向服务端单向推送双向全双工协议基于HTTP独立协议ws/wss自动重连原生支持需要自己实现二进制数据不支持支持鉴权方式EventSource不能自定义请求头握手时通过URL/子协议带token实现复杂度简单相对复杂典型场景AI流式输出、通知推送聊天、协同编辑、实时游戏我个人的经验是能选SSE就不要轻易上WebSocket。WebSocket虽然能力强大但能力强通常意味着要自己处理的事情多——心跳、重连、消息有序性、并发限制、鉴权、代理配置每个环节都可能埋坑。SSE基于HTTP天然兼容现有网关、代理、日志体系实现成本低很多。5.2 混合方案AI流式输出场景下的SSE普通HTTP现在的AI对话应用大量使用SSE做流式输出。原因也很简单大模型生成内容需要时间如果等全部生成完再一次性返回用户等得难受。SSE可以逐字逐句把生成结果推下来体验接近打字机效果。有些场景还会把SSE和普通HTTP请求混着用。比如用户发送消息普通HTTP POST消息进入队列AI开始处理SSE连接推送处理进度和最终结果这种设计的好处是发送消息不需要长时间占用连接出错重试也简单推送消息用SSE断线自动重连体验好。如果你用的是FastAPI或Django、Express这类框架SSE实现起来成本很低本质上就是开个长连接流式写响应。但要注意一下SSE连接在大部分服务器网关里仍然占用一个worker或连接槽位并发量特别高的时候要评估资源开销。6. 面试高频题与团队实战中踩过的坑6.1 我常问团队候选人的几个问题自己带前端团队这几年回答过也提问过很多跨域和WebSocket相关的问题。有几个问题我几乎每次面试都会问大家也可以拿来自测讲一下JSONP的原理和为什么只能GET——考察基础。JSONP通过动态创建script标签来加载跨域内容script标签请求只有GET一种方式所以JSONP只能GET。CORS预检请求在什么情况下会发——考察对简单请求的理解。很多人会漏掉Content-Type为application/json会触发预检这一点这是最容易被忽略的业务场景。开发环境配置了代理为什么生产环境还要配CORS——考察对代理和CORS本质的理解。代理只是把请求转发到同源地址生产环境如果前端资源域名和API域名不一致依然跨域。SSE和WebSocket你会怎么选——考察方案选型能力。这里没有标准答案重点看候选人是否了解两种方案的差异和各自坑位。WebSocket断线了怎么办——考察工程经验。只回答重连不够还得说清心跳检测、指数退避、消息补偿这些细节。WebSocket安全上需要注意什么——考察安全认知。至少要说清Origin校验、token鉴权、wss加密传输、消息内容校验这几个点。6.2 问题定位速查表与工具推荐最后给大家整理一份我在实际项目中反复使用的速查表按症状倒查原因症状可能原因排查方向浏览器报CORS错误但接口能通预检请求未通过或响应头配置不全查看OPTIONS请求的响应头开发环境正常生产环境跨域nginx代理未配置或后端CORS未配置检查生产环境请求是否同源Cookie始终带不上Access-Control-Allow-Credentials未配置或*通配冲突核对三个条件是否同时满足EventSource一直断开重连服务端未发送合理的重连间隔或ID检查SSE响应头和lastEventIdWebSocket握手200非101服务端未正确响应Upgrade请求查看服务端日志检查反向代理配置App连不上WebSocketH5正常权限、白名单或wss没配抓包看App内的网络请求WebSocket连接1006异常关闭网络断开、服务端异常、代理超时抓包确认是否有RST查看服务端日志调试工具方面我常用的有浏览器DevTools的Network面板看预检请求和响应头Postman/Apifox测试后端接口的CORS配置是否返回正确响应头在线WebSocket测试工具快速验证服务端是否正常工作Charles/Fiddler抓包看App内的WebSocket帧跨域和实时通信这块其实没有太多绝招可言更多的还是底层原理得吃透工程细节踩一遍就有感觉了。我这些年最大的体会就是做前端不能只看怎么让页面跑起来还要理解每一次请求在浏览器、服务器、网络层经历了什么。跨域报错、WebSocket莫名掉线这种问题表面上是配置问题本质上都是对协议细节理解不够。搞懂原理再去调配置、写代码就顺手多了。
