Sublime中正则替换枚举需分两步：先用^\s*(public\s+|final\s+|sealed\s+|)(enum)\s+(\w+)\s*(?:<[^>]*>)?\s*{安全匹配枚举头，再用^\s*(\w+)\s*(?:\((.*?)\))?\s*(?:,|$)提取常量，避免跨行、注释、泛型干扰。
Sublime 中正则替换枚举定义的常见失败现象
直接用 find in files 搜 enum { 或 public enum 往往匹配不全——因为换行、注释、修饰符（final、sealed）、泛型（enum Status<t></t>）会让简单模式失效。更麻烦的是，替换后新格式若没对齐缩进或漏掉分号，编译直接报错。
安全匹配 Java/C# 枚举头的正则写法
关键不是“找 enum”，而是“找以 enum 开头、到左花括号结束的完整声明行”。推荐用这个模式：
^\s*(public\s+|final\s+|sealed\s+|)(enum)\s+(\w+)\s*(?:<[^>]*>)?\s*\{说明：
• ^ 和 \s* 保证匹配行首或缩进后的声明
• (?:<[^>]*>)? 非捕获组匹配可选泛型，避免跨行误伤
• 不捕获修饰符，只捕获 enum、枚举名 \w+，方便后续引用
替换为（以转成 Kotlin sealed class 为例）：
sealed class $3 {注意：$3 是第三个捕获组，即枚举名；别用 $1 引用修饰符——Java 的 public enum 到 Kotlin 不需要 public sealed，硬搬会出错。
批量处理枚举常量时的缩进与分号陷阱
枚举体内的常量（如 OK, ERROR, PENDING）常被当成普通逗号分隔列表处理，但实际要转换成构造函数调用（如 object OK : Status()），必须注意：
- 原枚举值带参数（
RED(255, 0, 0)）需提取括号内内容，不能只替逗号 - 末尾常量后没有逗号，但新语法每行都应有分号或换行分隔
- Sublime 默认不支持多行替换中的条件逻辑，所以别试图一发替换全部常量——先用正则提取所有常量行，再逐条处理
例如，匹配单个枚举常量的安全模式：
^\s*(\w+)\s*(?:\((.*?)\))?\s*(?:,|$)
它能分别捕获 OK 和空参数，或 RED 和 255, 0, 0，避免把注释里的括号（// RED(255...)）也卷进来。
为什么不用 Sublime 的“Replace All in Files”一键到底
因为枚举重构不是纯文本替换：不同语言对空枚举体（enum Empty {}）、嵌套枚举、接口实现（enum X implements Y）的处理规则完全不同。Sublime 的正则无法判断上下文语义。
实操建议：
- 先用
Find in Files配合上述正则筛选出所有枚举文件，人工确认数量和典型结构 - 对每个文件单独打开，用
Ctrl+H分两轮替换：先改头（enum Name {→sealed class Name {），再改体（常量 → object 声明） - 每次替换后立刻运行编译器校验，尤其检查 import 是否缺失、是否误替了非枚举的
enum字符串（如日志里的 “enum type=…”）
真正耗时的不是写正则，是验证每种边缘 case 是否被正确覆盖——比如 private enum 要不要提升访问权限，@Deprecated 注解要不要迁移过去。这些没法靠搜索框解决。
