Go REPL 引擎拆解：表达式求值器与行编辑库

1. 为什么交互式求值引擎要拆成两块拼图

1.1 从“改一行跑一次”到“边敲边看”

做过 Go 小工具的人大概都有这么一段经历：想验证一段表达式，比如某个位运算到底切成什么样、某个时间戳解析出来是不是预期值，于是打开编辑器写一个main.go，fmt.Println一下，再go run。三五秒的编译等待平时不算什么，可一旦进入“改一行、跑一次、再改一行”的循环，这种摩擦感就会被放大几十倍。更要命的是状态丢失——前一秒刚构造好的一个大 slice，下一秒改了别的代码重新跑，全没了。

交互式求值引擎就是为了消灭这段摩擦而存在的。它的核心是两块东西：一块叫表达式求值器，负责把“a + b * 2”这样的字符串变成真正的值；另一块叫行编辑库，负责让你在终端里能正常打字、退格、翻历史、按 Tab 补全。在 Go 生态里，go-eval 这类表达式求值器配合 liner 这类行编辑库，是搭一个交互式 REPL 最常见的组合方式。

这篇内容写给两类人：一类是手头正好要做个内部调试小工具、想快速验证复杂表达式或配置规则的开发者；另一类是纯粹好奇“终端里那个能左右移动光标的输入框到底是怎么实现的”的同学。全文会按“先讲清分工、再拆开内部、最后拼回去”的顺序推进，中间穿插大量实操参数和踩坑记录，读完基本可以自己撸一个能用的交互式求值引擎出来。

1.2 职责边界：求值器管语义，行编辑器管像素

把这两个组件放在一起，最大的设计收益是职责边界干净。

行编辑库只关心三件事：用户按下了哪个键、当前缓冲区里的内容是什么、屏幕上光标该画在哪里。它完全不知道a + b是什么意思，也不需要知道。你把输入源换成从文件读、从网络读，它依然能工作——因为它压根不参与语义。

表达式求值器只关心一件事：这段字符串按照语言规范算出来的值是什么、出了什么错。它不关心这段字符串是从终端敲进来的还是从配置文件里读出来的，也不关心终端是不是支持光标移动。

中间靠一个薄薄的主循环粘合：行编辑器吐出一行字符串，主循环判断“这一行完整吗”，完整就丢给求值器，拿到结果再打印出去。分成两个独立组件而不是揉在一起，好处在实测中非常明显：

• 可测试性。求值器是纯函数式的，输入字符串、输出值或 error，写单元测试不用起终端，CI 里跑得飞快。如果揉在一起，测一个加法都要模拟按键序列，成本高一个数量级。
• 可替换性。哪天想把这个引擎接成 HTTP 接口或者编辑器插件，只换掉行编辑那一层，求值逻辑原封不动。
• 终端差异隔离。Windows 控制台、Linux tty、各类终端模拟器的行为差异全被关在行编辑库内部，求值器完全不受污染。

1.3 选型时我盯的几个硬指标

当年挑组件的时候列了一张对照表，这里直接摊开，省得别人再走一遍弯路：

这里有个容易被忽略的点：错误信息带位置。单行输入时无所谓，一旦支持多行（比如粘贴一段结构体字面量进去），错误只报“语法错误”而不告诉你是第几行第几列，排查起来能让人抓狂。我后来的做法是让求值层统一返回一个带Offset的错误结构，主循环负责把它换算成“第几行第几列”再展示。

提示：选型阶段先把“多行输入”这个需求确定下来。很多行编辑库默认是单行模型，后期硬改多行会比一开始就选对方案痛苦得多。

2. 求值器的三次变形：从字符串到值的三段流水线

2.1 第一段：词法与语法分析，标准库已经帮你做完了

Go 在这一点上运气很好——标准库自带go/scanner、go/parser、go/ast，一个完整的 Go 语法前端是现成的。go-eval 这类库通常直接复用它，而不是自己手写词法分析器。

具体做法是用parser.ParseExpr而不是parser.ParseFile。区别在于：ParseFile期望输入是一个完整的源文件，必须带package声明；ParseExpr只解析一个表达式，输入1 + 2 * 3直接就能拿到一棵ast.BinaryExpr树。

func parseOnly(src string) (ast.Expr, error) { expr, err := parser.ParseExpr(src) if err != nil { // 这里的 err 通常是 scanner.ErrorList，带位置信息 return nil, err } return expr, nil }

这一段的产物是一棵抽象语法树。举例说明，"a + b * 2" 解析后根节点是*ast.BinaryExpr，Op是token.ADD，X是标识符a，Y又是一个*ast.BinaryExpr，Op是token.MUL。算符优先级在这一步就已经固化成树形结构了，后面求值只需要老老实实后序遍历，压根不用再操心谁先算。

这一步的实操要点是：一定要保留token.FileSet。Parser 报错时的位置信息依赖它才能换算成人类可读的行列号。很多人图省事传token.NewFileSet()用完就丢，结果报错全是1:5: expected ...这种看不出所以然的东西。

2.2 第二段：类型检查，别急着上反射

新手最容易犯的错是跳过类型检查，直接在 AST 上做reflect运算。这么干在简单场景下能跑，一碰到下面这几种情况立刻翻车：

• 1 / 2到底是0还是0.5？
• var a interface{} = 1; a + 1该不该报错？
• 两个不同底层类型的自定义类型相加，结果类型是什么？

这些问题的答案全在 Go 的类型规则里，而 Go 的类型规则已经被go/types完整实现了。正确姿势是：先走一遍types.CheckExpr，拿到每个节点的类型，再去求值。

func typeCheck(fset *token.FileSet, expr ast.Expr) (types.Type, error) { info := &types.Info{ Types: make(map[ast.Expr]types.TypeAndValue), } tv, err := types.CheckExpr(fset, token.NoPos, expr, info) if err != nil { return nil, err } return tv.Type, nil }

types.CheckExpr返回的TypeAndValue里有个特别关键的字段：Value。对于常量表达式，这个字段直接就是编译期算好的值。也就是说1 + 2 * 3这种纯常量表达式，连求值阶段都不用进，类型检查阶段顺手就出结果了。这个优化在小引擎里收益不大，但概念上必须搞清楚——Go 的常量是在类型检查阶段折叠的。

还有一个绕不开的概念是无类型常量（untyped constant）。字面量1的类型是untyped int，它可以被赋给int8、int64、float64甚至complex128，具体选哪个取决于上下文。这一点在交互式求值里必须复现，否则var x int32 = 1会莫名其妙报类型不匹配。

2.3 第三段：求值遍历，reflect.Value是唯一的桥

类型确定之后，才轮到真正的求值。这一层的核心是写一个 visitor，递归下降地处理每种 AST 节点。返回值统一用reflect.Value承载——因为 Go 的类型是运行期才知道的，而reflect是运行期操作任意类型值的唯一标准手段。

简化后的骨架长这样：

func evalExpr(scope *Scope, expr ast.Expr) (reflect.Value, error) { switch e := expr.(type) { case *ast.BasicLit: return evalBasicLit(e) // 字面量：ints、floats、strings、chars case *ast.Ident: return scope.Lookup(e.Name) // 标识符：查作用域 case *ast.BinaryExpr: return evalBinary(scope, e) // 二元运算：先算子节点 case *ast.CallExpr: return evalCall(scope, e) // 函数调用 case *ast.IndexExpr: return evalIndex(scope, e) // 索引：切片、数组、map、字符串 case *ast.UnaryExpr: return evalUnary(scope, e) case *ast.CompositeLit: return evalCompositeLit(scope, e) // 复合字面量：切片、map、结构体 } return reflect.Value{}, fmt.Errorf("暂不支持的表达式类型 %T", expr) }

evalBinary是最容易写错的地方。看着简单——“取左右两个reflect.Value，按Op做运算”，实际上要处理的分支有十几条：算术、比较、逻辑、位运算、移位、字符串拼接。每一条都要考虑操作数类型是否一致、是否需要隐式转换、结果类型是什么。

举个具体例子：int32(1) + int64(2)。Go 里这是编译错误，因为两边类型不同。但在reflect层面，你拿到的是reflect.ValueOf(int32(1))和reflect.ValueOf(int64(2))，如果直接用.Int()取出来再相加，就会静默地变成int64(3)——类型检查的规则被绕过去了。所以正确写法是先比较Kind()和Type()，不一致就报错，一致再在对应 Kind 的分支里运算。

注意：reflect.Value.Int()返回的永远是int64，Uint()永远是uint64，Float()永远是float64。用完之后必须按原类型Convert回去，否则int8的运算结果会变成int64，后续再赋给int8变量就报错了。

3. 求值器核心细节：作用域、字面量与函数注入

3.1 scope 的链式查找与生命周期管理

交互式求值跟一次性求值最大的区别是状态要延续。你在第一行敲了a := 10，第二行敲a * 2，期望得到 20，而不是“未定义标识符 a”。

这就需要一个作用域对象。主流实现是一个链式结构：每个 scope 持有一个map[string]reflect.Value存变量，以及一个指向父 scope 的指针。查找时先查自己，查不到再往上找，一路找到根。

type Scope struct { parent *Scope vars map[string]reflect.Value consts map[string]reflect.Value } func (s *Scope) Lookup(name string) (reflect.Value, error) { for cur := s; cur != nil; cur = cur.parent { if v, ok := cur.vars[name]; ok { return v, nil } if v, ok := cur.consts[name]; ok { return v, nil } } return reflect.Value{}, fmt.Errorf("undefined: %s", name) }

链式查找的好处是支持嵌套。REPL 主循环持有一个根 scope，每次求值创建一个子 scope 并挂上去，这样即使在表达式内部定义了临时变量（比如函数字面量的参数），也不会污染全局。求值结束后子 scope 自然被 GC 回收，内存不会无限增长。

这里有个容易踩的坑：变量声明和变量赋值要走不同路径。a := 1是*ast.AssignStmt且Tok是token.DEFINE，语义是“在当前 scope 新建变量”；a = 1是普通赋值，必须找到已存在的a并修改它。如果两者混着处理，a := 1; a := 2不会报错，a = 1又会在全局凭空创建变量，行为会变得非常诡异。

还有一个细节：reflect.Value本身是不可变的，修改值必须通过可寻址的reflect.Value（由reflect.New或取地址得到）。所以 scope 里存的其实不是reflect.Value，而是reflect.Value指向的那个变量的Elem()。写法上是用reflect.New(t).Elem()创建，存下来的时候保持可寻址状态。

3.2 字面量与自动类型推导：那些“看起来对其实错”的陷阱

字面量处理看着最没技术含量，实际上坑最多。列几个我在实际项目里真实撞上的：

坑一：整数除法。1 / 2在 Go 里是0。但如果求值器内部统一用float64表示所有数字，结果就会变成0.5。这个偏差极其隐蔽，用户拿去做索引会直接 panic。正确做法是严格按 token 类型走：两个整数相除，结果还是整数。

坑二：int的宽度。reflect.TypeOf(1).Kind()是reflect.Int，不是reflect.Int64。在 64 位平台它们底层一样宽，但在一些边界场景（比如和int32混算）行为会不同。判断类型时看Kind()，别去比字符串名字。

坑三：浮点字面量的默认类型。1.5默认是float64，但如果上下文要求float32，就得能转过去。这个逻辑必须放在类型检查阶段处理，求值阶段已经拿不到原始上下文了。

坑四：字符字面量。'a'是rune（即int32），不是string。初次实现的人经常把它当字符串处理，'a' + 1会得到"a1"而不是98。

坑五：字符串的不可变性。Go 的字符串底层是只读字节序列，s[0] = 'x'是编译错误。但求值器里如果直接用reflect.Value.Index()拿到元素，它返回的是一个不可寻址的值，写回去会 panic，报错信息还特别难懂：reflect.Value.Set using unaddressable value。好的做法是在索引赋值时先判断CanSet()，不行就直接返回“字符串不可修改”这类人话。

坑六：整数溢出。Go 的整数运算是静默溢出的，int8(127) + int8(1)得到-128，不报错。求值器要不要保持一致？我的选择是保持一致，因为这是语言规范。如果做的是配置规则引擎那种场景，可以额外加一层溢出检测，但要在文档里写清楚这是增强而不是语言行为。

3.3 内建函数与宿主函数注入

一个只能算算术的求值器没什么用，得有函数。函数分两类：语言内建的（len、cap、append、make、copy、delete、panic、recover）和宿主注入的（你自己想把哪些 Go 函数暴露给表达式用）。

内建函数必须单独处理，因为它们有特殊语义。append就是典型的例子：它不是普通函数调用，编译器在背后做了大量工作——容量够就原地追加，不够就重新分配。用reflect模拟的话要写成这样：

func builtinAppend(args []reflect.Value) (reflect.Value, error) { if len(args) < 2 { return reflect.Value{}, fmt.Errorf("append 至少需要 2 个参数") } slice := args[0] if slice.Kind() != reflect.Slice { return reflect.Value{}, fmt.Errorf("append 第一个参数必须是切片，实际是 %s", slice.Kind()) } elems := args[1:] for _, el := range elems { if !el.Type().AssignableTo(slice.Type().Elem()) { return reflect.Value{}, fmt.Errorf("append 元素类型不匹配") } slice = reflect.Append(slice, el) } return slice, nil }

len相对简单，因为它对字符串、数组、切片、map、channel 都适用，一个Len()就能拿到，对指针指向数组的情况要额外Elem()一下。make麻烦一些，因为它的第一个参数是类型而不是值，从 AST 上看是*ast.Ident或*ast.ArrayType，需要先把类型解析出来再调reflect.MakeSlice/reflect.MakeMap/reflect.MakeChan。

宿主函数注入这块，接口设计上我倾向于用一个map[string]interface{}，求值器内部用reflect.ValueOf(fn)包一层，调用时把 AST 参数求值后Call过去。这样用户可以随便塞 Go 函数进去：

session := NewSession() session.Register("now", func() int64 { return time.Now().Unix() }) session.Register("upper", strings.ToUpper) session.Register("split", func(s, sep string) []string { return strings.Split(s, sep) })

注册完直接就能用：upper("hello")返回"HELLO"。这套设计的好处是零代码生成、零编译期依赖，代价是每次调用都有一次反射开销。在交互式场景里这点开销完全可以忽略。

3.4 panic 与错误的兜底：别让一句表达式干掉整个会话

求值器最怕的事情是用户敲了一句1/0或者nil.(interface)，直接把整个 REPL 进程带崩。Go 的整数除零是panic: runtime error: integer divide by zero，反射调用出错也是 panic 或者返回零值加错误。

兜底方案很朴素：在每次求值的边界上包一层recover。

func safeEval(scope *Scope, expr ast.Expr) (out reflect.Value, err error) { defer func() { if r := recover(); r != nil { err = fmt.Errorf("求值 panic: %v", r) out = reflect.Value{} } }() return evalExpr(scope, expr) }

这层recover必须放在evalExpr外面，不能放里面，否则递归调用过程中某一层 panic 被吞掉，上层会拿到一个零值继续算，错误会传播成更离谱的结果。

还有一个容易被忽视的点：错误要区分“编译期”和“运行期”。1 + "a"是类型错误，属于编译期，应该在类型检查阶段就拦下来，报错信息要和go build一致：invalid operation: 1 + "a" (mismatched types untyped int and untyped string)。而a[10]越界属于运行期，报index out of range [10] with length 3。两类错误的处理路径不同，混着报会导致用户看到一堆莫名其妙的内部错误。

4. 行编辑库的工作原理解析

4.1 终端原始模式：把回车键的所有权拿回来

在普通终端里，你敲的每个字符其实先被终端的“行缓冲”和“回显”机制处理了。按键先攒在缓冲区里，直到你按下回车，进程才一次性收到整行数据，同时终端自动把你敲的字符回显到屏幕上。

这个机制对普通命令行工具很友好，但对行编辑库来说是灾难——因为你没法知道用户按的是左箭头还是删除键，所有按键都被吞进缓冲区了。

解决方案是切到终端原始模式（raw mode）。在 Linux/macOS 上通过termios结构体操作：关闭ICANON（关行缓冲）、关闭ECHO（关自动回显）、设置VMIN=1和VTIME=0（每次至少读一个字节）。

// 概念示意，实际实现要处理平台差异 old := tcgetattr(fd) new := old new.Lflag &^= unix.ICANON | unix.ECHO new.Cc[unix.VMIN] = 1 new.Cc[unix.VTIME] = 0 tcsetattr(fd, new)

切进去之后，进程能逐字节收到按键了。但代价是：你自己得负责把字符画到屏幕上。用户敲了a，你得自己输出a并把光标右移一格；用户按退格，你得输出\b \b把字符擦掉。

这套机制还有个必须做的收尾：程序退出前一定要把终端设置恢复回去。否则用户回到 shell 之后会发现打字不显示回显、回车不换行，得手动敲reset才能救回来。稳妥做法是defer恢复，并且接管os.Interrupt信号做优雅退出。

4.2 行缓冲区与重绘：光标位置是算出来的

行编辑库内部维护一个 rune 切片作为行缓冲，外加一个整数作为光标下标。

举个例子，用户在hello中间插入字符。光标在第 2 位（he|llo），此时按下X，缓冲区变成heXllo，光标移到第 3 位。接下来要在屏幕上把新内容画出来——最简单的做法是整行重绘：

1. 把光标移到行首（\r）
2. 输出整个缓冲区内容
3. 输出\x1b[K清掉行尾残留
4. 把光标从行尾移回到正确位置（\x1b[<n>D左移 n 格）

整行重绘在行内容不长时完全够用，代码简单、bug 少。只有在长行（比如几百字符）时才会感觉到闪烁，那时候再上增量重绘优化。

这里有个必须特别注意的点：光标位置不能用字节数或 rune 数算。中文、日文、韩文字符在多数终端里占两列宽，用len(line)或len([]rune(line))算出来的位置都是错的，光标会跑到字的中间去。正确做法是引入一个字符宽度表，对每个 rune 查它的显示宽度，累加得到列号。

func displayWidth(r rune) int { // 组合字符宽度 0，东亚宽字符宽度 2，其余 1 if unicode.Is(unicode.Mn, r) { return 0 } if isWideRune(r) { return 2 } return 1 }

同理，删除字符的时候也不能简单退一格——删掉一个中文字符要退两格。这就是为什么有些简陋的 REPL 在处理中文输入时会留下一堆残影。

4.3 历史记录与 Tab 补全：两个独立的小系统

历史记录本质上就是一个字符串切片。按上箭头，索引减一，把对应内容复制到缓冲区；按下箭头，索引加一。边界处理是：索引到 0 就不再减小，到末尾时要不要保留“用户正在输入但还没提交的内容”是个设计选择——多数实现会先暂存当前输入，翻到底再恢复回来。

持久化就是把整个切片按行写到一个文件里。这里有两个实践细节：文件权限设成 0600，因为历史里可能包含敏感内容；写入要限长，只保留最后 N 条（我一般设 1000 条），否则文件会无限膨胀。

Tab 补全是一个回调函数，签名通常是func(line string) []string。库在用户按下 Tab 时调用它，拿到候选列表后自己决定弹出菜单还是自动补全公共前缀。

补全逻辑怎么写，取决于这个引擎暴露了什么。变量名和函数名是最基础的：

func (s *Session) completer(line string) []string { var names []string for name := range s.scope.vars { if strings.HasPrefix(name, line) { names = append(names, name) } } for name := range s.funcs { if strings.HasPrefix(name, line) { names = append(names, name+")") // 函数补上右括号 } } sort.Strings(names) return names }

注意：补全回调里千万别做耗时操作。有些实现会在补全时去扫文件系统、查远程接口，用户按一下 Tab 卡半秒，体验直接崩盘。所有可能慢的数据都应该提前缓存好。

4.4 多行输入与中断信号的语义设计

多行输入是交互式求值引擎的分水岭。粘贴一段结构体字面量进去，你不希望它一行一行地执行，而是希望攒齐了再求值。

行编辑库本身通常只负责“拿一行”，续行判断得自己做。最稳的办法不是去数括号，而是用已解析的 AST 来判断。但第一行还没法完整解析的时候，只能靠启发式：统计圆括号、方括号、花括号的配对情况，以及检查行尾是不是逗号、反引号、运算符。

func needsMoreInput(line string) bool { depth := 0 inString := false var quote rune for _, r := range line { switch { case inString: if r == quote { inString = false } case r == '"' || r == '\'' || r == '`': inString = true quote = r case r == '(' || r == '[' || r == '{': depth++ case r == ')' || r == ']' || r == '}': depth-- } } return depth > 0 || inString }

注意这里要处理字符串内部的花括号，否则"}"这种内容会被误判成闭合。反引号（raw string）还得额外处理，因为它允许跨行。

Ctrl-C 和 Ctrl-D 的语义要分开设计。Ctrl-C 在空行时标准行为是打印一个换行并重新出提示符；在有内容时是清空当前行。Ctrl-D 在空行时是 EOF，退出会话；在行中间是删除光标处的字符。这套约定是从 shell 继承来的，用户已经形成肌肉记忆，乱改会让人非常别扭。

5. 把两块拼起来：REPL 主循环的实操实现

5.1 最小可跑的骨架

把前面所有东西拼起来，主循环大概长这样：

type Session struct { scope *Scope liner *liner.State history string } func (s *Session) Run() error { s.liner = liner.NewLiner() defer s.liner.Close() s.liner.SetCtrlCAborts(true) s.liner.SetCompleter(s.completer) if f, err := os.Open(s.history); err == nil { s.liner.ReadHistory(f) f.Close() } defer s.saveHistory() var buf strings.Builder for { prompt := ">>> " if buf.Len() > 0 { prompt = "... " } line, err := s.liner.Prompt(prompt) if err == liner.ErrPromptAborted { buf.Reset() continue } if err == io.EOF { return nil } if err != nil { return err } buf.WriteString(line) buf.WriteString("\n") if needsMoreInput(buf.String()) { continue } src := buf.String() buf.Reset() s.liner.AppendHistory(strings.TrimSpace(src)) result, err := s.eval(src) if err != nil { fmt.Fprintf(os.Stderr, "%v\n", err) continue } if result.IsValid() { fmt.Println(formatValue(result)) } } }

这段代码不长，但每一行都有讲究。SetCtrlCAborts(true)让 Ctrl-C 返回ErrPromptAborted而不是直接退出进程；ReadHistory和WriteHistory用 defer 包住，保证异常退出也能保存；AppendHistory在求值之前调用，这样即使表达式报错，历史里也留下了记录，方便改。

5.2 续行判定的实战考量

前面那个needsMoreInput用的是括号配对法，够用但不完美。实际跑起来还有几个边界要补：

• 行尾是逗号：f(a,明显没完，括号配对也检测得出来。
• 行尾是运算符：1 +括号是平的，但明显没完。要额外检查最后一个非空白 token 是不是运算符。
• 行尾是反斜杠：某些场景下用\显式续行，也得识别。
• 空行提交：多行模式下，用户敲一个空行通常表示“我写完了，执行吧”。这是多数 REPL 的约定。

我踩过最坑的一个 case 是粘贴带缩进的代码块。终端会把粘贴内容按字母逐个送进输入缓冲区，如果某一行以}开头，括号深度马上就归零了，引擎会以为输入结束，把残缺的一段拿去求值，然后报一堆语法错误。解决办法是识别“粘贴模式”——检测到短时间内涌入大量字符就暂缓求值，或者干脆提供一个.paste命令进入多行粘贴模式，空行加.end结束。

5.3 输出顺序与提示符刷新的微妙关系

看着不起眼的细节，实际调试起来很花时间：打印结果之后，提示符什么时候出现。

如果求值结果是直接fmt.Println出来的，而下一个Prompt调用是异步刷新的，在某些终端上会出现提示符先出现、结果后打印，导致提示符被结果挤到上面去。解决方式是保证输出和提示符在同一条写路径上：先完整打印结果并确保换行，再调用Prompt。liner 这类库内部会处理光标位置，但前提是你别在它重绘的时候插一脚。

另一个相关的问题：求值过程中产生的输出。如果表达式里调用了会打印的宿主函数（比如print("x")），输出会直接写到 stdout，和 liner 管理的提示符区域打架。稳妥做法是在求值期间临时接管os.Stdout，把内容缓存到缓冲区，求值完成后再统一输出。

6. 排查实录：那些只在终端里出现的怪问题

6.1 求值侧的高频故障

问题一：undefined: a，但明明上一行刚定义过。

九成是作用域没接上。检查主循环是不是每次都NewScope(nil)而不是NewScope(rootScope)。另一个可能是定义语句走了普通赋值路径，变量被写进了临时 scope，求值结束就被回收了。

问题二：1/2返回0.5。

数字类型统一成了float64。去evalBinary的除法分支看，是不是无脑Float()了。正确做法是按Kind()分支处理，Int系列走整数除法。

问题三：reflect.Value.Set using unaddressable value。

scope 里存的是不可寻址的值。改成reflect.New(t).Elem()创建，或者用指针 +Elem()访问。

问题四：复杂表达式求值极慢。

大概率是每次都重新走了解析和类型检查。对于交互式场景，可以按源码字符串做一层缓存，命中就直接复用 AST。另外检查一下是不是在递归里反复reflect.TypeOf，这个调用有锁竞争，能缓存就缓存。

问题五：报错信息只有syntax error，没有位置。

parser.ParseExpr返回的是scanner.ErrorList，得用类型断言取出来逐条打印：

if list, ok := err.(scanner.ErrorList); ok { for _, e := range list { fmt.Printf("%s: %s\n", e.Pos, e.Msg) } }

6.2 终端侧的高频故障

问题一：中文输入后光标错位。

前面说过，宽度计算没考虑东亚宽字符。检查所有涉及光标移动的地方，是不是用了len(s)或len([]rune(s))。

问题二：程序退出后终端不回显。

原始模式没恢复。确保defer liner.Close()一定被执行，并且在os.Exit之前手动恢复一次。极端情况下用户按 Ctrl-Z 挂起也会出问题，需要处理SIGTSTP。

问题三：管道输入时直接报错。

liner这类库需要真正的 tty。判断一下os.Stdin是不是终端（用term.IsTerminal(int(os.Stdin.Fd()))之类的方式），不是的话就退化到bufio.Scanner逐行读，别硬上。

问题四：粘贴多行时字符错乱。

终端在原始模式下不做行缓冲，粘贴内容会逐字节送达。如果行编辑库的按键解析状态机不够健壮，遇到控制字符会乱。缓解办法是提供一个批量粘贴的入口，或者限制单次读取的字符数。

问题五：窗口 resize 后提示符消失。

没处理SIGWINCH。收到信号后重新查询终端尺寸，然后触发一次重绘。这个功能不算关键，但没有的话拉伸窗口时体验很糟。

6.3 问题速查表

7. 安全与性能的兜底设计

7.1 表达式沙箱：明确允许什么、禁止什么

一旦这个求值引擎不只在本地用，比如接了个 HTTP 接口让别人提交表达式，安全问题立刻变成第一位。核心原则是白名单，不是黑名单。

具体来说，AST 遍历时要主动拒绝这几类节点：*ast.ImportSpec（禁止导入包，这直接决定了求值器只接受表达式而不接受文件）、任何形式的文件读写、网络调用、进程启动。宿主函数的注册表就是全部可用的能力集合，注册表里没有的，表达式里就不可能调到。

还有几个隐蔽的逃逸路径要堵住：

• 反射逃逸。如果暴露了reflect.ValueOf或者任何返回interface{}再让表达式随意类型断言的函数，用户理论上能拿到不该拿的东西。稳妥做法是宿主函数一律返回具体类型。
• 无限递归。表达式里定义了函数字面量并递归调用自己，几秒钟就能把栈打爆。做法是在求值器里维护一个递归深度计数，超过阈值直接返回错误。
• 超大内存分配。make([]byte, 1<<30)一句话就能吃掉 1G 内存。对make和复合字面量的长度参数做上限检查。
• 死循环。纯表达式其实写不出死循环，因为 Go 的for是语句不是表达式。但如果你的引擎支持语句块，那就必须加超时。

7.2 性能数据与优化取舍

在一个空载的求值引擎上做过粗略测量（本机 x86_64 环境，仅作量级参考）：一次简单的1 + 2从解析到出结果大约在十几到几十微秒；带变量查找的a * b + c略高一点；一次append调用因为走反射，比原生慢一到两个数量级；涉及 map 索引的表达式开销更高，因为reflect.MapIndex内部要做类型检查。

这些数字放在交互式场景里完全无感——人打字的速度是毫秒级，微秒级的求值开销可以忽略。所以优化的优先级应该是：先把正确性和错误信息做好，性能最后再管。

真要做优化，几个方向按性价比排序：一是缓存解析和类型检查的结果，按源码字符串做键；二是把热点路径上的reflect.TypeOf换成预先存好的reflect.Type；三是对纯常量表达式在类型检查阶段就折叠掉，根本不进求值；四是对高频调用的宿主函数做专门的内联处理，绕过通用的Call路径。

我自己的经验是，前三项做完，绝大多数场景就够用了。第四项只在把引擎嵌进高 QPS 服务里时才值得考虑，而且那时候往往应该换设计——把表达式编译成闭包缓存起来，而不是每次现算。

最后分享一个我觉得最值的小设计：给每次求值记录耗时，超过 100 毫秒就在结果后面附一行灰字提示。这个小功能帮我抓到过好几次“某个宿主函数内部做了不该做的 IO”的问题，成本几乎为零，收益却很高。