^\s*$ 是最稳的匹配模式，因它匹配行首到行尾仅有空白字符（含空格、tab、\r\n\f等）的空行，覆盖纯空行、仅空格、仅tab三类，避免漏删或误删。
直接用 ^\s*$ 配合「Replace All」就能删干净，但必须关掉 . matches newline，否则会误吞整段内容。
为什么 ^\s*$ 是最稳的匹配模式
它表示“从行首到行尾之间只包含零个或多个空白字符”，覆盖三类空行：^$（纯空行）、^\t*$（只有 tab）、^ $（只有空格），而 \s 还自动包含 \r、\n、\f 等，不用手动列。
常见错误写法：
-
^$：漏掉带空格或 tab 的“伪空行” -
^\s+$：要求至少一个空白字符，跳过真正什么都没有的空行（即只有换行符的行） -
\n\n：只能删连续空行，且一次只消一个，还可能把if (a) {\n\n do();里的合法换行也干掉
替换时要不要加 \n？怎么避免末尾多出空行
推荐在查找框里写 ^\s*$\n，而不是只写 ^\s*$。因为：
- 不带
\n：只删行内容，换行符保留 → 替换后两行“焊”在一起，变成line1line2 - 带
\n：连换行符一起删，保持行结构清晰 - 但注意：文件末尾若有一行空行且不以
\n结尾（即 EOF 前无换行符），^\s*$\n匹配不到它 —— 这是 Sublime 的行为限制，不是正则写错了
所以操作完建议手动检查最后一行是否为空；如果想自动化处理尾部，可补一刀：\n\s*\Z → 替换为空，专清文件末尾残留。
批量处理多个文件时容易踩的坑
Sublime 的「Find in Files」不支持跨文件的「Replace All」，所谓“批量”其实是逐个打开再替换，这点常被误解。
- 编码问题：UTF-8 with BOM 文件中，BOM（
\ufeff）可能卡在行首，导致^\s*$失效；先转成 UTF-8 without BOM 更可靠 - 隐形字符：零宽空格（
\u200B）、LINE SEPARATOR（\u2028）等不会被\s涵盖，若发现“删不掉的空行”，可用^[ \t\r\n\u200B\u2028]*$临时兜底 - 协作规范干扰：Prettier/ESLint 可能在保存时自动加回空行（如函数间强制空一行），删完别急着提交，先
git diff --ignore-all-space看是否真有逻辑变更
删完空行，代码反而报错？重点检查这几处
这不是正则的问题，而是语义破坏：
- Python 文件里，
def或class后按规定要空两行，全删后缩进逻辑可能错乱 - Markdown 中，段落靠空行分隔，全删会导致所有段落合并成一段
- 某些配置文件（如
.editorconfig或Makefile）依赖空行做区块划分，删光后解析失败
真正难的从来不是“怎么删”，而是“哪些该删、哪些得留”——空行背后连着格式规范、协作约定和语法约束，比正则本身更值得花时间判断。
