直接在 handler 里删 map 字段会漏数据，因大小写不一致、嵌套字段无法删除、中间件顺序错位导致敏感字段未清除；应使用专用响应 struct、白名单字段控制及避免 goroutine 共享指针。
为什么直接在 handler 里删 map 字段会漏数据
常见错误是拿到 map[string]interface{} 后手动 delete 某些 key，比如删掉 Password 或 DeletedAt。问题在于：字段名大小写不一致（password vs Password）、嵌套结构（如 User.Profile.Phone）根本删不到、中间件顺序错位导致删早了或删晚了——最后响应里还是漏了敏感字段。
用专用响应 struct 替代反射过滤
Go 的 json: 标签不是安全机制，它只控制序列化行为，不阻止字段被赋值或传递。真正稳的方式是为每个接口定义独立的响应 struct，并显式赋值：
-
UserDetailResponse和UserAdminResponse分开定义，字段名、类型、是否必填全由 struct 约束 - IDE 可跳转、编译器可报错，加字段必须改 struct + handler，不会漏同步
- 避免把数据库模型（如
User）直接传给json.Marshal，这是泄露主因
动态字段控制必须用白名单
当接口支持 ?fields=id,name,email 这类客户端指定字段时，别用黑名单（排除某些字段），而要用白名单校验：
- 预定义允许字段集合：
allowed := map[string]bool{"id": true, "name": true, "email": true} - 遍历 query 参数，只取
allowed[field]为 true 的字段 - 拒绝非法字段直接 400，不静默忽略；否则攻击者可能试探出隐藏字段名
goroutine 间共享数据逃逸是脏数据温床
局部变量天然隔离，但指针、切片、map 一旦跨 goroutine 传递，就变成共享堆数据。典型污染场景：
立即学习“go语言免费学习笔记（深入）”；
- handler 中构造
user := &User{...}，然后传给多个 goroutine 做异步日志或审计，其中一个 goroutine 改了user.PasswordHash - 用
sync.Map存全局缓存时，value 是指针类型，下游 goroutine 直接修改其字段 - 返回结构体指针而非值，导致调用方意外修改原始数据
关键点不在“有没有锁”，而在于“要不要让别人碰这个内存地址”。能传值就别传指针，能拷贝就别共享。
