RPN求值无需语法树，只需栈操作：遇数入栈，遇符弹两算一；显式建树违背其轻量本质，且易致内存泄漏与逻辑错误。
逆波兰表达式（RPN）求值本身不需要语法树；所谓“构建语法树”是中缀转后缀阶段的中间产物或调试辅助，不是 RPN 求值的组成部分。强行在 evalRPN 函数里塞树节点创建逻辑，只会让代码不可靠、难维护、且违背 RPN 的设计本意。
为什么 RPN 求值根本不需要语法树
RPN 的语义就是“见数压栈，见符弹两算一”。它已通过后缀顺序消除了括号和优先级歧义——整个计算过程天然对应一棵隐式的二叉表达式树，但你完全不需要显式构造它。一旦开始 new TreeNode、递归 build、记录 left/right 指针，你就已经偏离了 RPN 的轻量求值路径，滑向中缀解析的复杂度泥潭。
常见错误现象：evalRPN 里混入 if (s == "+") { auto node = new TreeNode('+'); ... } 这类代码，结果栈操作和树指针管理互相干扰，内存泄漏、空指针解引用、栈大小误判全来了。
- RPN 输入如
["4","13","5","+","/"]对应的隐式树是/ → (4, + → (13,5))，但求值只要 4 和 18 两个数，不关心结构 - 语法树真正有用的地方是：中缀转后缀时做 AST 验证、支持变量/函数调用、生成字节码——这些都在
infixToPostfix或独立 parser 里做 - 如果你被要求“输出语法树”，那任务其实是“给定 RPN 字符串，反推可能的中缀形式并建树”，这属于逆向工程，不是标准 RPN 求值
token 分割必须保留完整数字字符串，否则树结构无从谈起
想后续构建任何树（哪怕是为调试打印），前提是 token 切分正确。逐字符扫描会把 "-123" 拆成 "-" 和 "123"，导致你拿到一个孤立的减号 token 和一个正数 token，根本无法还原原始操作数节点。
立即学习“C++免费学习笔记（深入）”；
正确做法是先切分再分类：
- 用
std::istringstream或手写空格跳过循环，把输入字符串（如"4 13 5 + /"）拆成vector<string>{"4","13","5","+","/"}</string> - 对每个
token，只用token == "+" || token == "-" || token == "*" || token == "/"判断是否为运算符 - 其余一律视为操作数，交由
std::stoi(token)转换——它能安全处理"-42"、"+7"、"0"
漏掉这步，后面所有树节点的 val 字段都会错：你以为 token[0] == '-' 就该建负数节点，结果 "-" 被当操作符，"123" 被当正数，树就歪了。
如果真要输出语法树，得另起一套 builder，不能污染 evalRPN
假设需求明确要求“返回 RPN 对应的表达式树”，你应该拆成两个独立函数：vector<string> tokenize(const string& s)</string> 和 TreeNode* buildTreeFromRPN(const vector<string>& tokens)</string>。后者才是树构建入口，而 evalRPN 保持纯计算职责。
buildTreeFromRPN 的核心逻辑是模拟栈但存指针：
- 遇到数字 token → 创建
new TreeNode(stoi(token))并压入stack<treenode></treenode> - 遇到运算符 → 弹出两个
TreeNode*（注意顺序：先弹的是右子树，后弹的是左子树），新建父节点，连左右，再压栈 - 最后栈顶唯一节点即根节点
关键约束：buildTreeFromRPN 必须复用同一套 token 切分和类型判断逻辑，否则和 evalRPN 行为不一致，同一输入可能产生不同树或崩溃。
最易被忽略的陷阱：树构建时的弹栈顺序和空栈防护
和数值求值一样，树构建也严格依赖弹栈顺序：对 token 序列 ["3","4","-"]，栈内是 [node3, node4]，遇到 "-" 时必须先弹 node4（右），再弹 node3（左），才能建出 node{val:'-', left:node3, right:node4}。顺序反了，树结构就镜像翻转，后续遍历或求值全错。
同样，每次弹栈前必须检查 stack.size() >= 2：
-
tokens = {"+", "3"}会导致第一次弹栈就访问空栈，top()未定义行为 - 不检查就直接
auto right = stk.top(); stk.pop();，程序大概率 SIGSEGV - 这个检查不是“为了好看”，而是树节点指针非空的前提——你不能拿一个野指针去赋
node->right
真实工程中，没人会在生产环境的 RPN 求值里实时建树；需要树的场景，一定是在 parser 层完成中缀到 AST 的转换，RPN 只是其中一种序列化输出格式。混淆这两者，是绝大多数“RPN + 语法树”实现崩坏的起点。
