Go 类型别名和定义类型怎么区分：cannot use 报错的转换边界

Go 里两行声明看起来只差一个等号，却会直接改变赋值规则：type UserID = int64 是类型别名，type UserID int64 是定义类型。遇到 cannot use 时，先确认自己写的是哪一种，再决定是否需要显式转换。

别名继续使用原类型的身份；定义类型拥有新的类型身份，和原类型之间通常要显式转换。

先看两种声明的差别

第一组变量可以直接互换，第二组即使底层都是 int64，也不再是同一个类型。

type LegacyID = int64
type OrderID int64
var n int64 = 1001
var a LegacyID = n
var b OrderID = OrderID(n)

如果把 var b OrderID = n 写进程序，编译器会提示 cannot use n (variable of type int64) as OrderID value in variable declaration。这不是数值不能表示，而是赋值两端的类型身份不同。

从 cannot use 开始排查

1. 两边是不是同一个类型？ 有等号的别名不会创建新类型；没有等号的 type Name Base 会创建定义类型。
2. 你要的是换名字，还是增加约束？ 兼容旧 API 时考虑别名；订单号、用户号和状态码更适合定义类型。
3. 转换是否安全？ 数值转换可能截断；字符串与整数之间也不要把 string(id) 当作十进制格式化。

两个定义类型即使都以 int64 为基础，也不能直接赋值。调用 loadOrder(OrderID(uid)) 可以通过编译，但这一步应表达调用方确认两个编号在该边界上可以互换。

定义类型带来真正的业务边界

定义类型可以绑定方法，适合把校验规则放到值的边界上：

type OrderID int64
func (id OrderID) Valid() bool { return id > 0 }

这样订单编号不会无意中接受所有 int64 参数。若所有 ID 都声明成基础类型，用户 ID 和订单 ID 互换时编译器没有机会提醒你。

别名适合兼容迁移

包迁移时可以让旧包里的名称指向新包类型：type Config = newpkg.Config。别名不会创建独立的方法集合；需要新的方法、参数身份或领域边界时，应使用定义类型。

三个常见转换坑

类型转换不等于格式化

string(65) 得到的是单个字符，不是 "65"。目标是十进制文本时使用 strconv.FormatInt(65, 10)。

不要因为底层类型相同就随手转换

UserID(orderID) 能编译，不代表业务上合理。跨边界转换最好集中在构造函数、适配器或仓储层。

别名不能掩盖迁移未完成

别名适合过渡。迁移完成后搜索旧名称的引用，逐步移除兼容层。

用最小测试确认判断

type Number = int64
type Count int64
var _ int64 = Number(1)
var _ Count = Count(int64(1))
// var _ Count = int64(1) // 取消注释应触发 cannot use

执行 go test ./... 后，合法赋值应通过；取消注释则稳定复现编译错误。这个测试能防止重构时误把定义类型改成别名，或反过来破坏公共 API 兼容性。

相关问题

类型别名能不能定义新方法？

别名不创建新的类型身份，不能把它当成独立定义类型扩展。需要独立方法时改用定义类型。

定义类型和原类型可以比较吗？

通常需要先转换到同一类型再比较；转换前确认范围和业务语义。

什么时候应该保留 cannot use 报错？

当两个值不应互换时，报错是有价值的保护。修复方式应是调整边界或增加明确转换。

把类型身份和底层表示分开看，Go 的这类编译错误就不再神秘：别名解决命名与兼容，定义类型解决边界与约束，显式转换则应当成为经过确认的业务动作。