Go反射FieldByName对非导出字段返回零值而非报错，因仅能访问首字母大写的导出字段；Set需可寻址值故须传指针；循环依赖需手动检测路径；性能瓶颈在于重复反射调用，应缓存元数据并优先用字段索引。
反射获取结构体字段时，FieldByName 返回零值？
不是字段不存在，而是字段未导出（首字母小写）。Go 反射只能访问导出字段，FieldByName 对非导出字段直接返回无效值（
reflect.Value{}<code>），不会报错，极易误判为“字段不存在”。</p>
<ul>
<li>检查字段名是否拼写正确，且首字母大写（如 <code>DB 而非 db）
NumField() + Field(i) 遍历所有字段，打印 Field(i).Name 和 Field(i).IsExported() 确认可见性json: 或自定义如 inject:"db"）配合 Tag 解析，而非靠名字匹配用 reflect.Value.Set() 给结构体字段赋值失败？
常见错误是传入了非地址的 reflect.Value —— Set 要求目标值本身可寻址（即由指针反射而来）。直接对结构体实例调用 reflect.ValueOf(s) 得到的是不可寻址副本，Set 会 panic：reflect: reflect.Value.Set using unaddressable value。
- 务必传入指针：用
reflect.ValueOf(&s)，再调用.Elem()获取结构体本身（仍可寻址） - 给字段赋值前，先
field := v.FieldByName("DB")，再确认field.CanSet() == true - 如果字段类型是接口（如
io.Writer），要确保注入值实现了该接口，且用reflect.ValueOf(dep)包裹后Set，不能直接SetInt等
依赖注入容器初始化时循环引用崩溃？
两个结构体互相声明对方为字段（A 依赖 B，B 依赖 A），反射递归构建时会无限深入，最终栈溢出或陷入死循环。Go 没有内置依赖图检测，全靠手动控制。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 在注册依赖时记录类型路径（如
[]reflect.Type{A, B, A}），每次递归前检查是否重复出现 - 对每个待构建类型维护一个
map[reflect.Type]bool表示“正在构建中”，发现重入立即返回 error - 避免在构造函数（
func() interface{}）里直接 new 依赖项；改为延迟获取（如用func() *DB代替*DB） - 生产级 IoC（如
dig、fwire）用 DAG 拓扑排序解决此问题，手写建议只处理单向依赖
反射注入后性能比硬编码慢 10 倍以上？
不是反射本身慢，而是高频路径反复调用 reflect.TypeOf、reflect.ValueOf、FieldByName。每次调用都涉及运行时类型查找和内存分配。
立即学习“go语言免费学习笔记（深入）”；
- 把反射元数据缓存起来：用
sync.Map存reflect.Type → []injectFieldInfo，首次解析后复用 - 字段索引（
Field(0)）比名字查找（FieldByName）快 3–5 倍，若字段顺序稳定，优先用索引+标签定位 - 避免在请求处理循环里做反射注入；IoC 容器应在启动时完成构建，运行时只取已实例化的对象
- 注意
interface{}到具体类型的断言开销，注入后尽量保持类型明确，减少后续v.Interface().(*DB)这类操作
真正难的不是让反射跑起来，而是控制它不越界——字段可见性、地址合法性、依赖拓扑、缓存粒度，每一步漏掉检查，都会在某个深夜的 panic 日志里精准复现。
