Go Expr 自定义函数参数不匹配为什么在编译期报错

Go Expr 自定义函数参数不匹配在编译期报错，通常不是运行时异常，而是类型检查器已经根据注册函数的签名判断出调用不成立。修复重点是让注册信息与表达式调用保持同一份参数契约：数量、顺序、类型和返回值都要对齐。

官方文档：https://expr-lang.org/docs/functions

这类错误常见于把 Go 函数放进 Expr 环境后，表达式写成了另一种调用方式。例如函数需要 (string, int)，规则却只传了一个参数，或者把数字写成了字符串。Expr 在 expr.Compile 阶段就会检查调用，因此不要把它当成 expr.Run 才会出现的业务异常。

Expr 为什么能在 Compile 阶段发现参数错误

Expr 把解析、类型检查和字节码编译放在 expr.Compile 这条路径中。使用 expr.Function 注册自定义函数时，第三个及后续参数可以传入函数类型，例如 new(func(string, int) string)。这个类型不是业务实现的第二份代码，而是表达式侧看到的调用契约。

如果表达式写成 normalize("gopher")，类型检查器会发现缺少第二个参数；如果写成 normalize("gopher", "3")，则会发现第二个参数是字符串而不是整数。两种错误都发生在程序还没有运行前，所以错误位置通常会指向表达式调用处。

用显式签名复现正确调用和两类错误

下面的示例把底层处理函数保持为可变参数实现，再用显式签名告诉 Expr 如何检查调用。实际项目也可以直接传入已有的 Go 函数类型；关键不在函数体写法，而在注册时有没有提供可供检查的签名。

package main

import (
	"fmt"
	"github.com/expr-lang/expr"
)

func main() {
	normalize := expr.Function(
		"normalize",
		func(params ...any) (any, error) {
			// 运行时只负责执行已经通过类型检查的参数。
			word := params[0].(string)
			limit := params[1].(int)
			if limit  limit {
				return word[:limit], nil
			}
			return word, nil
		},
		new(func(string, int) string), // 让 Expr 在 Compile 阶段检查两个参数。
	)

	program, err := expr.Compile(`normalize("gopher", 3)`, normalize)
	if err != nil {
		// 编译错误应阻止不完整规则进入缓存或发布流程。
		panic(err)
	}
	result, err := expr.Run(program, nil)
	if err != nil {
		// 这里处理的是函数体自身的运行时错误，而不是参数形状错误。
		panic(err)
	}
	fmt.Println(result) // 输出：gop
}

把表达式替换为 normalize("gopher")，得到的是参数数量错误；替换为 normalize("gopher", "3")，得到的是参数类型错误。不要只看错误文本，先看光标指向的调用位置，再回到函数签名核对参数顺序。

参数不匹配的排查顺序与边界

如果采用 expr.Env 直接注入具名 Go 函数，Expr 也会从函数本身读取类型；如果采用 func(params ...any) (any, error) 这种通用处理器，则应额外给出签名，否则类型检查器只能看到较宽的参数契约。多签名适合确实支持多种输入的函数，但每个签名都应对应一条真实的业务语义，不能用它掩盖参数设计不清。

发布前把 Compile 错误挡在规则上线之前

在配置中心或数据库加载规则时，建议把“读取文本—注册函数—Compile—缓存 program”做成一个原子步骤。Compile 失败就记录规则版本、表达式位置和具体错误，不替换当前可用的 program；只有成功编译的程序才进入并发运行缓存。这样参数写错会在发布检查阶段暴露，而不会等到某个请求命中规则时才发现。

这里的边界也很明确：Compile 阶段只能保证调用形状与静态类型契约成立，不能保证远端服务可用、业务数据满足约束或函数体不会返回业务错误。后者仍要在函数实现和 Run 阶段处理超时、错误值与资源释放。

常见问题

只写一个可变参数函数，为什么没有立刻报错？

因为 any 和可变参数表达的是宽契约。给 expr.Function 追加具体函数签名，才能让检查器知道精确的参数数量和类型。

把第二个参数改成数字，为什么仍然不通过？

还要核对数字的实际推断类型、函数签名和返回值约束；不要只凭字面看起来像数字就判断已经匹配。

能不能把参数校验全部放进函数体？

不建议。函数体适合处理业务边界和运行时错误，参数个数与静态类型应尽量在 Compile 阶段阻断。