因为strconv.ParseFloat仅解析单个数字字面量，无法处理运算符、括号及优先级逻辑，必须用双栈（操作数栈+运算符栈）按优先级延迟计算并支持负号、多位数和括号嵌套。
为什么不能直接用 strconv.ParseFloat 解析带括号和运算符的公式字符串
因为 strconv.ParseFloat 只能处理单个数字字面量（比如 "3.14" 或 "-2e5"），遇到 "2+3*4" 或 "(1+2)*3" 会直接报错 invalid syntax。它不理解运算符优先级，也不支持括号嵌套——这正是双栈（操作数栈 + 运算符栈）要解决的问题。
典型错误现象：把整个公式字符串丢给 strconv.ParseFloat，结果 panic 或返回 0 + error；或者手动切分字符串但忽略乘除优先于加减、括号打断优先级，导致 "1+2*3" 算成 9 而不是 7。
- 运算符必须按优先级延迟计算：遇到
+或-时，若栈顶是*或/，得先弹出并运算 - 左括号
'('只进栈，不触发计算；右括号')'则持续弹出直到匹配左括号 - 数字解析要跳过前导空格、支持负号（如
"-5"），但不能把"(-5)"中的'-'当作二元运算符
如何用两个 []float64 和 []rune 实现安全的双栈求值
Go 没有内置栈类型，直接用切片模拟最轻量。关键不是“怎么建栈”，而是“什么时候压、什么时候弹、弹多少”。核心逻辑在扫描字符时决策：
示例片段（仅主干逻辑）：
立即学习“go语言免费学习笔记（深入）”；
nums := []float64{}
ops := []rune{}
for i := 0; i < len(s); i++ {
c := rune(s[i])
if unicode.IsDigit(c) || c == '-' && (i == 0 || !unicode.IsDigit(rune(s[i-1])) && s[i-1] != ')') {
// 解析完整数字（含负号），追加到 nums
num, j := parseNum(s, i)
nums = append(nums, num)
i = j - 1 // 调整索引
} else if c == '(' {
ops = append(ops, c)
} else if c == ')' {
for len(ops) > 0 && ops[len(ops)-1] != '(' {
nums, ops = calcOne(nums, ops)
}
ops = ops[:len(ops)-1] // 弹出 '('
} else if c == '+' || c == '-' || c == '*' || c == '/' {
for len(ops) > 0 && prec(ops[len(ops)-1]) >= prec(c) {
nums, ops = calcOne(nums, ops)
}
ops = append(ops, c)
}
}-
calcOne必须从nums弹出两个操作数：注意顺序——栈底到栈顶是“先算的数在前”，所以第二个弹出的是左操作数，第一个是右操作数（a - b中a先入栈，b后入，计算时先弹b再弹a） -
prec函数返回优先级：'*'和'/'返回 2，'+'和'-'返回 1，'('返回 0（永不被弹出） - 空格必须跳过，否则
"1 + 2"里空格会被误判为非法字符
哪些输入会导致双栈算法崩溃或结果错误
不是所有字符串都能喂给这个算法——它假设输入是合法中缀表达式。实际使用前必须预检，否则 runtime panic 或静默错误：
- 空字符串或全空格 →
nums为空，最后取nums[0]panic - 括号不匹配：
"(1+2"导致ops末尾残留'('，后续无')'触发弹出，最终栈不空但没检查 → 返回错误结果 - 连续运算符：
"1++2"或"1*+2"，当前逻辑会把第二个'+'压栈，之后弹出时操作数不够 →nums长度 - 除零：
"1/0"不报错，但返回+Inf或NaN，需在calcOne里显式判断if op == '/' && b == 0.0
建议在入口加一层校验：用正则粗筛（如 ^[\d+\-*/().\s]+$）再跑双栈；或在每次弹栈前 assert len(nums) >= 2。
性能与边界场景：为什么不用 go/parser 或第三方库
标准库 go/parser 解析的是 Go 源码语法树，不接受 "2*(3+4)" 这种纯数学表达式（会报 expected 'import', found '2'）；而引入 shunting-yard 类库又过度——双栈实现不到 100 行，无依赖、易调试、可控性强。
- 时间复杂度是 O(n)，每个字符最多入栈出栈一次；空间 O(n) 存储数字和符号
- 浮点精度问题：Go 的
float64无法精确表示0.1 + 0.2，若业务要求精确小数（如金融），得换用big.Float，但运算慢且双栈逻辑需重写弹栈部分 - 科学计数法支持弱：当前解析只处理十进制数字，
"1e2"会被截断为1；需扩展parseNum用strconv.ParseFloat(s[i:j], 64)
真正容易被忽略的，是负号的上下文判断——它既可能是二元减法，也可能是数字前缀。这个分支写错，"3*(-4)" 就会变成 3 * 0 或 panic。
