应按业务定义“无效项”并显式检查字段，如id非0、name非空等；避免reflect.deepequal或通用清空函数；多字段时实现isvalid()方法；过滤切片优先原地覆盖；指针/切片/时间等需特殊判断；validator库适用于输入校验而非清洗。
怎么判断结构体字段是否为空值
Go 里没有内置的“结构体是否为空”判定，reflect.DeepEqual 虽然能比对，但开销大、不适用于嵌套或含指针/函数字段的结构体。更实际的做法是：**按业务定义“无效项”**——比如 ID 为 0、Name 为空字符串、CreatedAt 为零时间等。不要试图写一个通用“清空结构体”的函数，它要么漏判，要么误删。
常见错误现象：if reflect.ValueOf(item).IsNil() 对非指针结构体 panic；item == MyStruct{} 在含 slice/map/chan 字段时编译失败。
- 优先用显式字段检查，例如：
item.ID != 0 && item.Name != "" - 若字段多，可为结构体实现
IsValid()方法，返回bool - 避免依赖
reflect.Zero(reflect.TypeOf(item)).Interface()做默认值比对——类型不匹配或含未导出字段时行为不可靠
如何高效过滤切片而不分配新底层数组
用 for + 索引原地覆盖是最省内存的方式，尤其当有效项占比高时。新建切片（如 make([]T, 0, len(src))）虽简洁，但若后续频繁追加，可能触发多次扩容。
示例（原地清洗）：
func CleanItems(items []User) []User {
w := 0
for _, item := range items {
if item.IsValid() { // 或手动判断逻辑
items[w] = item
w++
}
}
return items[:w]
}
- 注意：该函数会修改原切片内容（但不改变其底层数组引用），调用方需确认是否可接受
- 若需保留原切片不变，必须新建切片并预估容量：
result := make([]User, 0, len(items)) - 不要用
append在循环里反复调用——即使预分配了容量，append内部仍要做长度检查，原地覆盖更直接
处理含指针或嵌套结构体的边界情况
当结构体字段是 *string、[]int 或另一个结构体时，“空值”含义更复杂。比如 *string 为 nil 不等于空字符串；Time 字段为零值 time.Time{} 可能是无效时间，但也可能是合法的 Unix 零时。
-
*string类型：先判item.Name != nil && *item.Name != "" -
[]int类型：用len(item.Numbers) > 0，而非item.Numbers != nil（空 slice 不为 nil） - 嵌套结构体：逐层判断，或让嵌套类型也实现
IsValid()并复用 - 时间字段：用
!item.CreatedAt.IsZero()，而不是item.CreatedAt != time.Time{}（后者在 Go 1.20+ 可能因内部表示变化失效）
为什么不用第三方库如 go-playground/validator
validator 适合表单校验，但清洗切片时引入它往往得不偿失：你需要为每个结构体打 tag、注册验证器、处理错误，而清洗函数通常只需布尔判断。除非你 already 在项目中重度使用 validator 且规则统一，否则直接写几行条件更轻量、更可控。
容易踩的坑：validate.Struct(item) 返回 error，但清洗场景不需要错误细节，只关心“留还是删”。硬套会导致代码臃肿，且 validator 默认把零值字段当作无效——这和业务语义常不一致（比如 Status 字段允许为 0 表示“待处理”）。
真正需要 validator 的场景是：输入校验 + 错误提示；清洗场景的核心是明确的布尔逻辑，别让它变重。
字段有效性永远由业务决定，不是语言或库替你定的。写清楚 IsValid() 或内联条件，比任何泛型抽象都可靠。
