Go项目里到底该不该用 iota 定义业务状态码？

iota适合定义协议层状态码，如HTTP/gRPC状态码和内部状态机；不适合业务状态码，因其值易变、不可读、跨服务不一致；推荐用字符串或显式赋值常量，并集中管理。

该用，但得用对地方。iota 适合定义固定、有序、无业务含义的枚举型状态码，比如

HTTP 状态码、RPC 错误码这类底层协议层值；但不适合直接定义带业务语义、可能跨服务共享、需长期兼容的业务状态码（如“订单已发货”“退款已驳回”）。

用 iota 的合理场景：协议层/框架层状态码

这类状态码本质是程序内部通信契约，强调唯一性、可预测性和序列性，不承载业务逻辑解释：

• HTTP 状态码常量（http.StatusOK = 200），虽然实际值固定，但用 iota 可避免手写数字出错，也方便批量生成文档或校验
• gRPC 自定义状态码（CodeOK = 0, CodeNotFound = 5），与 gRPC 官方码表对齐，且需在 proto 和 Go 间映射时保持一致性
• 模块内有限状态机的阶段标识（如 StageInit, StageRunning, StageDone），仅用于 switch 控制流，不对外暴露或存库

不该用 iota 的业务状态码场景

一旦状态码要出现在日志、监控、数据库字段、API 响应体、跨语言 SDK 或运营后台中，就该放弃 iota：

• 值易变：业务状态可能新增、合并、废弃（比如“待人工审核”被拆成“初审中”“复审中”），iota 会悄悄改变后续所有值，引发静默错误
• 不可读：看到 OrderStatus(3) 完全无法判断含义，而字符串 "shipped" 或带注释的 const OrderShipped = 1003 更安全
• 跨服务不一致：Java 服务用字符串，Go 用 iota 数字，前端解析时极易错位；统一用字符串或显式命名常量更可靠

折中方案：用 iota 生成，但导出为带名常量

既保留 iota 的防错优势，又规避其隐式序号风险：

const (
    _ = iota
    OrderCreated    // = 1
    OrderPaid       // = 2
    OrderShipped    // = 3
    OrderCancelled  // = 4
)

关键点：

• 首项用 _ = iota 跳过 0，避免无效状态被误用
• 每个常量都写明确注释，说明业务含义和典型使用上下文
• 对外暴露时，优先用常量名而非数值（如 if s == OrderShipped），禁止裸写数字
• 配套提供 String() string 方法和 IsValidOrderStatus(int) 校验函数

更推荐的业务状态码实践

对真正面向业务的状态，建议：

• 用字符串字面量（如 "pending_payment"），天然可读、跨语言、可直接进日志和数据库
• 用显式赋值的整数常量（如 OrderPendingPayment = 1001），值由人定、不依赖顺序、变更可控
• 搭配 map 实现双向转换：map[string]int{"pending_payment": 1001}，兼顾可读性与序列化效率
• 所有状态码集中在一个包里管理，配合单元测试覆盖全部值及转换逻辑