大厂禁用 iota 复杂表达式因其破坏确定性、可读性与协作安全：隐式递增叠加计算导致值难预测；跨 const 块不复用致数学关系断裂；静态分析难覆盖；新人理解成本高。
因为复杂表达式会放大 iota 的隐式行为，让常量值变得难以预测和维护，违背大厂对代码确定性、可读性与协作安全的硬性要求。
隐式递增 + 复杂计算 = 推理黑洞
iota 本身每行自增 1，但它的值只在“该行被解析为一个常量声明”时才生效。一旦你在某一行写类似 iota * 2 + 1 这样的表达式，值就不再线性可推——尤其当后续行省略赋值（如只写 B）、或混用 _ 占位时，iota 当前行的数值必须靠数“有效常量行”才能确认，而表达式又依赖这个数值做运算。工程师无法一眼看出 B 是多少，得逐行模拟编译器逻辑，极易出错。
跨 const 块不复用，重构时易断裂
每个 const 块内 iota 独立重置为 0。如果一组带复杂表达式的常量被拆分到多个 const 块（比如按功能或权限层级隔离），原本连续的数学关系（如幂次、偏移序列）立刻失效。大厂常见做法是把权限掩码、协议状态码、错误码等分块管理，此时若依赖 iota + 表达式 生成值，一拆就断，且没有编译错误提示，只有运行时行为异常。
静态分析工具难覆盖，CI 检查易漏
Go 的 vet 和 golangci-lint 对 iota 表达式不做深度语义校验。它能发现未使用的常量或类型不匹配，但无法判断 1 是否符合业务预期。大厂的代码扫描流水线通常禁用“不可判定行为”，直接禁止非常规表达式，用显式数字或辅助函数替代，确保所有常量值在源码中“所见即所得”。
新人/跨团队协作成本高
一个 const 块里若出现 FlagA = 1 、FlagB = 1 、_ = iota + 5 混用，三行之间 iota 实际取值分别是 0、1、2，但最终常量值却是 1、16、0——这种跳跃对非原作者几乎不可读。大厂强调“一次写对、长期可懂”，宁可多写两行显式定义，也不接受靠脑补运行的 magic。
