sublime原生不支持双栏同步滚动对比，所谓“同步”只是视觉对齐错觉；真比对需插件行级差异计算。ctrl+k,ctrl+j仅按行号跳转，不感知内容变化，遇空行、缩进、注释等即失效；scrollsync需满足三前提：独立文件标签、同窗不同分组、手动启用；compare side-by-side按语义动态对齐，diffy默认静态快照；编码与换行符不统一将导致误报，务必先统一格式。
Sublime 原生不支持双栏同步滚动对比，所谓“同步滚动”只是视觉对齐的错觉；真要可靠比对，得靠插件介入行级差异计算，而不是靠滚动位置绑定。
为什么 Ctrl+K, Ctrl+J 不能替代真正的同步滚动
这个组合键（Ctrl+K 然后 Ctrl+J）只是把右侧视图跳转到和左侧当前行号一致的位置，它不感知内容是否匹配。一旦两个文件结构有微小差异——比如左边多一个空行、缩进从 4 空格变 2 空格、或某处加了注释——行号立刻错位，后续所有对齐都失效。
- 它不读取文本语义，只做数字映射
- 无法处理换行符差异（
\r\nvs\n） - 对未保存的临时 buffer 无效（右下角显示
untitled时按没反应）
ScrollSync 插件开启后仍不同步？检查这三个点
ScrollSync 是少数能做“联动滚动”的插件，但它生效有硬性前提，不是装完就自动工作：
- 必须是两个已独立打开的文件标签页（不能是
New View into File克隆出来的视图） - 两个视图需处于同一窗口的不同分组（
Ctrl+Alt+2切分后，再分别拖入文件） - 插件启用状态需手动打开：右键任一编辑区 →
Scroll Sync: Toggle（默认关闭）
如果已满足以上却仍无响应，大概率是文件过大（>5MB）触发了 Sublime 的 Python 插件限流机制，此时会静默降级为不监听滚动事件。
Compare Side-by-Side 和 Diffy 的同步行为本质不同
这两个主流插件都支持“并排”，但底层逻辑完全不同：
-
Compare Side-by-Side的“同步滚动”是基于行内容相似度动态对齐，会尝试跳过空行、忽略空白差异，适合看结构近似的配置或代码 -
Diffy默认不联动滚动，它生成的是静态 diff 快照（新标签页），你手动滚动左右侧互不影响；若强行开启同步（通过配置"sync_scroll": true），它只按物理行号对齐，不识别语义
也就是说：想“看着顺眼”，用 Compare Side-by-Side；想“知道哪行真变了”，别信滚动，直接看它标出的 +/- 块。
真正可靠的对比永远绕不开编码和换行符统一
哪怕用了最准的插件，只要两个文件编码或换行符不一致，高亮就会大面积误报：
- UTF-8 with BOM vs UTF-8：BOM 被当作文本开头三个字节，导致整份文件偏移
- Windows (
\r\n) vs Unix (\n)：每行结尾多一个字符，diff 引擎会认为“全文件重写” - GBK vs UTF-8：中文直接变成乱码或方块，插件按字节比对，差异块完全不可读
操作前务必右下角点击编码/换行符标识 → 选 Reopen with Encoding 和 Convert Line Endings 统一成相同格式，否则所有后续步骤都在白忙。
