iota不能直接当位掩码用，因其默认从0开始递增得0、1、2…，而非所需的2ⁿ序列；需显式左移如1
为什么 iota 不能直接当位掩码用
因为 iota 默认从 0 开始自增，每次 +1，而位掩码需要的是 1、2、4、8……这种 2 的幂次。直接写 FlagA = iota、FlagB、FlagC，结果是 0、1、2 —— 这根本不是合法的位掩码，按位与/或会互相干扰。
常见错误现象：flagA | flagB == flagC 居然成立（比如 1 | 2 == 3），但你本意是让每个 flag 独立可组合。
- 必须显式左移：
1 才能得到 1、2、4、8… - 如果第一个值要跳过 0（比如不允许“无标志”状态），得重置
iota起始值，例如_ = iota // 忽略 0再接FlagA = 1 - 注意整数溢出风险：32 位系统上
iota超过 31 就会左移溢出，建议统一用uint64或明确限定枚举总数
1 在 const 块里的实际写法
这不是语法糖，是唯一靠谱的位掩码生成模式。关键在 const 块内保持连续声明，且所有位常量共享同一个 iota 上下文。
使用场景：定义 HTTP 方法权限、文件打开标志、协议选项位等需多选组合的场景。
立即学习“go语言免费学习笔记（深入）”；
const (
PermRead = 1 << iota // 1
PermWrite // 2
PermExec // 4
PermAdmin // 8
)参数差异：1 和 <code>1 在 32/64 位平台行为一致，但显式转 <code>uint 可避免某些 linter 报告移位宽度警告；Go 1.19+ 支持 1 这类表达式，但没必要，加法不改变本质。
如何安全支持“全选”和“无选中”两个特殊值
位掩码里，“全选”不是简单把所有 flag 相加，而是对已定义的 flag 做按位或再取反（受限于位宽）；“无选中”通常是 0，但若业务禁止空状态，就得单独定义一个非零占位值。
- 推荐方式：用
AllPerms = PermRead | PermWrite | PermExec | PermAdmin显式列出，比^0更清晰、可读、跨平台安全 - 如果枚举项太多，可用辅助 const 块隔离：
_ = iota; all = ^uint64(0)，但必须确认目标类型宽度，否则^0在 int 上是负数 - 容易踩的坑：把
0当作有效 flag（比如PermNone = 0），然后又用if flags & PermNone判断——这永远为真，逻辑崩溃
当需要带方法的枚举类型时，iota 还够用吗
够用，但必须配合自定义类型和方法绑定。单纯靠 iota 只能生成值，无法自带语义或校验逻辑。
性能影响几乎为零：底层仍是整型，方法调用不增加运行时开销；兼容性良好，只要类型定义不变，序列化（如 JSON）也能正常工作。
type FileMode uint32
const (
ReadMode FileMode = 1 << iota
WriteMode
AppendMode
)
func (f FileMode) String() string {
switch f {
case ReadMode: return "read"
case WriteMode: return "write"
default: return "unknown"
}
}容易被忽略的地方：如果后续新增 flag 但忘了更新 String() 或其他方法，会导致新值返回 "unknown" 却无编译错误——这类逻辑分散在多处，比纯 const 更难维护。
