自托管剪贴板同步工具 autoclip 部署实战：从 Docker 配置到客户端接入

我见过不少人折腾过各种剪贴板工具最后都卡在“能用”和“好用”之间。手机上看到一串验证码要发到电脑电脑上复制了一段服务器日志想贴进手机里的聊天窗口结果不是截图就是翻聊天记录来回折腾好几分钟。直到我在自己的服务器上完成 autoclip 部署把这套自托管的剪贴板同步服务用起来之后才觉得这事值得认真写一写。autoclip 不是一个花哨的项目解决的就是一个非常朴素的痛点多设备之间的剪贴板内容怎么顺畅流动。它把“复制”这个动作变成一个可以由你自己掌控的服务支持文字、链接、图片、短代码片段多个设备之间实时同步。比起用聊天软件给自己发消息、用网盘来回传临时文件这种方案要干净得多也更符合长期使用的习惯。更重要的是它是自托管的数据不经过第三方服务器剪贴板里那些密码、验证码、链接、未写完的段落都有机会只存在你自己的设备上。这篇文章写给谁如果你手头有一台吃灰的 NAS、树莓派或者一台低配云主机想搭一个属于全家人的同步基础设施如果你受够了各大平台剪贴板工具的各种限制如果你是那种喜欢“一切数据自己管”的人这篇部署记录应该能直接照抄作业。我在下面会把部署思路、配置步骤、客户端接入、常见问题排查全部拆开讲尽量把每一步为什么这么做也说明白。1. autoclip 是什么为什么值得自托管一个剪贴板1.1 到底在解决什么痛点先复盘一下没有 autoclip 时多设备传文字是什么体验。最典型的是验证码手机上收到短信验证码是六位数字你要在电脑网页里输入靠肉眼来回切换六位数字还可能输错。稍微好一点的办法是用聊天软件的“文件传输助手”发给自己但为了一个验证码去打开聊天窗口要经过解锁、找到会话、发送、切回电脑、点开五个步骤。更麻烦的是临时 URL手机上看到一个链接想在电脑上打开手动输了半天结果漏了一个字符网页直接 404。这些场景的本质问题是一样的剪贴板是跟着设备走的电脑的剪贴板和手机的剪贴板彼此不认识。操作系统根本没有提供跨设备剪贴板的能力所以就需要一个中间人来搬运。这个中间人可以是 IM 软件、网盘、笔记软件也可以是专门的剪贴板同步工具。前几种都只是“可用”不是“好用”因为它们的核心场景不是剪贴板数据容易被淹没在聊天记录里也没有统一的历史管理。autoclip 这类工具把剪贴板作为第一公民来对待。它的工作方式非常直接被监控的终端捕捉到“复制”事件后把剪贴板内容上传到服务端服务端保存下来五分钟内推给其他已连接的设备其他设备再把内容写回自己的剪贴板。整个过程对用户来说是自动的你复制然后在另一台设备粘贴链条就完成了。另外一个容易忽略的痛点剪贴板的历史记录。系统默认剪贴板只能存最近一条内容更早的内容就丢了。autoclip 可以保留一段时间的剪贴板历史尴尬时刻不小心覆盖了某条内容还能从历史里捞回来。这一点实际用下来非常救命尤其对经常复制各种临时配置、API Key、路径的人来说。1.2 自托管的价值在哪里剪贴板内容是隐私浓度很高的数据。你复制过邮箱验证码、登录密码、银行卡号、私密对话、未发表的文章段落这些东西如果经过第三方服务器你无法确认它们被存了多久、被谁看过、有没有被用于训练模型。即便厂商承诺加密也没有办法让所有人放心。autoclip 走自托管路线数据写在自己家的服务器或者自己的云主机上权限完全可控。最舒服的使用场景是局域网。家里或者办公室的设备通过 Wi-Fi 连接autoclip 服务跑在 NAS 上所有数据在内网流动根本不出门。我实际使用下来局域网内同步延迟基本在一秒以内复制完切到另一台设备粘贴动作已经就绪。这种体验甚至比很多商业剪贴板工具在公网上的表现还好。如果两条设备不在同一个局域网也可以把服务暴露到公网但要做 HTTPS 和访问控制这个后面会专门讲。自托管还有一个隐藏的长期价值服务不会被下架数据格式不会被厂商绑架。商业剪贴板工具可能会调整免费额度、改变协议、甚至整个产品线砍掉自托管只要你自己还愿意维护服务就一直在。部署一次之后基本不用管性价比很高。1.3 autoclip 的核心能力清单根据我实际部署和使用的体验一个完整的 autoclip 服务应该具备这几块能力这也是我判断一个剪贴板同步项目是否成熟的标准多端同步官方或者社区客户端覆盖 Windows、macOS、Linux、Android、iOS外加一个 Web 端至少保证你在任何设备上都能访问。内容类型支持纯文本是底线图片、富文本、文件片段以 Base64 形式传输属于加分项日常传截图、传小文件会很方便。历史检索能按时间、关键字搜索历史剪贴板记录不只是保留一个最新条目。一次性读取某些链接、密码类内容支持“只允许读取一次”读完即焚适合临时交付验证码这种场景。有效期控制每条剪贴板内容可以设置 TTL过期自动销毁避免服务端磁盘无限膨胀。忽略规则可以设置某些程序尤其是密码管理器的复制事件不被记录这类工具复制出来的内容往往是最敏感的。自托管友好提供 Docker 镜像、docker-compose 编排、环境变量配置数据目录清晰方便备份迁移。以上这些不全是 autoclip 的默认特性有些需要配合客户端和配置项来实现但至少在我部署的版本里以上能力都能找到落点。接下来我按自己实际部署时的顺序从零开始把每一步讲清楚。2. 部署前的准备与思路2.1 硬件选型不必一开始就追求高配autoclip 本身是轻量服务对硬件的要求低得惊人。纯文本剪贴板的存储量很小即使部署在树莓派上CPU 占用也常年是个位数。我用过的三种典型设备如下树莓派 4B2GB 或 4GB 内存适合纯局域网部署功耗低扔在弱电箱旁边不碍事。需要注意存储卡质量如果用的是普通 TF 卡建议把 autoclip 的数据目录放在外接硬盘上避免频繁写入导致卡损坏。NAS群晖、威联通、绿联等如果你家里已经有 NAS这是最优选择因为 NAS 自带存储冗余、自动备份和持续运行环境。群晖上装 Docker 套件新建一个 docker-compose 项目就行数据目录放在 NAS 的共享文件夹里以后备份非常方便。云主机1 核 1G 起步如果你没有内网设备或者希望异地设备也能接入可以用一台低配云主机。内存 1GB 跑 autoclip 和 Nginx 反代完全够用流量费用也微乎其微因为同步的就是剪贴板文本和小图片不是视频流。我的建议是先在局域网里跑通再考虑公网访问。不要一上来就把服务暴露到公网剪贴板数据一旦被未授权访问风险是被动的处理起来会很麻烦。先内网跑一个星期确认自己真的需要异地同步再做公网暴露。2.2 Docker 还是裸机部署autoclip 最常见的分发方式是 Docker 镜像我强烈建议优先用 Docker 部署。原因很实际第一依赖隔离不需要在宿主机上装 Node.js 或 Python 环境镜像内部已经打包好了第二升级方便拉取新镜像、重建容器几秒钟完成旧版本像垃圾一样清理掉就行第三出问题时回滚也容易可以指定旧 tag 重新跑起来。裸机部署不是不可以适合那些已经装了完整的应用运行时、并且有洁癖不想碰 Docker 的人。裸机的麻烦在于升级要自己去处理依赖版本变化还有 systemd 服务、日志轮转这些都得自己写。一套服务要长期跑稳定性比“不吃 Docker”这种执念重要得多所以我建议新手直接走 Docker 路线。Docker 安装这里不展开只说版本要求。Docker Engine 20.10 以上Docker Compose v2 以上基本上现在的系统仓库里默认版本都满足。如果你的服务器上 Docker 版本比较老而且不方便升级也可以用docker run单容器方式代替 compose但配置项会零散一些出问题时排查起来不如 compose 文件直观。2.3 需要提前准备的依赖项部署之前建议把下面几样东西准备好可以节省安装过程中的等待时间一个稳定的 IP 地址局域网部署就是设备的局域网 IP云主机就是公网 IP。建议在路由器上给设备做 DHCP 静态绑定避免 IP 变化导致客户端连不上。Docker 与 Docker Compose 插件安装完成后可以用docker compose version验证输出有版本号就说明可用。openssl 命令用来生成 token secret几乎所有 Linux 发行版自带。Windows 上也建议用 Git Bash 里的 openssl或者直接用在线随机字符串生成器但本地生成更安全。一个文本编辑器改配置用推荐 vim 或者 VS Code 的远程编辑功能别用 Windows 记事本因为它会把 LF 换成 CRLF容易把 YAML 搞坏。时间同步宿主机要开启 NTP 时间同步很多同步协议和 Token 校验依赖时间戳时间偏差太大可能导致客户端连接被拒绝。域名和 HTTPS 证书在局域网阶段可以不要但如果你打算公网访问建议提前准备一个域名有域名之后可以用 Caddy 之类的反代工具一键申请自动证书比自己维护证书省心得多。3. 一步步完成 autoclip 部署3.1 获取项目与规划目录在动手之前先想清楚文件放在哪里。我会把 autoclip 作为一个独立项目放在/opt/autoclip下数据目录、配置目录、日志目录全部集中在这个文件夹里未来备份的时候直接打包这个目录就行。sudo mkdir -p /opt/autoclip sudo chown -R $USER:$USER /opt/autoclip cd /opt/autoclip git clone https://github.com/你的来源/autoclip.git .如果你所在环境不方便用 git也可以直接下载 release 压缩包解压。解压之后目录里至少会有这几个东西docker-compose.yml示例文件、.env.example环境变量模板、data/数据目录说明。我建议先复制一份环境变量模板避免直接改原始文件以后升级时不会被覆盖cp .env.example .env3.2 docker-compose.yml 配置详解写配置之前要明白一个原则剪贴板同步服务最核心的配置不是端口而是密钥和存储路径。密钥决定谁能访问存储路径决定数据能不能保住。下面是我部署时使用的参考 compose 配置基于常见实践补齐了必要参数version: 3.8 services: autoclip: image: your-registry/autoclip:2.1.0 container_name: autoclip restart: unless-stopped ports: - 8080:8080 volumes: - ./data:/app/data environment: - AUTOCLIP_PORT8080 - AUTOCLIP_DB_ENGINEsqlite - AUTOCLIP_TOKEN_SECRET${AUTOCLIP_TOKEN_SECRET} - AUTOCLIP_READ_TTL86400 - AUTOCLIP_MAX_ITEM_SIZE5MB - AUTOCLIP_CLEANUP_INTERVAL3600 - TZAsia/Shanghai逐项拆解一下image不要用latest。latest 在别人机器上可能是另一个版本升级时还会在不经意间拉入不兼容版本。固定到具体 tag比如2.1.0需要升级时手动修改 tag可控性高很多。restart: unless-stopped容器意外退出时自动拉起服务器重启后也会自动恢复。这是长期服役服务的标配不加的话重启之后服务就断了。ports宿主机 8080 端口映射到容器 8080。如果你只想让本机访问可以写成127.0.0.1:8080:8080配合反代暴露如果只是内网使用直接8080:8080最简单。volumes把宿主机./data挂载到容器/app/data数据库和上传的临时图片都放在这里。数据目录要独立挂载否则容器删除之后数据就没了。TZ设置时区日志时间戳和 TTL 计算都依赖它不设置的话可能出现时间偏差问题。AUTOCLIP_TOKEN_SECRET是服务端签名密钥用来给客户端 Token 做加密校验。这个值不要直接用这行字符串而是要生成一个至少 32 字节的随机串。我通常这样做openssl rand -hex 32把输出结果填到.env文件里比如AUTOCLIP_TOKEN_SECRET9f8d2c7a4b6e1f3d8c2a5e7b9d4f6a8c1b3d5e7f2a4c6b8d0e1f3a5c7b9d2e4f每次重新生成 secret所有已连接的客户端都需要更新 Token所以这个值一旦确定就不要频繁改。把它写在.env中、compose 文件里引用.env文件要设置权限确保只有当前用户可读。3.3 启动服务与验证配置完成后启动很简单cd /opt/autoclip docker compose up -d这里-d表示后台运行。启动后要观察日志确认没有报错docker compose logs -f autoclip正常情况下日志里会出现服务监听地址和端口比如listening on 0.0.0.0:8080。看到这行说明服务核心已经起来了。接下来做两个健康检查curl http://127.0.0.1:8080/health如果返回{status:ok}之类的 JSON说明 HTTP 层正常。然后再用浏览器访问http://服务器IP:8080应该能看到 Web 管理界面或者首次设置引导页。这里有个容易踩的坑如果你在服务器本地访问正常但局域网其他设备打不开大概率是防火墙拦截了 8080 端口。Linux 上检查一下 firewalld 或者 ufw 规则必要的时候执行sudo ufw allow 8080/tcp另外还要确认 Docker 的端口映射里没有加127.0.0.1前缀否则宿主机之外访问不到。服务启动之后第一次使用会要求你创建一个管理员 Token 或者配对码。这个 Token 就是后续客户端接入的凭证建议复制下来保存到密码管理器里不要放在聊天记录里。客户端连接时填写的不是服务密码就是这个 Token。服务端到客户端的通信是加密的Token 相当于钥匙一旦泄露别人就能读你的剪贴板历史所以对待它要像对待自己的私钥一样。3.4 用 Nginx 或 Caddy 做反向代理与 HTTPS如果你只在局域网使用直接 IP 访问就够了。但如果你希望出门在外也能从手机访问家里的 autoclip或者云主机部署时不想暴露裸的 HTTP 端口就需要一层反向代理。我推荐 Caddy因为 Caddy 可以自动申请和续期 HTTPS 证书配置极短autoclip.example.com { reverse_proxy 127.0.0.1:8080 }前提是你的域名 DNS 已经解析到服务器 IP且 80 和 443 端口对外开放。Caddy 会自动完成证书申请之后http://autoclip.example.com的访问会被自动 301 到 HTTPS。有了 HTTPS 之后客户端连接地址就填https://autoclip.example.com剪贴板内容在传输过程中就是加密的。如果你不想用反向代理也可以直接把 autoclip 的容器映射到 443 端口并挂载证书文件但这样把证书管理和服务进程耦合在一起升级容器时要额外小心证书目录挂载不够灵活。反代方案的好处是后续想加访问控制、限流、日志审计都可以在反代这一层做而不用去动 autoclip 容器本身。4. 客户端接入与日常使用4.1 安装各平台客户端服务端只是基础设施真正每天都打交道的还是客户端。autoclip 各端的客户端安装方式不同但核心配置项是统一的服务端地址、Token、设备名称。Windows下载安装包安装也可以在命令行里运行客户端自带的autoclip daemon命令做后台常驻。我建议安装完成后设为开机自启动否则关了电脑剪贴板同步就失效了。macOS可以用 Homebrew 安装安装完成后需要通过系统设置给客户端“辅助功能”权限不然客户端没法监听剪贴板变化。这一步是 macOS 安全机制导致的不是 bug遇到时别慌乱。Linux桌面端一般提供 AppImage 或 deb 包使用 Wayland 的发行版需要额外安装 wl-clipboard 相关依赖否则剪贴板监听可能无效。Android安装 App 后在设置里开启“剪贴板监听”权限关闭电池优化否则后台被系统杀掉之后同步中断。iOSiOS 系统对后台剪贴板访问限制严格一般通过“快捷指令”或者 App 内手动同步无法做到完全自动需要在移动端接受这种体验差异。Web 端浏览器打开服务端地址即可适合临时用别人电脑的场景不需要安装任何东西。第一次配置时客户端会要求你输入服务端地址和 Token。这里有个细节Token 里通常包含特殊字符手动输入容易出错。很多客户端支持二维码配对服务端 Web 界面会显示一个二维码手机客户端扫码自动填入地址和 Token非常省事。我建议能扫码就扫码能避免 80% 的输入错误。4.2 安全加固这几件事必须做客户端接好之后不要急着体验同步先把安全配置做完。我列一下我认为必须做的项目第一设置一个独立的管理密码。管理密码用于登录 Web 界面查看和删除历史记录要跟 Token 区分开。Token 是设备凭证管理密码是人工操作凭证混用的话一旦 Token 泄露攻击者不仅能同步剪贴板还能进后台翻历史风险面太大。第二配置忽略规则。把密码管理器的复制动作排除掉因为密码管理器里复制出来的口令是最敏感的。排除之后这部分内容不会出现在 autoclip 的历史里也不会被推送到其他设备。这个规则在客户端设置里配是剪贴板工具的必修课。第三限制 Web 界面的访问来源。如果走 Nginx 反代可以加上 IP 白名单或者 Basic Auth。剪贴板 Web 界面不需要被全世界访问只让自己和一个备用手机访问就够了。公网暴露的 Web 界面是最容易被人扫描到的入口哪怕你没做端口映射、只有反代暴露也要加上访问控制。第四定期清理过期内容。我习惯把内容默认有效期设为 24 小时验证码、临时链接这种东西当天就会过期。设置太长的有效期没必要剪贴板里的内容往往是即时性的留一天足够回溯留一个月就变存储垃圾了。4.3 我摸索出的几个高效用法部署完 autoclip 之后除了最基本的“电脑复制、手机粘贴”还有几个用法是我实际用得最多的验证码自动接力手机收到短信验证码复制一下电脑上直接粘贴。比手动盯半天强太多尤其是现在验证码动不动就带大小写混合。长 URL 跨设备跳转手机端看到一篇长文章复制链接电脑上粘贴打开不用再扫码跳转。URL 里有追踪参数时整体复制也能保留完整的参数不会丢 query。服务器日志分段分析我在服务器上复制一段日志输出粘到本地电脑的编辑器里配合历史记录还能对比两段日志的差异。以前靠屏幕截图清晰度不够现在直接文本级流转。当临时的“局域网剪贴板中转站”公司里两台电脑需要来回贴东西不通过聊天软件autoclip 直接作为中转避免工作内容混进私人聊天记录。一次性密码交付如果某个平台要我把验证码发给别人我用 autoclip 生成一次性读取链接对方读取之后服务端自动删除不留二次读取的机会。这些用法都不需要额外配置只要客户端在跑、服务端没挂体验就是顺势而来的。真正让我离不开它的是那种“复制完不用想另一边已经可以粘贴了”的无感它已经变得像输入法一样自然。5. 实际部署中的坑与排查实录5.1 四个典型问题与解决办法部署和日常使用中我遇到了不少问题挑几个值得记录的列成表格方便你对症排查。现象可能原因排查与解决服务启动后浏览器访问不了Docker 端口映射不对或防火墙拦截用docker compose ps看端口映射curl http://127.0.0.1:8080/health验证本地检查 ufw/firewalld 是否放行 8080 端口容器反复重启数据目录权限不对容器用户没有写入权限chown -R 1000:1000 ./data然后重启容器具体 UID 以镜像文档为准手机客户端收不到推送剪贴板监听权限被系统限制或 App 被杀后台去手机设置里给 App 打开“剪贴板读取”和“后台运行”权限Android 关闭电池优化iOS 改用快捷指令方式同步内容一直超时Token 配错、时钟偏差大、服务端地址填了局域网 IP 但设备在外网docker compose logs autoclip看是否有鉴权失败日志用date确认服务器时间公网访问时必须用 HTTPS 地址第一类问题“服务起不来”多半不是服务本身的问题而是环境和配置问题。比如端口被别的进程占了执行lsof -i :8080或者ss -ltnp查一下占用就换端口或者杀掉旧的进程。再比如docker compose up -d之后容器 Exited直接看docker compose logs autoclip日志通常会直接告诉你缺了什么环境变量、连不上数据库文件等等比瞎猜有用。第二类权限问题也很典型。很多瘦身镜像里没有chown命令挂载出来的数据目录在宿主机上是 root 所属容器内用户写不进去服务就会崩溃。解决办法不复杂在宿主机上执行chown -R 1000:1000 ./data这个 1000 是容器内非 root 用户的 UID不同镜像可能不同可以在镜像文档里查看也可以进容器里执行id命令确认。第三类移动端权限问题是移动操作系统对剪贴板的保护越来越严格导致的。Android 版本越高后台读取剪贴板的限制越多需要靠厂商的“高耗电白名单”等机制保住进程。iOS 更是只允许前台 App 读取剪贴板所以不要期待 iOS 端和桌面端完全一样的自动同步体验。如果不确定自己的 App 是否活着可以打开 App 看一眼一般打开后就能把最近的剪贴板内容拉取过来。第四类同步超时问题九成是证书或者地址层面不对。客户端连不上服务端首先要确认设备和服务器之间网络是通的ping 服务器IP。如果通用浏览器能不能打开 Web 界面能打开说明 HTTP 层没问题问题在 Token 或者鉴权。如果浏览器也打不开检查是否配了反代、证书是否过期、服务器防火墙安全组有没有放行端口。跑一遍这个自下而上的排查顺序比直接改客户端配置有效。5.2 几个我自己踩过但文档里没写全的细节有几个细节是文档里不一定写清楚但我实际操作下来觉得非常关键的Token 不要用网上的在线生成器。严格说在线生成器生成的随机字符串也可以用但你不知道它有没有被记录。既然是剪贴板同步工具涉及的敏感度本来就高建议一律用本地 openssl 生成。如果你实在没有 openssl也可以从系统/dev/urandom读取head -c 64 /dev/urandom | md5sum这个的输出也可以作为补充随机源。总之生成 secret 的动作要发生在自己的可信设备上。SQLite 数据库文件备份前要停写。如果你数据量不大直接cp数据库文件一般也没事但遇到并发写入时可能备份出损坏文件。稳妥的办法是停掉容器再备份或者在服务端配置里打开 WAL 模式后用 SQLite 的在线备份命令。我自己的习惯是写了一个简单的 cron 脚本每天凌晨用docker compose stop停一分钟打包数据目录然后docker compose start。剪贴板服务停一分钟几乎无感但对备份安全来说非常值得。历史记录不是越多越好。剪贴板是流水型数据今天复制的内容大概率明天就毫无价值。每一条都保留 30 天纯属给自己的隐私风险添负担。我设置了 24 小时默认 TTL 每周清理一次策略磁盘占用常年只有几十 MB。如果你有特殊需求比如经常需要回看三天前的某个链接可以把 TTL 调到 7 天但别超过这个量级。日志轮转一定要做。容器如果一直跑不重启日志文件会无限增长几周之后就可能吃掉几 GB 磁盘。docker 自带的 json-file 日志驱动可以设置大小上限推荐在 compose 文件里加上logging: driver: json-file options: max-size: 10m max-file: 3加上这个之后单个日志文件最大 10MB保留 3 个文件自动轮转再也不用担心日志把磁盘塞爆。这个配置不会影响功能但对长期稳定性帮助很大。5.3 如果计划长期跑还可以做这些autoclip 部署完成、日常使用正常之后如果确定要长期服役建议把下面几件事排上日程用 Watchtower 或者类似工具做镜像自动更新我的态度是不要对自动更新抱太大期望。剪贴板服务平时低调运行就好激进更新反而容易引入不兼容配置。我会每月手动拉一次新版本看变更日志之后再决定要不要升级避免“半夜自动更新把自己跨版本坑了”的尴尬。数据目录纳入备份体系。我前面提到每天停服备份的方案虽然粗暴但很可靠。如果你的 NAS 已经自带快照可以直接对/opt/autoclip/data做快照更省事。监控容器的健康状态。在 compose 文件里给服务配置健康检查这样docker compose ps能看到容器是否健康而不是只显示 Up。healthcheck: test: [CMD, curl, -f, http://localhost:8080/health] interval: 60s timeout: 5s retries: 3如果镜像本身不带 curl健康检查会失败。有些容器里没有 curl可以用wget或者把检查命令改成读取进程列表。稳妥起见先确认镜像里装了哪个工具再写对应命令。为客户端设备起清晰的名字。我见过有人设备名全是“张三的 MacBook”“iPhone 12 Pro”这种默认名同步记录里根本分不清哪条来自哪台设备。客户端设置里改成“书房台式机”“随身手机”历史记录一翻就知道来源排查问题也方便很多。最后说一点我的实际感受autoclip 这套东西安装难度并不高真正花时间的地方是理解数据流向、处理好安全边界。我自己第一次部署时也踩了权限、日志、Token 配错的坑但跑顺之后它已经成了我工作流里最安静的基础设施之一。选一台常开的设备、配好固定的 IP、写一份整洁的 docker-compose、把备份和日志轮转弄好之后几乎不用再管它日常收益却是每天都能感受到的。如果让我给新手一个建议我会说先在局域网里把流程跑通让手机和电脑顺畅同步一周再考虑是否暴露到公网不要一上来就想着全平台全场景一步到位。剪贴板这种工具用得越久越知道自己的真实需求先做减法再慢慢加功能。部署到后面你会慢慢发现真正重要的不是“多设备同步”这个炫酷的外壳而是“剪贴板里的内容始终由自己掌控”这份安心。