go 标准库的 `regexp` 包不支持环视（lookaround）语法（如 `(?
Go 的 regexp 包基于 RE2 引擎，明确不支持所有形式的环视断言（包括正向/负向先行断言 (?=...) / (?!...) 和正向/负向后行断言 (?
panic: regexp: Compile(`'(.*?)(?✅ 推荐解决方案：用“非反斜杠结尾 + 单引号”逻辑替代负向后查
由于我们真正想匹配的是：以未被反斜杠转义的单引号结尾的字符串字面量，可改写为：
re := regexp.MustCompile(`'(.*?[^\\]|)'`) values := re.FindAllStringSubmatch(theRawEnumValuesString, -1)? 模式解析：
- ' ：匹配开头单引号
- (.*?) ：非贪婪捕获内容（含内部转义字符，如 \'）
- [^\\]| ：关键部分——匹配一个“非反斜杠字符”，或空字符（对应 '' 空枚举值）
- ) ：结束捕获组
- ' ：匹配结尾单引号
⚠️ 注意：该模式仍不能完美处理连续双反斜杠 \'（即 \' 被误判为转义），但在 MySQL ENUM 定义中，单引号内的转义仅允许 \' 和 \，且 Go 字符串字面量本身已对 \ 做了预处理。若原始 SQL 字符串来自 SHOW COLUMNS 或 INFORMATION_SCHEMA，其内容已是数据库返回的已解析字符串（例如 value\'s3 实际存储为 value's3），此时引号不会被双重转义——因此该正则在实际场景中足够健壮。
? 更稳妥的进阶建议（推荐用于生产）
若需 100% 正确解析 SQL 字面量（尤其涉及复杂转义），应避免纯正则方案，改用 状态机或 SQL 解析器：
- 使用 github.com/kyleconroy/sqlc/internal/sql/parser（轻量 SQL 片段解析）
- 或手动扫描：逐字符遍历，维护 inQuote 和 escaped 标志位，准确识别引号边界（代码约 20 行，零依赖、完全可控）
✅ 总结
| 方案 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| '(.*?[^\\]|)' | 快速适配简单 ENUM 字符串（无嵌套转义） | 零依赖、简洁、满足大多数自维护 DB 场景 | 不处理 \\' 等边界情况 |
| 手动词法扫描 | 生产环境、高可靠性要求 | 绝对准确、可定制错误处理 | 需额外编码（但逻辑清晰） |
| 第三方 SQL 解析器 | 复杂 SQL 提取需求 | 语义正确、扩展性强 | 引入依赖、学习成本 |
? 最佳实践：对于表结构元数据提取，优先考虑直接查询 INFORMATION_SCHEMA.COLUMNS 的 COLUMN_TYPE 字段，用标准 SQL 解析逻辑（如分割 enum('v1','v2') 中的括号内容），再对引号内字符串做一次性的、上下文感知的解引号处理，而非依赖通用正则——这既规避了引擎限制，又提升了可维护性。
