std::regex不支持编译期pattern验证，非法模式仅运行时报错；ctre通过模板参数ctre::re()在编译期解析字面量并报错，需严格使用字符串字面量，不可用变量或指针。
std::regex 的 pattern 无法在编译期验证
标准库 std::regex 的构造函数不是 constexpr，传入非法 pattern（比如 "[a-z["）只会导致运行时抛出 std::regex_error，根本进不了编译期检查。哪怕你把它包进 static_assert，编译器也会直接报错“call to non-constexpr function”。这不是写法问题，是标准本身没允许。
用 CTRE 库做编译期语法校验
CTRE（ctre::re()）会在模板实例化阶段解析 pattern 字符串字面量，非法语法（如未闭合的 [、错误的量词位置）会触发 SFINAE 失败或静态断言，直接编译报错。这是目前最可靠、最轻量的方案。
- 必须用字符串字面量，不能是
const char*或std::string；变量名也不行，哪怕是constexpr const char str[] = "...";都不被接受 - 错误示例：
ctre::re()→ 编译失败，提示类似invalid character class - 正确示例：
static_assert(ctre::re().match("123-45-6789"));，pattern 合法且匹配成功才过
不用第三方库时的手动 fallback
如果你不能引入 CTRE，又确实需要编译期校验，只能退回到“有限子集 + constexpr 函数”手工实现。例如只支持 ^、$、[a-z]、+、*、? 这几个元字符，自己写一个 constexpr bool is_valid_basic_regex(const char* p)。
- 它只能检查极简语法（比如括号配对、
[]内无非法嵌套），没法覆盖 PCRE 或 POSIX 全部规则 - C++17 起可用
constexpr字符串遍历，但递归深度受编译器限制（Clang 默认 512 层，GCC 更低） - 别试图复刻完整正则语法分析器——那已经等价于重写一个 CTRE，且大概率在 MSVC 上因 constexpr 限制崩掉
POSIX 兼容性不是编译期能解决的问题
有人想验证 “这段 pattern 能否被 regcomp(..., REG_EXTENDED) 接受”，这和编译期合法性是两回事。POSIX 正则引擎的行为（比如 BRE 中 ? 是字面量）依赖 C 库实现，而 CTRE 或手写 constexpr 校验器只认自己的语法定义。真要验证 POSIX 兼容性，唯一办法是运行期调用 regcomp 并检查返回值——它不属于编译期范畴。
真正容易被忽略的是：CTRE 的 re 模板参数必须是纯字符串字面量，连带空格、换行、BOM 都算非法字符；哪怕多一个不可见的 U+FEFF，也会让整个特化失败，错误信息还可能藏在模板展开深处，得开 -ftemplate-backtrace-limit=0 才看得清。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
