不能靠递归删属性做敏感过滤，因其易漏删、难维护、无法区分字段为空与不该存在、不支持动态权限策略，且会修改原对象引发副作用。

直接递归删除对象属性不是安全的敏感信息过滤方式。它容易漏删、难维护，且无法区分“字段为空”和“字段不该存在”，更无法适配角色权限等动态策略。

为什么不能靠递归删属性做敏感过滤

递归遍历并 delete obj.password 这类操作看似直观，实则隐患重重：

• 运行时无法校验字段是否真的该删——比如 PasswordHash 和 Password 可能同时存在，仅靠字段名匹配会误伤
• 无法处理嵌套结构中的条件逻辑：同一字段在 admin 接口要返回，在 user 接口必须隐藏，递归删属性做不到上下文感知
• delete 操作修改原对象，可能影响后续业务逻辑（如日志记录、缓存写入）
• JSON 序列化前若对象已被部分删除，还可能触发 panic 或空指针（尤其在 nil map 或未初始化 slice 场景）

真正可靠的深度过滤应基于结构体白名单

Go 生态中，最稳的实践是为每个接口定义专属响应 struct，并显式赋值：

• 字段名、类型、是否必填全部由 struct 定义约束，IDE 可跳转，编译器可报错
• 不同角色对应不同 struct，例如 UserPublicResponse 和 UserAdminResponse，天然隔离权限边界
• 敏感字段根本不出现在 struct 中，不存在“删不干净”的问题
• 嵌套结构也一样处理：子结构也用专用 struct，逐层显式构造

需要动态字段控制时，用白名单 map + 显式路径检查

当 API 支持 fields=id,name,profile.email 这类客户端指定字段时，应避免黑名单式递归删除，而采用：

• 预定义合法字段路径白名单（如 map[string]bool{"id":true, "name":true, "profile.email":true}）
• 解析请求参数后，只提取白名单内的路径值，其余一律忽略
• 对嵌套路径（如 profile.email）做分段取值，不依赖反射或通用 delete
• 关键点：所有路径访问都带非空判断，防止 panic；不修改原始数据，只构造新 map

前端侧可配合 JSON.parse reviver 做轻量清洗

如果后端已返回含冗余字段的数据，前端可在解析阶段做二次精简（仅限非敏感场景）：

• 利用 JSON.parse(jsonStr, (k, v) => {...}) 的 reviver 函数
• 自底向上判断：若某个对象只含 parent 字段、child 为空或全无业务字段（如无 id/name），则返回 undefined，自动剔除该节点
• 注意：这仅作为兜底或调试手段，绝不能替代后端的结构化过滤