应使用exprtk::parser<double>::compile()判断表达式有效性，因其能准确识别语法错误并返回具体错误位置；std::regex仅适用于轻量预筛，递归下降解析器适合可控场景，而std::stod完全不适用。
用 std::regex 快速过滤明显非法格式（但不够可靠）
正则只能检查“长得像”，比如匹配 ^[\d+\-*/().\s]+$ 可以排除含字母或特殊符号的字符串，但它无法判断 "1++2"、"(1+2))" 或除零风险。实际项目中有人图快直接上正则，结果在线上遇到 "2*(3-" 这种输入就崩了——它符合正则，但根本没法求值。
建议只用正则做第一道轻量筛：
• 先剔除空格后长度为 0 的字符串
• 拒绝开头或结尾是运算符（如 "*2"、"2+"）
• 拒绝连续两个运算符（"2++3"、"2*-3" 需要额外规则支持一元负号，别一刀切）
• 允许小数点但限制格式，比如 "\d+\.\d+" 而非随意的 "\."
手写递归下降解析器识别语法结构（推荐用于可控场景）
真正判断“是否有效”，本质是看它能否被数学表达式文法接受。C++ 没有内置 eval，但写一个最小可用的递归下降解析器只要 150 行左右，比引入 Boost.Spirit 或 ANTLR 更轻量。
关键设计点：
• 把输入转成 token 流（std::vector<std::string> 或自定义 Token 类），区分数字、括号、运算符
• 实现 parse_expression() → parse_term() → parse_factor() 三级函数，对应优先级
• 遇到不匹配的 token（如 ")" 但栈顶期待 "("）立即返回 false
• 支持一元负号需在 parse_factor() 开头处理 "-" 和 "+"，且只允许出现一次
• 最后必须消耗完所有 token，否则像 "1+2)3" 这种尾部残留也算无效
调用 muParser 或 exprtk 做健壮校验（适合生产环境）
自己写的解析器容易漏边界，比如科学计数法 "1e-5"、隐式乘法 "2(3+4)"、函数调用 "sin(pi/2)"。这时候直接集成成熟库更省心。
exprtk 是 C++ 友好的选择：
• 头文件即用，无依赖，编译进项目零成本
• 构造 exprtk::expression<double> 前先用 exprtk::parser<double> 的 compile() 方法
• compile() 返回 false 就代表语法无效，错误位置和原因会写进 parser.error_count() 和 parser.error(0).type
• 注意：它默认不拒绝未定义变量，若只接受纯数字表达式，需提前注册空符号表并设 parser.enable_symbol_table(false)
示例片段：
exprtk::parser<double> parser;<br>exprtk::expression<double> expression;<br>if (!parser.compile("1+2*3", expression)) {<br> // 这里可读取 parser.error(0).to_string()<br>}
为什么不用 std::stod + 异常捕获来判断
有人试过对整个字符串调 std::stod(str, &pos) 看是否解析到末尾，但这只适用于单个数字。遇到 "1+2" 时 stod 只读到 "1" 就停，pos 指向 '+'，不代表表达式无效——它只是不是纯数字。
立即学习“C++免费学习笔记（深入）”；
更危险的是：某些输入会让 stod 溢出或陷入静默失败（如 "1e999" 在部分标准库中返回 inf 而不抛异常），误判为“合法”。所以它完全不能替代表达式语法分析。
真正难的不是识别加减乘除，而是括号配对、运算符结合性、前导/尾随空白容忍、以及用户真实会输的怪异格式（比如多空格、制表符、全角符号）。这些细节堆起来，才是“有效”的实际门槛。
