Go constant.Make 传入 int 为什么得到 Unknown

constant.Make 不是接收所有 Go 数值类型的自动转换器。它按传入接口值的动态类型构造常量：支持 int64，但不支持 int，因此传入 int 会得到 Kind 为 Unknown 的结果。已经明确持有 int 时，可先转为 int64，再调用 MakeInt64；处理无符号整数时选择 MakeUint64。

官方文档：https://pkg.go.dev/go/constant#Make

命名输入适配边界

在配置转换器或静态分析工具里，业务数据常先放进接口，再交给常量运算层。这个边界需要回答两个问题：输入的动态类型是什么，业务允许怎样转换。只看调试输出里的数字相同，无法说明它们会走同一种构造规则。

我更倾向于在这一层明确列出支持类型，而不是把未知输入统统交给 Make，再等后续运算出现 unknown。这样错误可以留在输入发生的位置，调用者也能知道是数据类型不匹配，还是表达式本身尚不可确定。

识别类型丢失位置

Make 的参数是接口。把 int 存入接口后，它仍然是 int，不会因为目标函数也支持 int64 就自动升级。直接把无类型整数文字传给接口参数时，也会先采用默认的整数类型 int。要排查这类问题，打印 %T 比只打印 %v 更有用。

官方支持表包含 bool、string、int64、*big.Int、*big.Float 与 *big.Rat。其余类型进入 Unknown。这里列出的是 Make 的输入约定，不是 go/constant 整个包的能力清单；包里另有 MakeUint64、MakeFloat64 等专用构造函数。

最小实现对照

下面把相同的数值用 int、int64、接口包装与专用构造器分别表达。示例仅用于呈现类型契约，没有进行性能比较。

package main

import (
 "fmt"
 "go/constant"
)

// 业务边界只接受这里列出的整数类型，其他输入明确报错。
func integerValue(x interface{}) (constant.Value, error) {
 switch v := x.(type) {
 case int:
  return constant.MakeInt64(int64(v)), nil
 case int64:
  return constant.MakeInt64(v), nil
 case uint64:
  return constant.MakeUint64(v), nil
 default:
  return nil, fmt.Errorf("不支持的整数输入类型：%T", x)
 }
}

func main() {
 n := int(37)
 wrapped := interface{}(n)
 // 接口包装保留动态类型 int，Make 不会自动改成 int64。
 for _, x := range []interface{}{n, wrapped, int64(n)} {
  v := constant.Make(x)
  fmt.Printf("输入=%T，种类=%v，值=%s\n", x, v.Kind(), v.ExactString())
 }
 // 显式适配后再构造，业务可以立即处理错误。
 v, err := integerValue(n)
 if err != nil { fmt.Println(err); return }
 fmt.Println("适配结果：", v.Kind(), v.ExactString())
}

根据接口约定，循环前两项都是 int 输入，Kind 应为 Unknown；第三项动态类型为 int64，Kind 应为 Int。适配函数将 int 明确转换后，返回整数常量。这里的判断来自输入类型与文档规则，不把说明图当成运行证据。

拒绝盲目转换反例

不要把所有整数都先强制转成 int64。int 能以 int64 表示，但 uint64 的较大值超出 int64 上限；无符号输入直接使用 MakeUint64 可以保留其数值语义。遇到 float64 也不应为了“变成常量”就截断为整数，应先确定业务究竟需要浮点值还是整数值。

自定义定义类型与其底层类型也要区分。如果业务允许某个定义为 int 的领域类型参与转换，就在自己的适配层明确接纳并转换；不要假设接口中的动态类型已经变成内置 int64。类型别名与新定义类型的规则不同，排查时先确认实际声明。

业务判断清单

转换前确认动态类型、符号与范围；转换后确认 Kind；需要“构造失败即终止”的业务，在自己的适配函数中返回错误。Unknown 是有效的常量状态对象，不是 nil，也不是数值零。后续许多常量运算会传播 Unknown，把它留到最后才处理，会使问题离输入位置越来越远。

只处理一种固定整数类型的函数，直接选专用构造器更容易阅读。确实需要混合支持多种 Make 原生输入类型时，Make 才能减少分支。选择取决于输入契约，不应仅仅因为函数名较短就统一调用。

为什么 constant.Make(37) 也未知？

整数文字传给接口参数时默认成为 int，而 Make 支持的是 int64。用 MakeInt64(37) 或显式 int64 参数即可表达所需类型。

Unknown 是否意味着整数溢出？

在本文的 int 输入场景中，原因是输入类型不受 Make 支持，并不能据此得出数值溢出的结论。

能否用 ToInt 补救？

ToInt 处理已经存在的常量值，不负责恢复 Make 丢弃的原始动态输入。应回到原输入选择正确的构造方法。

参考：Go 官方 Make 输入约定、MakeInt64、MakeUint64。