直接用iota定义权限常量会出错，因其生成0、1、2等连续整数而非2的幂次（1、2、4、8…），导致read|write=1与write值冲突，权限判断完全失效；必须用1
为什么直接用 iota 定义权限常量会出错
直接写 Read = iota、Write、Exec，得到的是 0、1、2 —— 这不是位掩码，是普通整数序列。后果立竿见影：Read | Write 算出来是 1，而这个值恰好等于 Write 自身；更糟的是，如果后面还定义了 Timeout = 1，那权限判断就彻底失效。
根本问题在于：位掩码要求每个标志在二进制中只占一位（1、2、4、8…），这样才能保证按位或无损、按位与可精准检测。而 iota 默认只做 +1 递增，不自动满足这个前提。
-
Read = iota→ 值为0，连最低有效位都没设，组合时毫无意义 - 所有位常量必须在同一
const块内声明，且每行只参与一次位移表达式 - 别在同一个块里混入字符串、数字字面量或函数调用，否则下一行
iota重置为0
1 是唯一推荐的位掩码生成方式
这是 Go 社区长期验证过的可靠模式：编译期确定、零开销、类型安全。它不是语法糖，而是明确告诉编译器“我要的是 2 的幂次”。
示例：
const(
Read = 1
<p>第一行显式写出 <code>1</code>，后续行省略但继承同一 <code>iota</code> 上下文，自动推导为 <code>1、<code>1…</code></code></p>
- 若需跳过
0（例如不允许“无权限”状态），开头加_ = iota占位，再接第一个真实常量 - 建议显式加类型，如
type Perm uint8，再定义Read Perm = 1 ，避免跨平台整型宽度差异引发的移位警告或溢出 - 组合必须用
|，判断必须加括号：(perm & Read) != 0；漏括号会因优先级变成perm & (Read == Read)→ 编译失败
什么时候不该用 1 ，而该用 <code>iota + n
当你需要的是连续整数（非位组合）且起始值不是 0 时，比如 HTTP 状态码、星期几、错误分类编号——这时候 iota + 1 或 iota + 100 更自然。
- 从
1开始：const ( A = iota + 1; B; C )→A=1,B=2,C=3 - 跳过某个值（如留空
ERROR）：const ( OK; ERROR; UNKNOWN = iota )→OK=0,ERROR=1,UNKNOWN=2；若想让UNKNOWN=3，得写成UNKNOWN = iota + 1 - 混合使用允许部分常量显式赋值，不影响后续
iota计数，只要没重置块
封装类型 + String() 方法才是生产级写法
裸 int 枚举在日志、调试、API 返回时全是数字，可读性差，也不利于 IDE 自动补全和类型检查。但加得不对，照样踩坑。
- 类型声明必须显式，比如
type Status int，再写Pending Status = iota；否则常量是 untyped int，传参时可能隐式转换失败 -
Switch分支必须覆盖全部已知值，并带defaultfallback，否则未定义值（比如网络传入非法status=99）会返回空字符串，线上排查极难定位 -
String()只影响fmt.Printf("%v")等格式化输出，不影响 JSON 序列化 ——json.Marshal(Status(0))还是输出0；要 JSON 输出字符串，必须额外实现MarshalJSON()方法
位掩码枚举最易被忽略的点是：它本质上是一组独立 bit 位，不是数值序列；一旦混入非位运算逻辑（比如拿 Read 和 Write 做大小比较），就说明设计已偏离初衷。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
