[flags] 特性本身不赋予位运算能力，真正起作用的是每个枚举成员必须是2的幂且显式赋值；否则会导致tostring()异常、parse失败、ef core查询被拉入内存等错误。
直接说结论：[Flags] 特性本身不赋予位运算能力，它只是让 ToString()、序列化和调试器“懂你”——真正起作用的是每个枚举成员必须是 2 的幂（1、2、4、8…），且必须显式赋值；否则组合会歧义、检测会失效、EF Core 查询会崩。
为什么加了 [Flags] 还报错或行为异常？
常见错误现象：明明写了 [Flags]，但 Permission.Read | Permission.Write 打印出来是数字 3，不是 "Read, Write"；或者 Enum.TryParse("Read, Write", out perm) 失败；更糟的是，在 EF Core 的 .Where(x => x.Perms.HasFlag(Permission.Read)) 中整个查询被拉到内存执行。
- 根本原因不是没加特性，而是成员值没按 2 的幂分配 —— 比如写成
Read = 1, Write = 2, Admin = 3，Admin的二进制是0011，和Read | Write完全等价，系统无法区分 - 漏掉
None = 0：会导致default(Permission)不是空状态，perms == Permission.None可能为false，序列化时也容易出空字符串或异常 - 跳着赋值（如
Read = 1, Delete = 4）：中间的2位未定义，ToString()可能输出"1, 4"而非名称，调试器也显示数字
怎么声明一个真正可用的 Flags 枚举？
关键不是语法糖，而是二进制唯一性。必须确保每个成员在二进制中只占一位，且互不重叠。
- 用
1 写法最安全：<code>Read = 1 、<code>Write = 1 、<code>Delete = 1 、<code>Admin = 1 - 必须包含
None = 0—— 它不是可选项，是清空、默认值、序列化起点的基础设施 - 避免十六进制硬编码（如
0x01）除非团队统一规范；十进制1、2、4更直观，也防手误 - 底层类型建议显式指定（如
: uint），避免int负值干扰位操作逻辑
(perms & flag) == flag 为什么比 HasFlag() 强？
这不是风格偏好，是性能、兼容性、语义三重刚需。
-
HasFlag()是反射实现，.NET Core 2.1+ 已标记为“低效”，在循环或高频路径中会明显拖慢 - 在 EF Core 的
IQueryable中调用HasFlag()，表达式树无法翻译成 SQL，触发客户端评估（Client Evaluation）——可能把几万条记录全查出来再过滤 -
(perms & flag) == flag可被 EF Core 直接转成WHERE (perms & 1) = 1，下推到数据库执行 - 注意括号：必须是
(perms & flag) == flag，不是(perms & flag) != 0—— 后者在flag = Permission.None（即0）时恒为true，逻辑错误
从字符串或整数反序列化时容易踩什么坑？
解析环节是非法值最易混入的地方，尤其来自 API 或配置文件。
-
Enum.TryParse<t>("Read, Write", out var p)</t>✅ 安全，支持逗号分隔字符串，自动校验每个名称是否合法 -
Enum.TryParse<t>("3", out var p)</t>⚠️ 危险：它会直接匹配整数值3，不检查这个3是否是合法组合（比如你没定义ReadWrite = 3，但它仍会成功解析并赋值） - 入库前建议加校验：
!Enum.IsDefined(typeof(Permission), value)判断是否为任意合法值（含组合），但注意：它对组合值返回false，所以更适合校验单个成员；组合校验应结合位合法性（所有置位都对应已定义成员） - JSON 序列化默认走字符串模式（如
"Read, Write"），但若字段是int类型或禁用了JsonStringEnumConverter，就会输出数字，丢失语义
最常被忽略的一点：Flags 枚举的“合法性”不在编译期检查，而完全依赖人工定义 —— 编译器不会阻止你写 Admin = 3，但运行时所有位运算都会开始说谎。一旦上线，调试成本远高于初期多敲几个 。
