WebSocket传输XML需手动序列化为UTF-8字符串或ArrayBuffer发送，不支持直接传XMLDocument；HTTP上传则通过Content-Type区分application/xml或multipart/form-data，天然支持进度、状态码与代理处理。
WebSocket 传输 XML 文件：用 send() 发送字符串或二进制，但得自己处理编码
WebSocket 本身不关心内容类型，它只负责双向、全双工的字节流通道。XML 是文本，所以最常用方式是把 XML 字符串转成 UTF-8 字节后用 send() 发送——但注意：send() 接收的是 String、ArrayBuffer、Blob 或 TypedArray，不能直接传 DOM XMLDocument 对象。
常见错误是直接 ws.send(xmlDoc)，结果发出去的是 [object XMLDocument] 字符串；正确做法是先序列化：
const serializer = new XMLSerializer(); const xmlStr = serializer.serializeToString(xmlDoc); ws.send(xmlStr);
如果 XML 很大（比如 >1MB），建议改用 ArrayBuffer + TextEncoder 避免中间字符串拷贝：
const encoder = new TextEncoder(); const bytes = encoder.encode(xmlStr); ws.send(bytes.buffer);
- 服务端必须按相同编码（通常是
UTF-8）解码，否则中文变乱码 - WebSocket 没有内置的“文件名”“MIME type”字段，XML 的
<?xml version="1.0" encoding="GBK"?>声明仅对解析器有意义，不影响传输 - 若需校验完整性，得自己加
Content-MD5或用 WebSocket 子协议协商校验方式
HTTP 上传 XML：走 multipart/form-data 或 application/xml，带标准元数据
HTTP 上传本质是单向请求响应模型，XML 通常作为请求体发送，靠 Content-Type 头声明格式。两种主流方式：
-
Content-Type: application/xml：整个 body 就是 XML 文本，适合纯数据提交（如 SOAP 请求） -
Content-Type: multipart/form-data：XML 包在表单字段里，可同时传文件、文本、XML，适合 Web 表单场景
例如用 fetch 上传 XML 字符串：
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
fetch('/api/upload', {
method: 'POST',
headers: { 'Content-Type': 'application/xml' },
body: xmlStr
});
而上传 XML 文件（如用户选中的 config.xml）更常见：
const fileInput = document.querySelector('input[type="file"]');
const file = fileInput.files[0];
const formData = new FormData();
formData.append('xml_file', file); // 自动设为 multipart
fetch('/api/upload', { method: 'POST', body: formData });
- HTTP 上传天然支持进度事件（
upload.onprogress），WebSocket 需手动分块 + 序号 + ACK 模拟 - HTTP 有状态码（
400 Bad Request、413 Payload Too Large）和标准错误反馈，WebSocket 错误只能靠自定义消息结构传递 - 浏览器对 HTTP 上传有内置重试、断点续传（通过
Range）、代理/缓存策略；WebSocket 全要自己实现
协议层根本区别：连接模型、状态、头信息不可互换
WebSocket 和 HTTP 是不同层级的协议。HTTP 是无状态请求-响应协议，每次上传都是独立事务；WebSocket 是有状态长连接，建立后双方随时可发数据，没有“请求头”概念。
- WebSocket 握手用 HTTP Upgrade，但一旦成功，后续帧就脱离 HTTP 语义——
Content-Type、Authorization等头全部失效 - HTTP 上传能被 CDN、WAF、反向代理（如 Nginx）原生识别和拦截；WebSocket 流量除非显式配置（如 Nginx 的
proxy_http_version 1.1+Upgrade头透传），否则容易被中断 - 移动端网络切换（Wi-Fi → 4G）时，HTTP 上传失败会报错，可捕获重试；WebSocket 连接会静默断开，需靠心跳 + 重连逻辑恢复，期间 XML 可能丢失
选哪个？看是否需要实时双向交互，而不是“传得快不快”
如果只是把一个 XML 文件从浏览器发到服务器，保存完就结束，HTTP 上传更简单、兼容性更好、调试更直观（Chrome Network 面板直接看请求体）。WebSocket 在这种场景下纯属杀鸡用牛刀。
只有当出现以下情况才值得上 WebSocket：
- XML 是持续生成的流式数据（如实时设备配置变更推送）
- 服务器要基于该 XML 主动下发关联数据（如返回校验结果、触发下游通知），且要求低延迟
- 客户端需在上传中途取消、暂停，或服务端要实时反馈解析进度（非 HTTP 上传能自然支持的）
真正容易被忽略的是错误边界：HTTP 上传失败，你能明确知道是网络问题、401 还是 413；WebSocket 里发一个 XML 后没回音，可能是连接断了、服务端崩溃、消息被丢弃、甚至 XML 格式错导致解析器静默退出——排查链路远比 HTTP 长。
