两者都能做服务器推送，但成本模型完全不同：长轮询是「用反复的 HTTP 请求模拟推送」，WebSocket 是「一次握手后保持一条双向连接」。长轮询的工作方式：客户端发一个请求，服务端没有数据时就把它挂住，直到有数据或超时才返回；客户端收到响应后立刻再发下一个请求。优点是协议简单、兼容性好，现有的 HTTP 网关、鉴权、限流、日志都能直接复用，服务端也可以做成无状态。缺点是每条消息都要带一轮完整的 HTTP 头（Cookie、UA 等），连接和线程占用高，消息延迟受「挂起超时加重新请求」影响，超时还会产生大量空请求；连接数一多，服务端的 fd、内存和调度压力都很明显。WebSocket 的工作方式：先发一个带 Upgrade: websocket 的 HTTP 握手，服务端返回 101 后，这条 TCP 连接就变成帧协议，双方可以随时发送数据。帧头最小只有 2 字节，天然全双工，服务端可以在任意时刻推送，不需要客户端先问一句。它的延迟更低、单连接吞吐更高，适合聊天、协同编辑、实时游戏、行情推送这类高频双向场景。代价和坑：WebSocket 是有状态的长连接，必须自己做心跳、断线重连和退避；负载均衡要支持 Upgrade，并注意空闲超时；扩容时要么粘性会话，要么用 Redis Pub/Sub 之类的机制做跨实例广播；还要校验 Origin、处理移动网络切换和代理断连。长轮询则把这些复杂度留给了「请求次数」，运维上更容易理解。选型上：更新频率低、只是偶尔通知，长轮询或 SSE 就够；只需要服务器单向推送，SSE（text/event-stream）比 WebSocket 更轻，自动重连还是浏览器内置的；需要高频双向交互，选 WebSocket。HTTP/2 的多路复用能降低长轮询的连接开销，但没有改变请求-响应语义，不能替代真正的全双工。实际系统里常见的做法是「WebSocket 为主，降级到长轮询」，在网关不支持 Upgrade 或网络不稳定时保底。

完成时间：2025年12月12日案例名称：基于华为开发者空间-Versatile Agent开发平台构建爱旅游助手心得：小白轻松搞定，但是案例中演示的两个插件已经没有了。完成案例实践截图：