go类型安全枚举必须用type t int+const x t = iota实现，因裸const x = iota仅为int常量，允许非法赋值如t(999)；真正安全需编译期类型隔离、运行时isvalid()校验及禁止强制转换。
Go 没有 enum 关键字，但用自定义类型 + const + iota 组合能实现真正可用的类型安全枚举——不是“看起来像”，而是编译器会拦住非法赋值。
为什么 const BlahFoo = 1 不算类型安全枚举
这种写法只是裸 int 常量，和 var x int = 1 没本质区别。它带来的问题很实际：
-
Cluster{a: 999}能编译通过，但 999 根本不是合法状态 - 两个包都定义了
Pending = 0，一个是订单状态，一个是用户状态，混用时毫无提示 - 函数参数是
int，传入任意整数都合法，没法靠类型区分语义
关键不在“有没有枚举名”，而在“类型是否隔离”。必须让 BlahFoo 的类型是 FooEnum，而不是 int。
type FooEnum int + const 块的写法要点
这是最常用也最稳妥的模式，但细节决定是否真安全：
- 必须显式写
BlahFoo FooEnum = iota，不能只写BlahFoo = iota（否则推导为 untyped int） - 如果不想让 0 成为合法值，就别从
iota开始：用BlahFoo FooEnum = 1显式起始，或加个InvalidFoo FooEnum = 0作兜底 - 常量名首字母大写（如
BlahFoo）才可导出；包内私有枚举可用小写blahFoo - 避免在业务逻辑里写
int(BlahFoo)转成普通 int——这等于主动绕过类型检查
运行时校验：IsValid() 和 String() 怎么补位
编译期类型检查拦不住反序列化或用户输入，所以需要运行时兜底：
-
IsValid()方法应覆盖所有合法值：return f == BlahFoo || f == MooFoo，不要用f >= 1 && f 这种范围判断（易漏、难维护） -
String()方法建议用switch分支，而不是 map 查表——map 需要初始化且无法在编译期校验完整性 - 若枚举值来自外部（如 JSON），解码后务必调用
.IsValid()，别依赖json.Unmarshal自动转换（它不会拒绝非法数字）
字符串枚举：什么时候该用 type Role string
当枚举值天然对应固定字符串（如 API 返回的 "admin"、"guest"），且需跨语言/跨协议传输时，string 底层比 int 更直观：
- 定义方式一样：
type Role string+const Admin Role = "admin" - 优势：JSON 直接序列化为字符串，无需额外映射；调试日志直接可见含义
- 代价：内存占用略高；无法做位运算；
==比较性能略低于 int - 注意：仍需
IsValid()校验，因为Role("hacker")是合法语法
类型安全不是一劳永逸的事——FooEnum 类型本身不阻止你赋值非法整数，它只阻止你用裸数字赋值。真正的防护来自组合：编译期类型约束 + 运行时校验 + 团队约定（比如禁止 FooEnum(x) 强制转换）。漏掉任何一环，枚举就只剩名字好听。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
