我做了一个跨设备剪贴板同步工具：WebRTC + 端到端加密的完整实践关键词：跨设备同步、WebRTC、端到端加密、分块传输、React、Socket.IO、IndexedDB、工程化落地测试地址：https://sync.wpcoder.cn/摘要日常开发和办公里，我们经常在电脑、手机、平板之间来回切换：在电脑上复制了一段命令，想马上在手机里粘贴。在手机里保存了一张截图，想立刻在电脑里继续处理。在多设备协作时，文件和片段内容总在聊天软件里“绕一圈”。我基于这些真实痛点，做了一个项目：ClipSync。它的目标很简单，但实现并不简单：让剪贴板在不同设备之间实时、安全、低延迟地同步，同时保留可追溯的历史记录，并支持图片和文件这种更复杂的数据类型。这篇文章不是只讲“我做了个工具”，而是把背后的关键技术方案讲透：为什么选择 WebRTC + Socket.IO 的通信组合。如何把端到端加密做进实时传输链路。大文件分块传输为什么总在 90% 卡住，怎么从协议层修好。前端与后端模块如何拆分，才能在功能增加时不失控。如何从“Demo 可跑”走到“真实环境可用”。如果你也在做跨端工具、P2P 实时通信、或对工程化加密传输有兴趣，这篇可以直接当一份实战参考。1. 项目背景：复制粘贴看似简单，跨设备却并不简单在单设备里，剪贴板是操作系统能力；但一旦跨设备，它就变成了一个完整的分布式问题：设备发现和配对：两台设备怎么快速建立会话？通信可靠性：网络抖动、NAT、移动端后台冻结，怎么保证体验不断裂？数据安全性：复制内容可能是账号、密钥、内部文档，服务器不该看到明文。多类型数据：文本容易，图片和文件才是“重头戏”。历史与回溯：用户需要可搜索、可筛选、可删除的本地历史。所以 ClipSync 的设计思路不是做一个“云端中转剪贴板”，而是：传输层尽量走 P2P，减少中间节点依赖。数据层默认端到端加密，服务端只做信令与会话管理。存储层本地优先，历史数据落 IndexedDB，减少隐私暴露。工程层面考虑断线重连、降级策略、远程链路和移动端特性。一句话概括：这是一个偏“生产可用”思路的跨设备同步项目，而不是只演示 API 的教学 Demo。2. 项目能力总览：不只同步文本，而是完整跨端协作链路2.1 核心功能ClipSync 目前覆盖了跨设备同步的主场景：实时同步：支持文本、链接、图片、文件在设备间实时收发。会话配对：使用 6 位数字连接码快速加入，无需复杂配置。历史管理：本地历史列表支持搜索、筛选、钉选、删除。多设备状态：显示在线设备、连接状态、角色信息。国际化：内置中英文切换，自动检测浏览器语言。2.2 体验层能力除了“能传”，项目也关注“可感知”和“可恢复”：传输进度可视化：大文件显示排队、进行中、完成与失败状态。连接模式提示：局域网直连与远程中继模式清晰可见。自动恢复策略：断线后主动清理失效 Peer 状态