必须启用“点号匹配换行符”模式才能跨行匹配CSS类定义块，推荐使用[\s\S]而非.，并结合^.[-a-zA-Z0-9_]+(?=\s{)(?!:)等精准锚定规则，删除时替换为\n或\r\n以保持换行结构。
怎么匹配跨行的CSS类定义块
废弃的CSS类往往不是单行存在，而是以 .old-class { ... } 形式跨多行书写，中间可能夹换行、缩进、注释甚至空行。默认正则中 . 不匹配换行符，所以 \.old-class\{.*?\} 会完全失效。
必须启用 . matches newline（点号匹配换行符）模式：点击替换面板右下角的 .\n 图标，或按 Alt+R 切换。此时才能用 [\s\S] 或 (?s:.*?) 安全跨行捕获。
-
[\s\S]兼容所有 Sublime 版本，比.*更可靠，推荐用于生产环境 - 避免用
/\*.*?\*/这类写法——它在未开启. matches newline时根本跨不了行 - 若类名含特殊字符（如
.btn--primary），需转义连字符：\.btn\-\-primary，否则-在字符组中会被误读为范围符
如何精准定位“废弃类”而不误删正常样式
直接搜 \.xxx 风险极高：HTML 中的 class 属性、JS 字符串里的类名、甚至 CSS 自身的伪类（如 :hover）都可能被波及。真正要删的是「在 CSS 文件中独立声明、且不再被 HTML/JS 引用的类选择器」。
先缩小范围：只匹配以 . 开头、后接字母/数字/下划线/连字符、紧接着是空格或 { 的完整选择器行：
立即学习“前端免费学习笔记（深入）”；
- 安全起始模式：
^\.[-a-zA-Z0-9_]+(?=\s*\{)——(?=...)是正向先行断言，确保后面紧跟着{，不消耗字符 - 跳过伪类：
^\.[-a-zA-Z0-9_]+(?=\s*\{)(?!:)排除.foo:hover这类 - 排除媒体查询内嵌套：
^(?!(?:@media|@supports)).*?\.[-a-zA-Z0-9_]+(?=\s*\{)，但注意 Sublime PCRE 对多行上下文支持有限，此写法仅对顶层声明有效
删除时保留换行结构，避免样式塌陷
直接把整个匹配块替换成空字符串，会导致相邻规则粘连，比如：
.header { color: red; }
.old-legacy { display: none; }
.footer { margin-top: 20px; }
删掉中间块后变成：
.header { color: red; }.footer { margin-top: 20px; }
这会破坏 CSS 解析。正确做法是替换为单个换行符，保持行数不变：
- Replace With 填
\n（Unix/Linux/macOS）或\r\n（Windows），视文件原始换行符而定 - 更稳妥：先用
Ctrl+Shift+P→Set Syntax: CSS确认语法类型，再用View → Show Console输入view.settings().get('default_line_ending')查当前换行符 - 若不确定，可先 Replace All 成
\n，再执行一次Ctrl+Shift+P→Convert Line Endings统一格式
为什么不能靠一个正则通吃所有 CSS 文件
老旧项目里 CSS 往往混杂多种来源：手写、预处理器输出（Sass/Less）、构建工具注入（如 CSS-in-JS 的 css`...）、甚至内联 style 标签。这些场景下，. 的语义完全不同。
- HTML 文件里的
class="old-legacy"不该被删，但正则无法区分上下文 - Sass 文件中
.old-legacy {@include reset;}会被误删，因为@include不是标准 CSS - JS 文件中
el.classList.remove("old-legacy")若被当 CSS 类删掉，后续代码会报错
最易被忽略的点：Sublime 的正则不解析 AST，它只做文本扫描。所谓“批量剔除”，本质是人工划定边界后的高危操作——哪怕预览了 Find All 结果，也得逐个确认是否在 @keyframes、@font-face 或变量定义区里。别信“一键”，信 Ctrl+Z。
