改过的剪藏笔记会同步回原文吗——笔记同步助手在冲突时保留哪一版

剪藏笔记改完会不会同步回原文，取决于改动落在哪一层：是剪藏工具自身的云端同步，还是把本地文件当数据源的同步助手（配合网盘、Git、Syncthing 这类文件搬运工具）。大多数实现遇到冲突时并不是“永远以手机为准”或“永远以电脑为准”，而是按一条固定规则挑一版留下——常见的有“最后修改时间较新的覆盖较旧的”“服务端先收到的写入胜出”“本地版本优先，云端另存为冲突副本”。手机上改的内容在电脑上看不到，通常不是同步没跑，而是手机那一版在规则里被判成了“旧的”。

判断哪一版被保留，不能靠记忆，要靠一次可复现的对照：在两端分别修改同一条笔记，拉开时间差，触发一次同步，然后比对两端的最终内容、文件修改时间和内容摘要。多数同步助手以“最后修改时间较新”或“服务端先收到的写入”为一致规则，但不同实现、不同同步模式（自动同步、手动同步、只读剪藏）会有差别，需要结合自己的客户端确认。动手前先复制一份原始笔记，避免在测试过程中被二次覆盖。

在两处分别修改同一条剪藏笔记并拉开时间差

要判断保留哪一版，先人为制造一次自己知道正确答案的冲突。挑一条已经同步完成、两端都存在的剪藏笔记，记下它的文件名和原始内容。

电脑端：在正文里加一行可识别的标记，例如 PC-A，保存，并记下电脑当前的系统时间（精确到分钟）。
等几分钟（建议 3~5 分钟，跨过一次自动同步周期），在手机端改同一条笔记：加一行 Mobile-B，保存，同样记下时间。
时间差是关键。两端改动如果落在同一分钟，部分客户端只按秒级时间或服务器接收顺序判断，结果很难复现；让手机端的保存时间明显晚于电脑端，结论才可靠。

修改前后的内容快照可以直接复制正文，或导出成 md/txt，存到笔记目录之外，例如 ~/conflict-test/，避免同步助手把它当成新笔记推到云端。两种方向都要试一次：一次手机改得更晚，一次电脑改得更晚。只有对照两次结果，才能看出客户端究竟以哪一端为准。

触发一次同步并记录两端的最终内容

同步动作要明确：手动点一次“立即同步”，或者安静等自动同步周期过去。不要在两台设备之间反复切前后台，那会让时间顺序变得不可读，也容易触发额外的中间状态写入。

同步完成后，在两端分别打开同一条笔记，比较三件事：

两端内容是否一致。一致，说明冲突已经被合并或被覆盖成同一版；不一致，说明还没同步完，或者两端连的其实是不同数据源（一边是本地文件夹，一边是云端导出）。
保留的是哪一版。逐行看 PC-A 和 Mobile-B 哪个还在。
另一版是否还在。被覆盖的那端通常是直接在原文件上写回，正文里看不到另一版痕迹，但这不等于改动彻底丢失——见下一节。

如果被覆盖的是手机那一边，把同步日志（客户端设置里一般有“同步记录/活动日志”）里这条笔记对应的时间戳抄下来，和上一步记的两端保存时间对照，通常能看出客户端用的是本地时间、服务端时间还是文件 mtime 作为比较基准。这一步只做记录，不要急着改回内容。

用文件时间戳与内容哈希比对两份改动

文件修改时间（mtime）只能当参考：同步客户端写入后会常常把 mtime 改成写入时刻，而不是你在应用里编辑的时刻。所以判断“哪份更新”，要把 mtime 和内容摘要一起看，再和客户端内部记录的修改时间互相印证。

下面这段脚本在两端各跑一次，输出“文件名 + 修改时间 + 内容摘要”三列，适合放在笔记目录下执行。macOS 与 Linux 的 stat 参数不同，脚本里做了分支；如果失败，先确认目录路径和文件后缀。

# 用法：在笔记根目录执行，两端各跑一次，结果分别存成 pc.txt / phone.txt
for f in *.md; do
  mtime=$(stat -c '%y' "$f" 2>/dev/null || stat -f '%Sm' -t '%Y-%m-%d %H:%M:%S' "$f")
  hash=$(sha256sum "$f" 2>/dev/null | cut -c1-12 || shasum -a 256 "$f" | cut -c1-12)
  printf '%s\t%s\t%s\n' "$f" "$mtime" "$hash"
done | sort

如果需要递归子目录，把 for f in *.md 换成 find . -name '*.md' -print0 | while IFS= read -r -d '' f; do 并把结尾的 done 补成 done; done。也可以换成 Python 骨架，逻辑相同：用 os.stat().st_mtime 取时间、hashlib.sha256 取摘要，按时间排序后逐行打印。

输出对照方式很直接：同一文件名在两份结果里按“文件名 → 修改时间 → 摘要”对齐。摘要相同，说明两端内容已经一致，不必再判断谁新谁旧；摘要不同，且客户端内部修改时间也不同的，以客户端内部记录的时间为准——因为 mtime 很可能被同步动作改写。只看 mtime 就下结论，容易把“刚被同步写入、但内容更旧”的那份当成更新版本。

在笔记列表和历史版本里查找是否留下冲突副本

同步助手覆盖文件时，不一定真的删掉另一版。先按这几个位置找：

笔记列表里出现同名重复条目，标题后带 “(1)”、conflicted copy、冲突副本、来自某某设备 这类后缀。有的排在列表顶部，有的按创建时间插在原条目旁边。
应用内的“历史版本 / 版本记录 / 回收站”。多数笔记工具每次保存都留一份快照并按时间倒序排列，找到手机端保存的那个时刻，就能看到改动是不是只是没合进当前版本。
本地文件层：搜同一目录下的 .conflict、.bak、~$ 前缀文件或带时间戳的文件名。文件同步工具在冲突时通常保留一份副本，而不是静默覆盖。
分清对象：剪藏原文和笔记正文往往是两个东西。如果你改的是笔记正文或标注，而剪藏的网页快照被当作只读内容，那改动不会写回原文，这是产品设计，不是同步失败。

确认标准很简单：能在上述任一处找到 Mobile-B 那段文字，说明改动还在，只是没合并；三处都找不到，再按丢失处理，并从历史版本里手动复制回来。

整理一套避免丢改动的操作顺序

同步前：确认两端都已完成上一次同步（列表条目和内容一致）再开始编辑，避免一端离线改、另一端也在改。
改动较大前，先复制一份原笔记或导出 md，给自己留一个不参与同步的副本。
同一时间只在一个设备上改同一条笔记，改完等同步跑完再换设备；不得不同时改时，尽量把两次保存拉开几分钟以上。
同步后：打开笔记确认内容是不是你要的那版，再看一眼列表有没有多出冲突副本。
发现不一致时的处理顺序：先停止在两台设备上继续编辑同一条 → 用内容摘要确认两端差异 → 查历史版本或冲突副本，把要保留的内容复制到新笔记或改标题另存 → 再手动触发一次同步，让两端收敛到同一版 → 最后清理多余的冲突副本。

如果同一条笔记反复被覆盖，优先怀疑同步模式本身：自动同步间隔太长、只允许单向推送、或者剪藏原文走的是只读通道。把编辑动作集中在同一个数据源上——要么都在应用内改，要么都直接改本地文件——比在两端来回改更容易保住改动。以上判断都基于可观察的配置、日志和文件状态；换客户端或换同步后端时，需要重新做一次上面的对照测试再下结论。