html5 不支持 directsockets api。该 api 从未被 w3c 或 whatwg 标准化，主流浏览器均未实现，纯 web 环境下无法进行原生 tcp/udp 套接字通信；推荐使用 websocket、webrtc datachannel 或实验性 webtransport，或借助 electron/tauri 等混合框架突破限制。
HTML5 不支持 DirectSockets API。
截至 2026 年 4 月，DirectSockets 并非标准 HTML5 或 Web 平台规范的一部分，它从未被 W3C 或 WHATWG 纳入正式标准，也未被任何主流浏览器（Chrome、Firefox、Safari、Edge）实现或启用。你无法在当前的 HTML5 环境中通过 <script></script> 直接使用 navigator.directSockets 或类似接口进行原生 TCP/UDP 套接字通信。
H5 页面运行在沙箱化的安全模型下，浏览器明确禁止网页脚本直接访问底层网络套接字——这是出于关键的安全与隐私考量（防止恶意站点扫描内网、发起 DDoS、绕过同源策略等）。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
你实际能用的、标准化且广泛支持的方案只有：
WebSocket（
ws:///wss://）
基于 TCP 的全双工通信，需服务端配合 WebSocket 协议握手，不是裸套接字，但满足绝大多数实时交互需求（聊天、通知、协作编辑等）。WebRTC DataChannel（仅限点对点或信令中转）
支持低延迟双向数据传输，但依赖 ICE 连接建立，不适用于直连任意 IP:Port，也不适合客户端主动连接传统 TCP 服务端。WebTransport（实验性，逐步落地）
Chrome 97+ 支持（需开启 flag 或部署在 HTTPS + 有效证书环境），提供基于 QUIC 的多路复用流（fetch()类似语义），比 WebSocket 更灵活，但仍不是 DirectSockets，不暴露 raw socket 控制权，也无法绑定本地端口或使用 UDP 原始报文。
⚠️ 注意：网上部分文章提到的
navigator.directSockets是早期 Chromium 内部实验性 API 的误传或已废弃原型（2021 年前后短暂出现在某些 Canary 版本中，随后被移除）。它从未进入草案阶段，也无 Polyfill 可用。
如果你确实需要“受控环境下”的原生套接字能力，可行路径是：
- 使用 Electron / Tauri / Capacitor 等桌面/混合框架，它们允许 JS 调用 Node.js 或原生模块（如
net、dgram）； - 在 WebView 容器中嵌入自定义原生桥接层（如 Android 的
@JavascriptInterface+ Java Socket，iOS 的WKScriptMessageHandler+NWConnection）； - 采用 WebAssembly + WASI 网络扩展（极少数实验环境），但目前浏览器不开放 WASI socket 权限，仅限 CLI 工具链（如 Wasmtime）。
简言之：
想在纯 HTML5 页面里做 socket.connect('192.168.1.100', 8080)？不行。
想用标准 Web 技术实现实时双向通信？用 WebSocket 就对了。
想突破浏览器限制？必须离开纯 Web 沙箱，引入原生能力或专用运行时。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
