反射读取结构体字段权限标签时，必须确保字段导出且调用 Interface() 前检查 CanInterface()；perm 标签值须用双引号包裹、逗号分隔；应预生成权限检查函数避免运行时反射开销，并明确默认行为与递归策略。
反射读取结构体字段权限标签时，reflect.Value.Interface() 会 panic
常见错误是直接对未导出字段调用 Interface()，比如结构体里写了 userID int `perm:"read"`，但 userID 是小写开头 —— 反射无法访问未导出字段，此时 Interface() 抛 panic: reflect: call of reflect.Value.Interface on unexported field。
必须先判断字段是否可导出：field.CanInterface() 或更稳妥地用 field.CanAddr() && field.CanInterface()。不可导出字段只能通过反射的 UnsafeAddr 或绕道方法访问（不推荐），实际权限校验中应只校验导出字段。
- 权限标签只加在导出字段上（首字母大写），否则反射拿不到值
- 若业务强依赖私有字段权限，改用方法封装 + 显式权限检查，别硬怼反射
- 用
structField.Tag.Get("perm")读标签没问题，但读值前务必CanInterface()
用 reflect.StructTag 解析 perm 标签时，空格和引号容易写错
perm:"read,write" 是对的，perm:"read write" 或 perm:read,write（缺引号）会导致 Tag.Get("perm") 返回空字符串 —— StructTag 解析器严格要求双引号包裹，且内部空格会被当分隔符而非值的一部分。
权限值建议统一用逗号分隔、无空格，后续用 strings.Split(tagVal, ",") 拆解。如果要支持带空格的语义（如 "own data"），必须用引号嵌套，但解析逻辑就得升级成类似 Go 原生 tag 的 parser，成本高且易出错，不推荐。
立即学习“go语言免费学习笔记（深入）”；
- 写法必须是
perm:"read,write,delete"，不是perm:read,write - 避免在 tag 值里出现双引号、反斜杠，否则需转义，维护成本陡增
- 校验时建议提前
strings.TrimSpace去首尾空格，防配置手误
反射遍历字段做权限比对，性能差且无法静态检查
每次请求都 reflect.TypeOf(obj) + 遍历字段 + 解析 tag + 字符串比对，CPU 和 GC 压力明显。实测千级 QPS 下，纯反射校验比预生成 map 查找慢 3–5 倍，且所有权限字段名、操作类型全靠字符串匹配，拼错就静默失效。
折中方案是启动时用反射“编译”一次：为每个目标结构体生成一个 func(interface{}, string) bool 权限检查函数，缓存到 sync.Map 里。后续直接调用函数，避开运行时反射开销。
- 禁止在 HTTP handler 内现场反射 —— 提前生成检查器，或用代码生成工具（如
stringer思路） - 权限动作名（如
"read"）建议定义为 const，避免散落字符串 - 字段没打
perm标签？默认行为要明确：是放行、拒绝，还是继承结构体级标签？得写死，别靠反射猜
嵌套结构体或 slice/map 字段的权限递归校验容易漏层级
比如 User 里有个 Profile *UserProfile 字段，你只校验了 User 一级的 perm，但 UserProfile 本身也有敏感字段。反射一层遍历会跳过指针指向的值，reflect.Value.Elem() 前没判 Kind() == reflect.Ptr 就 panic；遇到 map[string]*Detail 更容易直接忽略。
真要递归，必须显式处理 reflect.Ptr、reflect.Slice、reflect.Map、reflect.Struct 四种情况，并设深度限制（比如 ≤3），否则用户传个循环引用结构体直接栈溢出。
- 默认不递归 —— 权限控制粒度优先放在 API 入口或 DTO 层，不在反射里自动穿透
- 若必须递归，用栈代替递归调用，避免爆栈；每层检查前先
CanInterface()和IsValid() - map 的 key 默认不校验权限（通常为 ID），value 才走字段检查逻辑
