用 iota 定义位掩码必须左移或显式赋值，否则得 0,1,2…而非 1,2,4,8…；错误示例 read= iota（0）、write（1）、exec（2）导致 read|write=1 与 exec 冲突；正确做法：read = 1
用 iota 定义位掩码时，必须左移或显式赋值
直接用 iota 会得到连续整数（0,1,2,3…），不是 1,2,4,8…，根本不能当位掩码用。常见错误是写成这样：
const (
Read = iota // 0
Write // 1
Exec // 2
)
结果 Read | Write 是 1，和 Exec 值冲突，逻辑全乱。正确做法只有两种：
- 用位移：
Read = 1 ，后续自动变成 1, 2, 4, 8… - 或显式写死：
Read = 1 、<code>Write = 1 ，但失去 <code>iota的简洁性
const 块里混用 iota 和非 iota 行会重置计数
一旦在 const 块中插入非 iota 表达式（比如普通数字、字符串、函数调用），iota 下一行就从 0 重新开始。这很容易踩坑：
const (
A = 1 << iota // 1
B // 2
C = "hello" // ⚠️ 这行不参与 iota，但导致下一行 iota 重置
D // 0 ← 不是 3！
)
解决方法很实在：
立即学习“go语言免费学习笔记（深入）”；
- 把所有位掩码常量放在一个独立
const块里，不掺杂其他类型值 - 如果真要加说明字段，用注释，别用赋值语句
- 需要分组时，用多个
const块，每个块开头写_ = iota强制对齐（可选）
位掩码常量建议加 uint 类型约束
Go 默认推导整型常量为 int，但在位运算中，int 有符号可能引发隐式转换问题，尤其跨平台（32/64 位）时。比如 1 在 32 位 <code>int 上直接溢出。
更稳妥的做法是统一用无符号类型：
- 定义时加类型：
Read uint = 1 - 或用类型别名封装：
type Perm uint，再让常量属于该类型 - 这样后续做
&、|、^运算时，类型检查更严格，编译器也能更好提示越界
判断是否包含某标志，别用 ==，要用 & 非零判断
新手常写 if perm == Read，这只能匹配“恰好只有 Read”这一种情况，而位掩码的本意是“包含 Read”。正确逻辑是：
if perm & Read != 0 { ... }
这个细节容易被忽略，但影响功能正确性。另外注意：
- 不要写
perm & Read == Read—— 看似等价，但若Read是 0（比如误设None = iota），整个表达式永远为真 - 如果定义了
None = 0，它不该参与位运算逻辑，建议单独处理或干脆不定义 - 组合多个标志时，用
|拼接：Read | Write，而不是加法
位掩码看着简单，但 iota 的计数规则、类型隐含行为、以及按位判断的惯用写法，三者稍一松懈就埋雷。尤其是多人协作时，有人改了常量顺序或加了中间值，整个位逻辑可能悄无声息地坏掉。
