Ctrl+Z 不能撤销批量替换，因 Sublime 将其设计为不入撤销栈的原子操作；唯一可靠补救是立即 Revert、未保存前重启，或从 Local Recovery 目录恢复快照。
Ctrl+Z 不能撤销批量替换，这是设计使然
批量替换（即通过 Ctrl+Shift+F → Replace All）产生的修改，**不会进入 Ctrl+Z 的编辑撤销栈**。不是快捷键失灵，而是 Sublime 明确将“跨文件批量替换”归类为“不可撤销的原子操作”。一旦点击 Replace All，所有变更就直接写入各文件内存缓冲区，但不记录到单文件撤销历史中。
常见误判现象：
- 点完
Replace All立刻按Ctrl+Z，毫无反应 → 正常，该操作本身不被追踪 - 只对当前文件按
Ctrl+Z，能撤回部分文字 → 那只是你在替换后手动编辑过当前文件，和批量替换无关 - 关掉某个文件再重开，
Ctrl+Z彻底失效 → 因为未保存的内存变更已释放，且无跨文件撤销上下文
真正能挽回批量替换错误的三个入口
别依赖 Ctrl+Z，Sublime 提供了更底层、更可靠的恢复路径，但需立刻行动：
-
立即执行
File → Revert：仅对当前已打开且被批量替换修改过的文件有效；它会丢弃所有未保存变更，还原为磁盘原内容（前提是没手动保存过） -
用
File → Save All前紧急中断：批量替换后所有文件标签页出现 * 星号，此时尚未落盘；只要不点Save All或单独保存任一文件，所有改动都还在内存里可逆 —— 直接关掉 Sublime（不保存），再重开，文件自动回退到替换前状态 -
从 Local Recovery 目录取快照：若已点过
Save All，则去本地恢复目录找.tmp文件：~/Library/Application Support/Sublime Text 3/Local/Recovery/（macOS）或C:\Users\用户名\AppData\Roaming\Sublime Text 3\Local\Recovery\（Windows）；这些是 Sublime 自动保存的崩溃前快照，时间戳接近替换发生时刻
为什么不能靠 Ctrl+U 或 Esc 挽救
Ctrl+U 只撤销光标添加动作（如 Ctrl+D、列选），Esc 只清空辅助光标 —— 它们和文本内容变更完全无关。批量替换不依赖多光标，也不生成光标链路，所以这两个命令对已发生的替换结果零影响。
典型误区：
- 替换后狂按
Ctrl+U→ 光标数量不变，内容也不会变 - 替换后按
Esc清光标 → 内容照旧，只是把可能残留的多光标干掉了 - 以为
Ctrl+U和Ctrl+Z是同一套机制 → 它们分属两套独立栈，互不感知
预防比挽救更重要：批量替换必须带预览和隔离
Sublime 的批量替换没有“试运行”模式，但你可以用三步强制建立安全边界：
- 在
Ctrl+Shift+F面板中，先点Find，看右侧匹配列表是否精准；尤其注意正则是否误吞 JSON 键名、注释内容、字符串字面量 - Where 框填
src,-node_modules,-dist而不是.，避免污染构建产物或依赖包 - 替换前关闭所有非必要文件标签页 —— 这样
Revert或重启时干扰更少，恢复目标更明确
最易被忽略的一点：Sublime 不会提示你“这次替换会影响 17 个文件”，它只默默高亮匹配项。一旦 Replace All 点下去，就没有二次确认环节，也没有“撤销本次替换”的专用命令 —— 所有补救都依赖你是否还握着未保存的内存快照。
