StructTag解析失败的主因是标签格式错误或未显式调用Get("csv")；字段须导出、无空格、正确解析omitempty；类型转换需手动处理，指针和默认值逻辑须自定义；性能瓶颈在重复反射操作，应缓存Type和列索引。
为什么 reflect.StructTag 解析失败，字段始终不被识别
反射读取 CSV 行转结构体时，最常见问题不是字段没值，而是压根没进到目标字段——根本原因是 struct 标签写法不合规，或解析逻辑没调用 StructTag.Get("csv")。
Go 的 reflect.StructTag 不会自动识别任意标签名，必须显式提取。比如 `csv:"name"` 不能靠 tag.Get("") 拿到，必须写 tag.Get("csv")；若写成 `csv:"name,omitempty"`，Get("csv") 返回的是完整字符串 "name,omitempty"，得自己切分。
-
csv:后面不能有空格（`csv: "name"`会导致Get返回空） - 字段必须是导出的（首字母大写），否则
reflect.Value.Field(i)拿不到可设置的值 - 如果结构体嵌套，且想支持
csv:"user.name"这类点号路径，反射本身不支持，得手写递归查找逻辑
csv.NewReader 读出来的 []string 怎么安全映射到结构体字段
CSV 行是字符串切片，但结构体字段可能是 int、bool、time.Time，直接赋值会 panic。不能依赖 reflect.Value.Set 自动转换，它只做同类型赋值。
必须在反射外先做类型转换：对每个字段，根据其 reflect.Kind 和 csv tag 提取的原始字符串，调用对应解析函数（如 strconv.Atoi、strconv.ParseBool、time.Parse）。失败时建议跳过该字段或返回错误，别用 panic。
立即学习“go语言免费学习笔记（深入）”；
- 数字类型字段遇到空字符串或非数字，
strconv系列函数返回 error，需检查而非忽略 -
bool字段常见输入是"true"/"false"或"1"/"0"，标准库不处理后者，得自己扩展 - 时间字段强烈建议统一指定 layout（如
csv:"created,2006-01-02 15:04:05"），避免依赖默认解析逻辑
如何让反射工具支持指针字段和零值判断
很多结构体字段是 *string、*int64，甚至 sql.NullString。反射时若原 CSV 值为空，你得决定是设为 nil 还是保持原指针不变。这不能靠 Set 自动推断。
关键在两步：一是用 field.Type.Kind() == reflect.Ptr 判断是否是指针；二是对空字符串，选择调用 reflect.New(field.Type.Elem()) 创建新值并解引用赋值，还是跳过（保留原有指针值）。
- 如果字段是
*string且 CSV 是空串，reflect.Value.SetString会 panic，必须先Elem()再SetString - 结构体字段有默认值（如
Age int `csv:",default=18"`），得在空值时手动注入，反射不读取default这种自定义 tag，要自己解析 -
omitempty在 CSV 场景意义不大（没有“省略字段”概念），它实际影响的是写回 CSV 时是否跳过，不是读取逻辑
性能瓶颈在哪？什么时候该放弃反射
单条记录反射开销约 3–5μs，看似不大，但批量处理 10 万行时，纯反射映射可能比硬编码慢 3–5 倍，主要卡在 reflect.Value.FieldByName 和反复的 Interface() 转换上。
真正拖慢的不是反射本身，而是每次都要重新解析 struct tag、重复新建 reflect.Value、以及大量 interface{} 逃逸。如果你的 CSV schema 固定，且字段数不多（go:generate 或模板）收益明显。
- 字段超过 20 个、吞吐要求 >10k 行/秒，建议缓存
reflect.Type和字段索引映射表，避免每次重扫 - 别在循环内反复调用
reflect.TypeOf(&T{})，提前提取并复用 - 如果 CSV 有 header 行，优先用 map[string]int 建立列名→索引映射，避免按字段名反复查找，比按名字反射快一个数量级
反射不是银弹，它让第一版快速跑通，但上线前得看 p99 延迟——那个 FieldByName 调用，往往就是火焰图里最宽的一格。
