起因：为什么要做这件事
复制一条几十字的文字，系统到底往剪贴板里写了几份？你大概会说一份。我原本也这么想，直到上周要挑一款剪贴板管理工具，才认真去量了一遍——答案是一份内容、三份副本。
起因很琐碎：写周报时要从四五个窗口来回抄东西，系统自带的剪贴板只留最后一条，抄错一次就得回去重找。我想装个带历史的工具，但一搜全是「装机必备」清单，数字互相打架，索性自己拿脚本和官方接口各量一遍。
过程：具体怎么做的
先说方法，省得你以为下面这些是抄来的：剪贴板部分是我用 Python 的 ctypes 直接调 Windows API 在本机跑出来的（2026-10-14）；工具的数据是我在同一天用 GitHub REST API 查的，星星数、许可证、最新版本号都是接口返回值。
第一次测量就撞了墙。写入一段带制表符的表格文本后枚举格式，剪贴板里同时躺着四条记录：CF_UNICODETEXT 74 字节、CF_LOCALE 4 字节、CF_TEXT 52 字节、CF_OEMTEXT 52 字节。同一段内容，系统按不同编码存了三份，外加一条语言标识。再加一段 HTML 进去，格式数变成 5 个，其中 HTML Format 273 字节——是纯文本那份的 3.7 倍。
顺带确认了一件事：工具监视剪贴板靠的就是序号变化。同样内容我连写两次，序号一路涨到 8470，说明它认的是「动作」不是「内容」——想靠序号去重是不成的，去重得自己比内容。
所以「工具能存多少条」这个问题本身就不成立。存的是哪一份，才是关键。
踩坑：哪里翻车了
第一个坑是我自己想当然。查监控逻辑时我以为剪贴板序号每复制一次只加 1，实测是每次写入加 5：8450 → 8455 → 8460 → 8465 → 8470，而且写入完全相同的内容，序号照样 +5。也就是说序号只能用来判断「变了没有」，不能用来数「变了几次」。
第二个坑在选型资料上。搜「Ditto 剪贴板」，前排几个下载站写着「开源 MIT 协议」「发布年份 1995」，另一家英文站写「6,100+ stars」。我拿接口一查：sabrogden/Ditto 的许可证是 GPL-3.0，星级 7,294，最新版本 3.25.113.0（2025-09-27），主语言 C，仓库 2020-11-13 迁到 GitHub，官网在 ditto-cp.sourceforge.io。三个数字，两个对不上。这种事我们不是第一次遇到，之前核开源项目的二手数字时就吃过亏，规矩还是老样子：只认官方仓库。
第三个坑是我把「能存多少条」当成了核心指标。真正常用的场景是检索——存了三千条但搜不出来，等于没存。这个思路和做周报自动化时先砍指标是一个道理：先定要什么，再定存多少。
解法：怎么爬出来的
把需求拆开之后，选项就清楚了。三个方向：系统自带、Windows 老牌工具、跨平台工具。
系统自带的历史（Win+V）需要先手动开启，够用的前提是「只找回最近几条」。网上流传的「上限 25 条」我没在微软官方文档里找到出处，所以不写进结论，只说一点：它是跟着会话走的，不是给你做长期归档的。
Windows 上想长期留历史，Ditto（GPL-3.0，7,294 星，3.25.113.0）是绕不过去的一个：本地 SQLite 存条目，官方站点与文档给出的能力包括快捷键呼出、正则/全文检索、分组与固定条目、局域网加密同步。它的短板也明确——只跑 Windows，同步要在你自己的机器之间做。
跨 Windows / macOS / Linux 就要看 CopyQ（GPL-3.0，12,457 星，最新 v17.0.0 于 2026-10-06 发布，C++）：标签页式管理、条目可编辑、能写脚本。但它的定位偏「可编程的剪贴板」，配置项多，想省事的人容易劝退。
Mac 单独看 Maccy（MIT，21,913 星，2.7.1 于 2026-08-10 发布，Swift，官网 maccy.app），极简、纯本地，但也就只在这一个平台上。
以上功能描述来自各项目官方仓库与文档口径，我这次只核了许可证、星级、版本与发布时间，没有逐个安装试交互——真要落地，照官方最新说明走。
验证：拿什么数据证明有效
回到那条最有用的实测：一次复制会留下多份副本。这直接决定了两件事。
一是体积。纯文本那条 74 字节，带格式那条 273 字节，如果你复制的是表格、代码、截图，差距会更大。工具若按全格式存历史，磁盘占用按最肥那份算；若只存纯文本，你从浏览器复制的表格贴回文档就只剩光秃秃的文字。我们那个剪贴板历史暂存板走的是轻量路线：专注把被覆盖的条目找回来，具体保留多少条、保留哪些格式以工具页说明为准。
二是监听成本。我测了序号轮询开销：读 2000 次共 1.72 毫秒，单次约 0.86 微秒。也就是说 250 毫秒轮询一次的开销可以忽略，常见的「开着工具会不会卡」在这个量级上不成立。真正的成本在写入：4KB 文本连写 500 次共 269.55 毫秒，单次 0.539 毫秒；一次写 128KB 只用 0.62 毫秒。工具本身的慢，多数来自检索和磁盘，不是来自剪贴板。
还有一个我后来改了看法的点：体积要分开算。文本条目本身就小，涨得快的是图片和整段表格；如果你一天里大半时间复制的是代码片段和链接，历史库跑半年也就几 MB，完全不必为了省磁盘把上限压到几百条。
顺便一提，Windows 自带的剪贴板历史不是所有人都会开，而且它和第三方工具会争同一块剪贴板。装之前想清楚只留一个，来回抢的体验比没有还差。这类「两个工具干同一件事」的麻烦，我在配 PDF 工具链那次也遇到过，最后留下的只有一个主力。
常见问题
存历史会不会把密码也存进去？
会。多数工具都能设排除规则或忽略指定窗口，装完第一件事就是去配，别等历史里躺了一堆验证码再清理。
多设备同步到底靠不靠谱？
Ditto 给的是局域网内加密直连，不走云；CopyQ 没有官方云服务。想跨公网同步，就得自己搭通道，别指望开个开关。
为什么我搜不到三天前复制的那段？
先确认存的是哪种格式。只存纯文本的工具，对富文本条目会退化成一段没有结构的字，关键词自然匹配不上。
公司电脑能装吗？
Ditto 与 CopyQ 都是 GPL-3.0，个人与内部使用一般没问题；要二次分发或做成对外服务，先读许可证条款，官网与仓库写得清楚。
到底该选哪个？
只在 Windows 上、要检索和留历史，Ditto；要跨平台还想脚本化，CopyQ；只用 Mac，Maccy；只想要「被覆盖了也能找回」，轻量工具就够了，不必上全家桶。
