关键不是禁用 iota，而是约束其使用边界：仅用于语义清晰的枚举场景（如状态机、HTTP 方法），避免混合类型或条件跳变；每个 const 块专注一类常量，配合自定义类型与 String() 方法提升可读性，并通过文档明确顺序依据。
别让 iota 变成“我它妈看不懂”的缩写——关键不是禁用 iota，而是约束它的使用边界和上下文。
只在语义清晰的枚举场景用 iota
iota 的本意是为一组有明确逻辑顺序、互斥且命名自解释的常量自动编号，比如状态码、协议版本、权限等级。一旦出现“这个值为什么是 3？”“下一个加了会破坏什么？”这类疑问，说明已经超出了 iota 的舒适区。
- ✅ 推荐：状态机（Created, Processing, Done, Failed）
- ✅ 推荐：HTTP 方法（GET, POST, PUT, DELETE）
- ❌ 避免：混合类型（UserID = iota, UserName, UserEmail）——这不是枚举，是字段名误用
- ❌ 避免：带条件跳变（FlagA, _, FlagC）——人为空位破坏可读性，改用显式赋值
禁止跨行隐式依赖和重置滥用
iota 每次出现在新常量块开头时重置为 0，但团队常忽略“块”的边界——比如在同一个文件里多个 const 块连续写，第二个块的 iota 又从 0 开始，容易误以为是延续。
- 每个 const 块只定义一类相关常量，块之间用空行+注释分隔
- 绝不把 iota 和非 iota 常量混在一个块里（如 A = iota, B, C = 100, D）——D 的值难推导
- 需要偏移时，用 Offset = iota + 100，而不是靠空行或注释“跳过前几个”
给 iota 值配有意义的类型和方法
裸 int 值传参或打印时毫无上下文。配合自定义类型和 String() 方法，能让调试日志、错误信息、API 返回立刻可读。
- 定义 type Status int，再用 iota 枚举其值
- 实现 func (s Status) String() string，返回 "Created"/"Failed" 等
- 调用 fmt.Printf("status: %v", s) 就直接输出文字，不暴露数字
- 必要时加 func (s Status) IsValid() bool 拦住非法数值（比如网络传入的未知 status）
文档和审查要盯住“为什么是这个顺序”
iota 本身不表达意图。代码审查时，不要只看语法是否合法，要问：这个顺序是否反映真实业务约束？插入新值会不会影响下游序列化、数据库 schema 或前端映射？
- 在 const 块上方加一行注释，说明排序依据（如 “按故障严重程度升序” 或 “与 gRPC status code 对齐”）
- 如果顺序纯为兼容旧版，明确写 “保留历史顺序，勿调整”
- CI 中可加简单检查：当新增 iota 常量时，触发提醒 PR 作者补全文档或测试覆盖
