直接用iota定义权限常量会出错，因其生成0、1、2等连续整数而非2的幂次（1、2、4、8…），导致Read|Write=1与Write值冲突，权限判断完全失效；必须用1<<iota或显式赋值确保每位独立。
为什么直接用 iota 定义权限常量会出错
直接写 Read = iota、Write、Exec 会导致值为 0、1、2，这不是位掩码，是普通整数。后果很直接：Read | Write 得到 1，而这个值恰好等于 Write 自身，更糟的是它还可能和另一个枚举值撞车（比如 Timeout = 1），按位判断完全失效。
根本原因在于位掩码要求每个标志独立且互不干扰，必须是 2 的幂次：1、2、4、8……而 iota 默认只做 +1 递增。
- 错误写法：
Read = iota→ 值为0，连最低有效位都没设，组合时毫无意义 - 正确前提：所有位常量必须在同一
const块内声明，且每行只参与一次位移表达式 - 别在同一个块里混入字符串、数字字面量或函数调用，否则
iota下一行重置为0
1 是唯一推荐的位掩码生成方式
这是 Go 社区长期验证过的可靠模式，不是语法糖，而是编译期确定、零开销、类型安全的写法。
示例：
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
const ( Read = 1 << iota // 1 Write // 2 Execute // 4 Delete // 8 )
- 第一行显式写出
1 ，后续行省略但继承同一 <code>iota上下文，自动推导为1 、<code>1 等 - 若需跳过
0（例如不允许“无权限”状态），开头加_ = iota占位，再接第一个真实常量 - 建议显式加类型，如
type Perm uint8，再定义Read Perm = 1 ，避免跨平台整型宽度差异引发的移位警告或溢出
什么时候该用 iota + n 而不是位移
当你需要连续整数（非位组合）且起始值不是 0 时，比如 HTTP 状态码、星期几、错误分类编号——这时候 iota + 1 或 iota + 100 更自然。
示例：
立即学习“go语言免费学习笔记（深入）”；
const ( StatusContinue = 100 + iota // 100 StatusSwitchingProtocols // 101 StatusProcessing // 102 ) const ( Sun = iota + 1 // 1 Mon // 2 Tue // 3 )
-
iota + n本质是偏移，适合语义上“从 1 开始计数”的场景，避免0和 “未初始化”歧义 - 不要用它定义权限、标志位、协议选项等需按位操作的常量——数值连续反而破坏位独立性
- 如果某组枚举要预留空档（如保留 5–7 给未来扩展），用
_ = iota多写几行跳过，比硬编码更易维护
多个枚举组共存时怎么隔离 iota 计数
iota 在每个新 const 块里自动重置为 0，这是隔离不同枚举组最轻量的方式，不用额外技巧。
错误做法：把状态码、权限、日志等级全塞进一个 const 块里，靠注释分组——iota 不认注释，中间插个字符串就重置，极易错位。
- 正确结构：每个逻辑组单独一个
const块，彼此无关 - 如果组内还要细分（如读权限含
ReadFile、ReadDB），新开一个块，开头可加_ = iota对齐语义，但非必需 - 切忌在块中穿插非
iota表达式，哪怕只是Version = "v1"这种字符串，也会让下一行iota回到0
& 和 | 操作，而不是拿去跟整数比较**。比如 if perm == Read 是错的，正确是 if perm&Read != 0——这和你用没用 iota 无关，但和你是否理解位掩码的本质强相关。 
