企业官网建设流程全解析

1. 跨域到底挡的是什么：同源策略、CORS 与 Nginx 的边界

前端圈里有个很有意思的现象：几乎每个团队都遇到过“跨域访问被拒绝，请检查浏览器配置!”这种报错，但真正能把这个报错背后的机制讲清楚的人，其实不多。我见过太多人一遇到跨域问题就条件反射式地往 Nginx 配一段add_header Access-Control-Allow-Origin *，配完发现没用，又去查所谓“浏览器配置”，最后折腾大半天才发现是后端没带响应头或者请求触发了预检却没人处理OPTIONS。

先把最基础的事情说透：跨域是浏览器行为，不是 HTTP 协议层面的限制，更不是服务器之间的通信障碍。服务器 A 想请求服务器 B，用 curl、用 Python、用 Node.js 都可以畅通无阻，因为这不是浏览器的环境。但一旦换成浏览器里的 JavaScript 发请求，浏览器的同源策略就会介入——它要求请求的协议、域名、端口三者完全一致，只要有一个不一致，就构成跨域。

同源策略的本意是保护用户。你可以把它想象成快递柜的取件规则：快递员把包裹放进柜子，用户必须用自己手机号对应的取件码才能取件。如果任何人都能取走任意柜子里的包裹，那用户的隐私就全完了。同样的道理，如果任何网站都能通过 JavaScript 去读取你已登录的银行页面数据，那你在网上就没有隐私可言了。

1.1 CORS 工作的真实流程：简单请求与预检请求

CORS 全称是 Cross-Origin Resource Sharing，它做的事情是：让服务器明确告诉浏览器“这个跨域请求是我允许的”。这套机制下浏览器把请求分成两类。

简单请求需要同时满足几个条件：使用 GET、HEAD、POST 这三个方法之一；Content-Type 只能是application/x-www-form-urlencoded、multipart/form-data或text/plain；不能自定义头（比如Authorization、X-Custom-Header）。简单请求的跨域过程是：浏览器直接发出请求，然后在响应头里检查服务器有没有返回Access-Control-Allow-Origin，如果这个头的值和当前站点域名匹配，浏览器才把响应交给 JavaScript，否则直接报跨域错误。

预检请求（Preflight Request）则是给“不简单”的请求准备的。当你的请求用了 DELETE、PUT、PATCH，或者带了自定义头，又或者 Content-Type 是application/json时，浏览器会先发一个OPTIONS请求到目标服务器，询问“我打算用这个方法、这些头，你允许吗？”服务器需要返回Access-Control-Allow-Methods和Access-Control-Allow-Headers，并且用Access-Control-Allow-Origin表明允许跨域，浏览器确认后才发真正的业务请求。

很多前端开发者在本地开发时接后端的接口，明明在代码里加了mode: 'cors'，还是报跨域，原因就是没搞懂预检请求不通过。我在实际项目里排查这类问题，第一件事就是打开 DevTools 的 Network 面板，找到那个标红的OPTIONS请求，看返回什么。绝大多数场景下，要么是后端没处理 OPTIONS，要么是 Nginx 层把 OPTIONS 拦截了。

1.2 Nginx 处理跨域的根因与正确姿势

这里必须澄清一个高频误区：很多人以为 Nginx 配了跨域头就能解决一切。实际上 Nginx 只是一个反向代理服务器，它能“解决”跨域的本质是因为它把前后端放在了同一个域名下，浏览器看到的请求是同源的，自然没有跨域问题。这和 CORS 完全是两条思路。

如果你不想动后端代码，用 Nginx 做反向代理是最干净的方案。比如前端部署在https://www.example.com，后端接口在https://api.example.com，你可以通过 Nginx 把/api/路径转发到http://127.0.0.1:8080：

server { listen 443 ssl; server_name www.example.com; location /api/ { proxy_pass http://127.0.0.1:8080/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }

这样配置之后，前端代码里请求/api/data就等同于请求https://www.example.com/api/data，浏览器的同源策略不再介入。如果你确实需要保留跨域请求的形态，也就是前端直接请求另一个域名的接口，那就必须让后端在响应头里做文章。Nginx 也可以代劳，但细节上很容易踩坑。最常见的坑是：只配了add_header Access-Control-Allow-Origin *，没有处理预检请求，或者没有配置Access-Control-Allow-Credentials却在前端代码里设置了withCredentials: true。

location /api/ { if ($request_method = 'OPTIONS') { add_header Access-Control-Allow-Origin $http_origin always; add_header Access-Control-Allow-Methods 'GET, POST, PUT, DELETE, PATCH, OPTIONS' always; add_header Access-Control-Allow-Headers 'Content-Type, Authorization, X-Requested-With' always; add_header Access-Control-Max-Age 86400; add_header Vary Origin; return 204; } add_header Access-Control-Allow-Origin $http_origin always; add_header Access-Control-Allow-Credentials true always; add_header Vary Origin; proxy_pass http://127.0.0.1:8080/; }

注意我用的是$http_origin而不是*，原因是Access-Control-Allow-Origin和Access-Control-Allow-Credentials: true不能同时使用*。这是一个极其隐蔽的坑，浏览器会严格检查这一点。另外always参数也容易被人忽略，如果不加，当某个请求返回非 2xx 状态码时，Nginx 可能不会附带 CORS 头，导致错误响应在浏览器里被拦截，前端拿不到真正的错误信息，排查起来非常痛苦。

1.3 JSONP 的现实定位：只适合 GET 请求的“老物件”

JSONP 在热搜词里还占着一席之地，这和很多老系统的遗留接口有关。JSONP 的原理是利用<script>标签不受同源策略限制的特性：动态插入一个<script>，src指向服务端接口并携带一个回调函数名，服务端返回一段可执行的 JavaScript 代码，调用这个回调函数并传入数据。

function jsonp(url, callbackName) { return new Promise((resolve, reject) => { const script = document.createElement('script'); script.src = `${url}?callback=${callbackName}`; window[callbackName] = (data) => { resolve(data); delete window[callbackName]; script.remove(); }; script.onerror = () => { reject(new Error('JSONP request failed')); delete window[callbackName]; script.remove(); }; document.body.appendChild(script); }); } jsonp('https://api.example.com/user?uid=123', 'handleUserData').then(data => { console.log(data); });

JSONP 的致命弱点有三个：只能发 GET 请求；无法处理非 2xx 状态码的错误信息；服务端需要配合返回 JavaScript 代码，安全上要非常小心回调函数名的注入问题。现在新项目基本不应该再选它，但如果你在维护老系统，或者对接某些第三方平台只提供了 JSONP 接口，还是需要知道它怎么工作。

2. SSE 与 EventSource：被压在 WebSocket 光芒下的单向实时利器

聊完跨域，进入实时通信。很多人一想到“实时”就脱口而出 WebSocket，但我在实际项目里发现，至少有三成的实时推送场景用 Server-Sent Events（SSE）更合适，而且实现成本低得多。SSE 在最近两年大火，和 AI 大模型的流式输出密切相关，很多人第一次接触 SSE 就是在对接 ChatGLM、GPT 这类接口的时候。

你可能会问：SSE 到底是什么？简单来说，它是基于 HTTP 协议的单向服务端推送技术。客户端发出一个普通的 HTTP 请求，服务器不立即返回完整响应，而是保持连接打开，不断向客户端发送数据块，直到主动关闭连接或超时。这在 HTTP 层面就是一个普通的text/event-stream响应流，走的还是 80/443 端口，不需要额外的握手协议，不受同源策略那套“特殊待遇”之外的限制——它遵守标准的 CORS 规则，所以跨域配置方式和普通 HTTP 请求完全一致。

2.1 SSE 协议的核心字段与完整实现

SSE 的消息格式非常简单，每一行以field: value的形式组织，常见的字段有data、event、id和retry。多个数据行组成一条消息，消息与消息之间用空行分隔。如果一条消息的数据量很大，可以拆成多行data字段，解析时服务端会用换行符拼接起来。

一个典型的 SSE 响应长这样：

id: 1 event: message data: {"text": "你好"} id: 2 event: message data: {"text": "世界"} event: done data: [DONE]

浏览器原生提供了EventSource对象来消费 SSE，它的最大优势是自动重连。一旦连接断开，浏览器会根据服务端返回的retry字段（单位毫秒）自动重新发起请求，不需要你写任何重连逻辑。同时，如果服务端在消息里带了id字段，浏览器在重连时会自动把Last-Event-ID头带给服务端，服务端据此判断该从哪条消息继续发送，这是 WebSocket 需要自己实现的功能。

但EventSource有个硬伤：不支持自定义请求头。这意味着如果你想在请求里带Authorization头对 SSE 接口做鉴权（“sse鉴权”这个词条在热搜里排名不低，可见是真实痛点），原生EventSource做不到。解决办法是改用fetch+ReadableStream自己读取流式数据：

async function connectSSE(url, token, handlers) { const response = await fetch(url, { headers: { 'Authorization': `Bearer ${token}`, 'Accept': 'text/event-stream', }, }); if (!response.ok) { throw new Error(`SSE connection failed: ${response.status}`); } const reader = response.body.getReader(); const decoder = new TextDecoder(); let buffer = ''; while (true) { const { value, done } = await reader.read(); if (done) break; buffer += decoder.decode(value, { stream: true }); // SSE 消息以空行分隔，按事件块处理 const events = buffer.split(/\r?\n\r?\n/); buffer = events.pop() || ''; for (const event of events) { const lines = event.split(/\r?\n/); const type = lines.find(l => l.startsWith('event:'))?.slice(6).trim() || 'message'; const data = lines .filter(l => l.startsWith('data:')) .map(l => l.slice(5).trim()) .join('\n'); if (handlers[type]) { handlers[type](data); } } } }

这个方案能自定义 header，也能像 EventSource 一样自动重连——你只需要在外层包一个while循环或者递归调用，断线时捕获异常后延时重试。

2.2 SSE 的自动重连机制与超时陷阱

上面提到Last-Event-ID是 SSE 一个非常实用的能力。服务端推送消息时给每条消息编一个递增的 ID，当客户端断线重连时，浏览器自动携带Last-Event-ID，服务端只需要对比这个 ID 就能知道客户端已经收到了哪些消息，把缺失的部分补发即可。这在实现消息可靠性上能省很多事。要注意的是，如果你用fetch方案，就得自己保存最后一次收到的 ID，并在重连时手动加到 header 里。

关于超时，热搜词里有一个很典型的错误：before completion: idle timeout waiting for sse。这个报错通常出现在使用 HTTP 网关（比如 Spring Cloud Gateway、Apifox 的 mock 服务或某些 API 网关）转发 SSE 请求时。网关默认的空闲超时时间很短，通常在 30 秒到 60 秒之间，如果服务端在这段时间内没有任何数据发送，网关就会主动断开连接。解决办法是调大网关的空闲超时配置。如果你用 Nginx 做代理，对应参数是proxy_read_timeout，实测中如果 AI 模型思考时间比较长，我建议直接设为3600s；如果用 Spring Cloud Gateway，需要设置spring.cloud.gateway.httpclient.pool.max-idle-time或者自定义NettyRoutingFilter的相关参数。

另外提一句后端框架的支持情况：Spring Boot 从 4.2 开始支持SseEmitter，Node.js 里用 Express 加text/event-stream中间件也很容易实现。如果是在 Go 里做 SSE，用 Gin 的话，设置完Content-Type后往http.ResponseWriter里不断Flush就行。

2.3 SSE 的适用边界：最多“单向”就够的场景

SSE 适合什么场景？凡是“客户端不需要发消息，只需要持续接收服务端推送”的场景，都值得优先考虑。典型的例子包括：AI 大模型的流式输出、股票行情、日志实时滚动、后台任务进度通知、服务端告警推送。这些场景的共同特点是数据流向是单向的，客户端对服务端的数据生成过程只能被动观察，没办法也不需要对服务端“说话”。这种情况下，用 WebSocket 就像用货车往隔壁送一份文件——能送到，但是过度设计了，而且复杂度翻倍。

SSE 也不是没有短处。它只能从服务端向客户端推送，客户端如果也要实时发消息，它就无能为力。另外，大部分浏览器对同一个域名的并发 SSE 连接数量有限制（一般是 6 个），如果你在一个页面上开了很多个 EventSource，会很快打满连接数。这时候要么考虑合并成一条连接按事件类型分发，要么评估是不是该上 WebSocket。

3. WebSocket 不只是“双向通信”：握手、心跳与断线重连

WebSocket 是这三个概念里最常被提起、也最常被误解的。很多人以为 WebSocket 就是“建立一个全双工通道，然后自由收发消息”，这句话不算错，但离真正能抗住生产环境压力还差得远。

WebSocket 的连接建立不是凭空发生的，它基于 HTTP 协议做了一次升级。客户端发起一个带Upgrade: websocket头的普通 HTTP 请求，服务器返回101 Switching Protocols，之后双方才在同一个 TCP 连接上以帧（frame）为单位传输数据。理解了这一点，你就会明白为什么 WebSocket 在跨域问题上表现得和普通 HTTP 请求如此相似，又如此不同。

3.1 WebSocket 跨域的真实机制：Origin 头说了算

WebSocket 不受浏览器同源策略的直接限制。也就是说，你在https://a.com页面上用new WebSocket('wss://b.com/socket')建立连接，浏览器不会像发普通 XHR 那样拦着不让你连。但这不代表服务器无所谓——标准规定，浏览器在发起 WebSocket 握手时，会自动带上Origin头，值为当前页面的源。服务器可以用Origin头做白名单校验，决定接受还是拒绝这个连接。

这里有一个经常被误解的点：既然浏览器不拦截 WebSocket 的跨域连接，服务端为什么还要关心Origin？答案是防止恶意网站利用用户的浏览器向你的服务器发起 WebSocket 连接。如果某个攻击者在他的网站上放一段 JavaScript，向wss://bank.com/socket发起握手，浏览器同样会放行。如果你的后端不校验Origin，攻击者就能借用用户的浏览器身份发起攻击。所以服务端必须校验Origin，不在白名单内的直接拒绝握手。

在 Nginx 层也可以提前校验，但更推荐在后端业务逻辑里做，因为后端能拿到用户会话信息，能做更细粒度的判断。前端通常不需要为 WebSocket 跨域做太多事情，浏览器在握手时自动处理了跨域协商，你只需要保证服务端配置正确。

3.2 1006 状态码背后的真相：为什么断线原因一片空白

“WebSocket onclose, code: 1006, reason:, reconnect: true” 是很多前端同学深夜加班的元凶。1006是一个很特殊的关闭码：它表示连接异常关闭，而且没有任何关闭原因。也就是说，浏览器收到了close帧，但没有提供reason字段，或者连接是直接被网络层中断的，根本没有机会收到关闭帧。

什么会导致 1006？我整理过一张问题对照表，直接列出我在项目中遇到过的所有可能性：

排查 1006 一个特别有用的技巧：用 Wireshark 抓包看 TCP 层的行为。如果看到的是 RST 包，说明服务端或中间设备主动重置了连接；如果看到 FIN 包，是某一端正常发起了关闭流程；如果是静默断开（没收到任何包），那基本可以判定是连接空闲超时被中间设备清理了。这个区分能把排查范围缩小很多。

3.3 心跳机制：为什么不能依赖 TCP 的“看似连接”

WebSocket 的底层是 TCP，但 TCP 本身并不能保证连接“活着”。举个例子：你的手机连着 WiFi，信号显示满格，但路由器其实已经断网了——此时 TCP 连接依然处于建立状态，任何一端都不知道另一端已经不可达。等到真正要发送数据时才发现发不出去，但客户端要收服务端消息的场景里，这个“探测”就永远不会发生。

解决方案是心跳机制。WebSocket 协议定义了Ping和Pong两种控制帧，一端发 Ping，另一端必须回 Pong。浏览器端的 WebSocket API 没有直接暴露发送Ping的方法，但服务端可以主动向客户端发 Ping，浏览器会自动回 Pong——你不需要写任何代码，底层的浏览器实现会响应它。所以心跳的设计思路是：

1. 服务端定时（比如每隔 30 秒）向所有客户端发送 Ping 帧。
2. 如果客户端在指定时间（比如 3 个周期内）没有收到任何数据，就主动触发close并走重连流程。
3. 客户端侧的模拟心跳可以在应用层实现：前端每隔 30 秒发送一个{type: 'heartbeat'}消息，服务端收到后正确处理并回应，如果连续 N 个心跳没有回应，前端主动断开重连。

这里有一个很重要的细节：WebSocket 的 Ping/Pong 是协议层的控制帧，不会走业务消息回调，所以你在onmessage里是不会收到 Ping 的。很多前端同学手写心跳时会用setInterval发一个业务层的心跳消息（比如ping），这当然可以，但要小心和服务端的协议字段冲突。如果你对接的后端框架自带 Ping/Pong 机制（比如 Spring Boot 的 WebSocketHandler 会自动处理 Ping），你再发应用层心跳就重复了，反而增加无谓流量。

3.4 鉴权与广播：加密连接之外的两个常见难点

关于 WebSocket 鉴权，有两种主流方案。方案一是连接鉴权：在 WebSocket 握手 URL 上带?token=xxx，后端在handshake阶段校验，校验不过就拒绝升级返回 403。方案二是首消息鉴权：连接建立后先不发业务数据，客户端和服务端约定第一条消息必须是{type: 'auth', token: '...'}，鉴权通过前服务端不发任何数据，通过后开始正常通信。

方案一的优点是实现简单，适合快速上线。缺点很多：token 会留在服务器访问日志里，有泄露风险；URL 长度有限制，不适合批量传参；而且浏览器的 WebSocket API 没法自定义握手请求头，所以你只能用 query string 或 path 传递。方案二相对安全，但要处理好“鉴权期间收到的消息怎么办”这种边界问题。

广播需求也很常见。搜索词里有一条很典型：spring boot 好用的 websocket 后端框架 可以广播、群组、设置属性等。这个问题在 Spring Boot 生态里最直接的答案是 Spring 自带的SimpMessagingTemplate，可以通过 STOMP 协议做点对点、广播和群组消息。当然，如果你用的是纯 WebSocketHandler，需要自己维护一个Session集合，实现广播、根据用户 ID 定向推送、分组推送。我自己维护过一个在线通知系统，用的就是ConcurrentHashMap<String, WebSocketSession>按用户 ID 分组，再配合一个CopyOnWriteArraySet存所有在线会话，广播时遍历所有会话，定向推送时从 Map 里精确找到会话。需要注意并发安全问题：WebSocket 的sendMessage方法并不是线程安全的，同一个WebSocketSession如果被多个线程同时调用sendMessage，偶尔会出现The remote endpoint was in state [TEXT_PARTIAL_WRITING]之类的异常。解决方法是给每个会话加一个写锁，或者用ConcurrentWebSocketSessionDecorator包装一层。

3.5 VueUse 的 useWebSocket 到底封装了什么

现在项目里越来越多地使用 VueUse 这个组合式工具库，其中useWebSocket封装的恰恰是上面这些反反复复要处理的问题：自动重连、心跳、消息解析、状态变化。我看很多新手直接拿来就用，遇到问题无从下手，其实是不知道它内部做了什么。

useWebSocket的核心参数有url、protocols、options三项。options里支持onConnected、onDisconnected、onError回调，还支持autoReconnect（自动重连，可以配置重连次数和间隔）。心跳方面，你可以传heartbeat: { message: 'ping', interval: 30000, pongTimeout: 5000 }，它会定时发送message，如果在pongTimeout内没有收到响应就判定失联并触发重连。它内部还把不同事件类型归类，能在消息中识别type: 'ping'和type: 'pong'这些协议定义。理解这些封装背后的设计，你才不会在它失效的时候一脸懵。

4. 选型决策：轮询、长轮询、SSE 与 WebSocket 到底选哪个

很多初学者最容易犯的错误是：聊到实时通信就用 WebSocket，聊到数据刷新就用setInterval轮询。其实这四种方案各有明确的使用半径，选错方案的后果通常不是立刻爆掉，而是到了一定用户量或者特定网络环境才暴露问题，那时候再改架构代价就大了。

4.1 四种方案的取舍对照

我用一张表把这四种方案从连接模型、数据流向、实现复杂度、重连机制、适用场景几个维度拉平对比：

从这张表能得出几个实战结论。第一，低频率的数据刷新（比如每分钟刷新一次股票行情）用短轮询完全足够，不要过度设计。第二，单向高频推送首选 SSE，实现成本低很多，而且天然走 HTTP 协议，中间设备兼容性最好。第三，真正的双向低延迟交互才需要 WebSocket，比如在线聊天、多人实时编辑、协同白板。

4.2 用业务场景反推技术选型

我习惯在技术方案评审的时候用一个简单的问题来引导决策：服务端真的需要主动向客户端发消息吗？客户端需要实时向服务端发消息吗？

按这个思路拆几个真实场景：

• 扫码登录：手机扫码后，网页端需要等服务端通知“登录成功”。数据流是服务端到网页的单向推送，选 SSE 最合适。扫码登录页面只需要收一次消息，之后就能关掉连接。
• 在线客服：访客和客服都要发消息、收消息，这是真正的双向通信，必须用 WebSocket。中间还有一个“客服正在输入”的状态同步，也是实时双向的。
• AI 流式问答：用户提问后，服务端需要持续推送生成内容，中途客户端不需要打断（哪怕你实现了“停止生成”，这也是单独的一个普通 HTTP 请求就能做到的）。这种场景用 SSE 最省事。
• 多人白板协作：每个用户的落笔都要同步到所有人，双向性很强，延迟要求极高，只有 WebSocket 能胜任。STOMP 协议下的 subscription 还能很方便地实现按房间隔离。
• 后台任务进度：比如批量导入文件，前端发起导入请求后展示进度条，进度数据由服务端推送，选 SSE。如果中途还需要“暂停/取消”控制，可以考虑 WebSocket 或者在导入请求里加取消链接。

说白了，做技术选型时，先看数据流向，再看对延迟的容忍度，最后看实现和维护成本。一味地上 WebSocket 不仅后端要处理连接状态、心跳、集群广播，前端还要处理断线重连、消息补发，复杂度远超小型项目应有的负担。

5. 我踩过的实时连接坑：从 1006 到 App 连不上

最后分享几个我在实战中踩过的真实坑，这些坑从热搜词里能看出是大量开发者的普遍困惑。每个我都会给出完整的排查链路，你以后遇到同类问题可以直接照着走。

5.1 H5 能连、打包成 App 连不上

“websocket运行到h5可以连接，打包为app连接不了”，这个词条我太熟了。Web 端一切正常，一打包成 App，WebSocket 死活连不上。这类问题的排查核心是：App 里的网页运行环境和浏览器不一样。

第一个要检查的是证书问题。你的 WebSocket 连接如果是wss://协议，App 内嵌 WebView 的证书校验策略可能比桌面浏览器严格。如果用的是自签名证书或者某个中间证书链不完整，浏览器可能“忽略”了问题，但 App 的 WebView 直接拒绝了握手。排查方法是打开 Android WebView 的远程调试（chrome://inspect），或 iOS 里用 Safari 开发者模式连接模拟器，在 Console 面板里看报错。

第二个是Android 明文流量限制。Android 9 之后默认禁止明文 HTTP 流量。如果你的 WebSocket 地址是ws://（非wss://），在 Android WebView 里默认会被拦截。需要在AndroidManifest.xml里配置android:usesCleartextTraffic="true"，或者通过网络安全配置文件（Network Security Config）只对特定域名放开明文流量。

第三个是网络权限。有些 App 壳会限制 WebView 的联网权限，或者设置了白名单只允许特定域名的请求。这种情况下，H5 页面能加载但 WebSocket 连接被拦，界面上看不出区别。

第四个没那么常见但很坑：代理设置。公司网络环境经常要求浏览器走系统代理，而 App 内嵌 WebView 默认继承系统代理设置，如果代理不支持 WebSocket 的升级请求，连接就会失败。这个坑在本地开发环境特别难查，因为你自己电脑上的浏览器可能也走了代理但浏览器对 WebSocket 的代理处理更宽容。

5.2 “before completion: idle timeout waiting for sse”：网关的超时问题

这个报错的完整链路我在第二节提到过，这里展开讲排查过程。当时我们在做 AI 流式问答，前端用的是 fetch 方案连接 SSE 接口，服务端是 Java Spring Boot。上线后用户反馈：每次提问后如果 AI 思考超过 30 秒，前端就报这个错，页面完全没有输出。

第一次排查，我以为是前端的问题，因为在本地用 Node.js 模拟服务端时一切正常。后来在测试环境复现时，我盯着 Network 面板发现请求的状态码在 30 秒整的时候变成了失败，这个“整 30 秒”的规律立刻让我怀疑是代理层超时。查了部署架构，发现前端请求要经过云厂商的负载均衡和 Nginx 两层。云厂商 LB 默认空闲超时是 60 秒，Nginx 默认proxy_read_timeout是 60 秒。理论上都不该在 30 秒断，但问题是模拟环境里没人设置过这些参数，默认值为什么是 30 秒？后来才发现请求还额外经过了一层 API 网关（Spring Cloud Gateway），它的默认空闲连接超时是 30 秒。

排查链路是这样的：先定位是哪一层断开，方法是分阶段压测——绕过所有网关直接打服务端接口，用 curl-N看流式响应是否能超过 30 秒；然后再逐层加上网关复测。最后修改了网关的max-idle-time和 Nginx 的proxy_read_timeout为 300 秒，问题解决。

这个坑的通用教训是：SSE 长连接跨过的每一级代理，都要重新检查一次超时配置。不只是 Nginx，云负载均衡有 idle timeout 参数，API 网关有 max-idle-time，有的 CDN 也会断开长时间无数据的长连接，甚至连接本身太久没数据本身就可能是问题。SSE 的retry字段和Last-Event-ID能帮你实现业务层的断点恢复，但这只是补救，最好的做法是从根上让每一级都知道“这个连接可以长时间空闲”。

5.3 SignalR 前端到底该怎么获取数据

signalr前端应该怎么获取数据这个词条表明 .NET 技术栈的团队也不少。SignalR 的抽象层次比原生 WebSocket 高很多，它封装了连接管理、重连、消息协议（默认 JSON，也可以 MessagePack）。很多人第一次接触 SignalR 会困惑：对接 WebSocket 时候我们用onmessage接收数据，SignalR 里去哪接收？

SignalR 前端的主要 API 是HubConnection。连接建立后，你用connection.on('MethodName', callback)注册服务端 Hub 方法的回调，用connection.invoke('MethodName', args)调用服务端方法，用connection.send('MethodName', args)发送消息但不等待响应。它的重连策略是自动的，也可以手动控制：connection.onreconnected、connection.onclose这些事件里做业务补偿。

如果对接 Spring Boot 的 WebSocket 后端，前端用的是原生 WebSocket，但 Spring 也支持 STOMP 子协议。用 STOMP 时，前端需要先CONNECT帧、订阅目的地（destination），服务端通过SimpMessagingTemplate.convertAndSendToUser等推送时，前端在订阅的回调里拿数据。这种情况下很多人会觉得比原生 WebSocket 绕，但它换来的是一套现成的路由、鉴权、群组概念。类似地，如果你接的是网易云信、腾讯 IM 这类云服务，它们也会在 WebSocket 之上做一层协议封装，前端的重点是理解“事件名—回调函数”这个映射关系，而不是执着于底层帧结构。

5.4 “跨域访问被拒绝，请检查浏览器配置”的真相

最后说一个前端新手特别容易懵的报错。有些老业务系统在遇到跨域错误时，给用户展示的是“跨域访问被拒绝，请检查浏览器配置!”这种提示。这个文案其实来自某些框架的封装，真正的意思是：浏览器的同源策略拦截了一个跨域请求。它和浏览器配置没有半毛钱关系。

遇到这种提示，正确的排查顺序是：

1. 打开 DevTools 的 Console 面板，找到那行Access to fetch at 'https://...' from origin 'http://...' has been blocked by CORS policy的报错，看完整信息。
2. Network 面板里找到对应的请求，看是否出现了预检请求（OPTIONS）。如果 OPTIONS 请求返回了非 2xx，问题大概率在服务端或代理层。
3. 检查请求头里是否带了Authorization或者请求方法是否为PUT、DELETE等，如果是，确认服务端响应头里有没有对应的Access-Control-Allow-Headers和Access-Control-Allow-Methods。
4. 如果请求带了 Cookie（withCredentials: true），确认服务端没有使用Access-Control-Allow-Origin: *，且返回了Access-Control-Allow-Credentials: true。

大部分“请检查浏览器配置”最终都指向后端或者 Nginx 配置，看到这种提示先别怀疑用户浏览器，先从自己代码和配置上查起。

写到这里，关于 WebSocket 的断线重连和心跳，我还有一个自己的土办法想分享一下。在团队项目里我习惯约定一个“连接状态试图”：断开自动重连，重连成功后先做一次轻量数据同步（拉取最近一条消息的 ID 或时间戳），再继续后续推送。这个设计虽然多写几十行代码，但它能把“断网期间的消息遗漏”这种最讨厌的问题，从“追踪无头悬案”变成“同步一个偏移量就行”。如果你也在做实时通信相关的前端工作，建议在心底里把“连接可靠性”当作一等公民，而不是侥幸地认为网络永远不会断。