HTML无法实现信令服务，因其是静态文档，不具备监听端口、处理Socket连接、管理房间状态等后端能力；信令服务器必须依赖Node.js等运行时和WebSocket，HTML仅作为客户端存在。
纯 HTML 无法实现 WebRTC 信令服务——它必须依赖后端运行时（如 Node.js）和 WebSocket 通信能力，HTML 只能作为客户端页面存在。
为什么不能只用 HTML 写信令服务器
信令服务器本质是一个长期维持双向连接、广播/转发消息的网络服务。HTML 是静态文档格式，没有监听端口、处理 socket 连接、管理房间状态的能力。常见误解是把 index.html 当成“服务器”，其实它只是被 express.static 或 Nginx 提供的前端资源。
- 浏览器中运行的 HTML 页面只能发起连接（
new WebSocket()或io()），不能接收其他客户端的连接请求 -
localStorage、sessionStorage或IndexedDB都无法跨标签页实时同步信令，更无法让两个不同设备“看到彼此” - 所谓“无后端信令”，比如使用 Firebase Realtime DB 或 PeerJS Cloud，仍是调用外部可写入的后端服务，不是 HTML 自身提供的能力
最简可行的信令服务结构（Node.js + Socket.IO）
你需要三个最小必要部分：一个 Node.js 后端进程、一个暴露给浏览器的 WebSocket 接口、一个能加载 socket.io-client 的 HTML 页面。缺一不可。
- 后端启动命令必须是
node server.js，且server.js中调用了http.createServer()和io.listen() - HTML 中必须通过
<script src="/socket.io/socket.io.js"></script>加载客户端库（路径由 Socket.IO 自动托管，不是你手动放的文件） - 客户端连接地址应为
io('http://localhost:3000')，而非io('./')或空字符串——后者会默认连当前页面 origin，容易因跨域或协议不匹配失败
Socket.IO 房间消息转发的关键写法
WebRTC 信令的核心不是点对点直连，而是“进同一房间 → 相互可见 → 按需转发 SDP/candidate”。很多初学者卡在消息没收到，问题常出在 emit 范围写错。
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
立即学习“前端免费学习笔记（深入）”；
- 发 Offer 给对方：用
socket.to(roomId).emit('offer', sdp)，不是io.emit()（全服广播）或socket.emit()（只发给自己） - 处理 candidate 时，要确保接收方已加入房间，否则
socket.to(roomId)不生效——建议在join事件回调里用socket.join(roomId)显式加入 - 不要在前端用
socket.on('offer', ...)后立刻调用peerConnection.setRemoteDescription()，需先检查peerConnection.signalingState !== 'closed'，否则触发InvalidStateError
本地测试时最容易忽略的 CORS 和协议问题
即使代码逻辑全对，Chrome 控制台仍可能静默失败，原因往往藏在 DevTools 的 Network 或 Console 标签页里。
- Socket.IO 客户端连接报
WebSocket connection to 'ws://...' failed：检查后端cors配置是否遗漏methods，或前端 URL 写成了ws://（应交由 Socket.IO 自动协商，始终用http://或https://初始化） - 信令发出去但对方收不到：打开 Network → WS → 点开连接 → 查看 Frames，确认发送的消息 type 字段是否拼写正确（比如写成
'Offer'而非小写的'offer'），前后端必须完全一致 - 本地用
file://直接双击打开 HTML：必然失败。必须通过http://localhost:3000访问，否则浏览器禁止 WebSocket 连接
真正麻烦的从来不是写几行 socket.emit，而是确保每个连接生命周期里：房间加入时机正确、消息路由范围精准、前后端字段命名零误差、HTTP/WS 协议上下文始终一致——这些细节不靠调试器逐帧看，很容易陷入“代码没报错，但就是不通”的状态。
