iota 不是枚举关键字，而是编译器预定义的 const 块内从 0 开始逐行递增的常量计数器；需配合自定义类型、显式赋值和 String() 等方法才能安全模拟枚举行为。
为什么 iota 不是枚举关键字，但能模拟枚举行为
iota 本身不是 Go 的枚举类型，Go 甚至没有原生枚举语法。它只是一个编译器预定义的常量计数器，只在 const 块中有效，从 0 开始、每行递增。真正实现“枚举感”的，是配合自定义类型 + const 块 + iota 的组合用法。
常见错误是直接写 const { A, B, C } 然后期望它们自动属于某个类型——这会得到 int 类型，失去类型安全。正确做法是先声明一个命名类型（比如 type Status int），再让常量属于该类型。
- 必须显式将
iota赋值给自定义类型，否则推导为int -
iota在每个const块内独立重置，不同块之间互不影响 - 空行或注释行不会跳过
iota递增（即第 3 行的iota永远是 2）
如何让 iota 从 1 开始或跳过某些值
默认从 0 开始往往不符合业务语义（比如状态码 Pending=1, Running=2）。这时不能靠“跳行”，而要用表达式重置起始值。
示例：让第一个常量为 1，后续自动递增：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
type Phase int
const (
Pending Phase = iota + 1 // iota=0 → 1
Running // iota=1 → 2
Done // iota=2 → 3
)
- 用
iota + N是最常用且清晰的偏移方式 - 想跳过中间值（如预留未来扩展），可显式赋值：
Suspended Phase = 5，之后的iota仍按行号继续（下一行iota=3，但值变成5+1=6？不——iota不受前面显式赋值影响，它只看行序） - 错误写法：
Unknown = iota放在块中间却没加类型，会导致类型不一致
为什么 String() 方法对 iota 枚举很重要
没有 String()，打印 Pending 得到的是数字 1，调试和日志完全不可读。Go 的 fmt 包会自动调用实现了 fmt.Stringer 接口的值的 String() 方法。
必须为自定义类型实现该方法，且注意 switch 分支要覆盖所有常量值，否则运行时 panic：
func (p Phase) String() string {
switch p {
case Pending:
return "Pending"
case Running:
return "Running"
case Done:
return "Done"
}
return "Phase(unknown)"
}
- 漏掉某个 case 会导致返回
"Phase(unknown)"，容易掩盖逻辑错误 - 如果常量值不连续（比如中间插入了
Suspended Phase = 5），switch 必须显式处理，不能依赖“默认范围” - 别在
String()里用fmt.Sprintf递归调自己，会栈溢出
在 HTTP handler 或 JSON API 中使用 iota 枚举的坑
HTTP 响应或 JSON 输出时，常需要把枚举转成字符串（如 {"status": "Running"}），而不是数字。此时仅靠 String() 不够——json.Marshal 默认序列化为数字，除非你额外实现 json.Marshaler。
- 若希望 JSON 输出字符串，必须实现
MarshalJSON()方法，返回[]byte（例如return json.Marshal(p.String())） - 反序列化时，
json.Unmarshal不会自动调用String()，需手动实现UnmarshalJSON()并做字符串匹配 - 别依赖
map[Phase]string做转换，既冗余又易遗漏新增常量；统一收口到方法里更可靠 - 测试时记得覆盖非法字符串输入（如
"InvalidStatus"），确保UnmarshalJSON返回明确错误
类型安全和可读性之间的平衡点就在这里：iota 提供紧凑的数值底层，而方法集决定它对外暴露什么形态。漏掉任意一环，都会在调试或协作时多花半小时。
