用 map[string]struct{} 实现 o(1) 白名单检查最高效，空结构体零内存开销且语义清晰；白名单极小时（≤5项）优先用 switch-case，go 会优化为跳转表，性能更优。
用 map[string]struct{} 实现 O(1) 白名单检查
直接用 map[string]struct{} 预存白名单，比遍历 slice 或调用 strings.Contains 快得多，且内存开销极小。Go 中空结构体 struct{} 占 0 字节，仅作存在性标记。
常见错误是误用 map[string]bool —— 虽然也能用，但语义上不如 struct{} 清晰（你只关心“在不在”，不关心“true/false”值），且多占 1 字节/键（取决于对齐）。
实操建议：
- 白名单固定或极少变动时，定义为包级变量，用
var validTypes = map[string]struct{}{"json": {}, "xml": {}, "yaml": {}} - 检查逻辑统一写成
_, ok := validTypes[input]，避免写成validTypes[input] == true（后者在map[string]struct{}下编译不过） - 如果白名单来自配置文件或环境变量，务必在初始化阶段完成 map 构建，不要在热路径里重复解析
当白名单很小（≤5 项）时，考虑 switch-case 替代 map
对于极小集合，CPU 分支预测器往往比哈希查找更高效，且避免了 map 的内存分配和哈希计算开销。
典型场景：HTTP Content-Type 的有限枚举、API 版本标识（如 v1、v2）、状态码字符串别名（"success"、"error"）。
实操建议：
- 用
switch input { case "a", "b", "c": return true; default: return false }，Go 会优化为跳转表或序列比较 - 注意
switch是精确匹配，不支持前缀或正则；若需模糊匹配（如"text/*"），仍应回退到 map + 自定义逻辑 - 别为了“看起来统一”硬套 map ——
len(validList) 时，<code>switch更快也更易读
警惕大小写与空白字符导致的误判
白名单检查失败，十次有八次是因为输入字符串带首尾空格、大小写不一致，或用了全角字符。
常见错误现象：validTypes["JSON"] 返回 false，但用户传的是 "json " 或 "Json"。
实操建议：
- 明确约定：白名单 key 统一小写（或大写），并在检查前统一 normalize 输入 —— 用
strings.TrimSpace(strings.ToLower(input)) - 避免在 map 构建时做
strings.ToLower(k)，而应在检查入口统一处理，否则容易漏掉原始 key 的校验逻辑 - 如果业务允许宽松匹配（如忽略空格、换行符），用
strings.FieldsFunc(input, unicode.IsSpace)拆分后取首项，再 trim
需要动态增删白名单？小心并发安全
运行时修改白名单很常见（比如插件热加载、权限规则更新），但 map 默认不是 goroutine-safe 的。
错误做法：多个 goroutine 直接读写同一 map，触发 fatal error: concurrent map read and map write。
实操建议：
- 读多写少场景，优先用
sync.RWMutex包裹 map，读操作用RLock()，写操作用Lock() - 若写操作频繁，考虑用
sync.Map，但注意它不支持遍历全部 key，且接口是Load/Store/Delete，不能直接用_, ok := m[key] - 更稳妥的做法：用不可变 map + 原子指针替换 —— 新 map 构建完毕后，用
atomic.StorePointer替换旧指针，读侧始终 atomic.LoadPointer 后断言类型
白名单逻辑看着简单，真正上线后出问题的，往往卡在大小写归一化没做全、并发写 map 没加锁、或者把 map[string]struct{} 误写成 map[string]bool 还死活想不通为啥编译报错。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
