反射

Go反射是标准库reflect提供的一组运行时API。 它把接口中的动态类型和值表示为reflect.Type与reflect.Value，让代码在不知道具体类型名称时仍能检查结构。 encoding/json一类的包正是靠这项能力读取任意结构体的字段和标签。

静态类型仍然是规则的主体。 编译器能检查具体类型、接口和泛型代码，而反射把一部分检查推迟到运行时。 检查推迟到运行时会增加运行期开销；不适用于当前Kind的反射方法通常会panic，而不是返回错误。

当数据形状只能在运行时得知时，反射才有明确用途。 常见边界包括序列化器、结构体校验器、依赖注入容器、RPC调度器和测试工具。 业务逻辑已经知道类型时，普通字段访问、接口或泛型通常更清楚，也保留更多编译期检查。

反射不是绕过Go可见性和类型规则的后门。 未导出字段不能通过常规反射接口取出为any或修改，赋值也必须满足类型关系。 需要unsafe才能完成的操作不属于reflect的正常用法。

接口值是入口

reflect.TypeOf(input)和reflect.ValueOf(input)都接收any。 传参时，具体值被装入一个 接口值（interface value） ，其中保存动态类型和动态值。 TypeOf读取类型部分，ValueOf则返回一个可检查该动态值的句柄。

Value.Interface()完成反方向的转换，把可导出的有效Value重新装成any。 它返回的静态类型是any，动态类型仍是原类型。 对来自未导出字段的值调用Interface会panic，所以边界代码应先看CanInterface()。

Type与Kind回答不同问题

reflect.Type描述完整类型身份，包括名称、包路径、元素类型、字段和方法。 两个命名类型即使共享同一个 底层类型（underlying type） ，它们的Type仍然不同。 需要判断赋值、转换或接口实现关系时，应使用AssignableTo、ConvertibleTo或Implements。

Kind只给出底层表示的大类，例如Int64、Struct、Slice或Pointer。 自定义的UserID可以有Int64这个Kind，但它并不因此等于int64。 Kind适合选择可调用的方法，不适合代替类型检查。

TypeOf(nil)返回nil，因为空接口中没有动态类型。 如果代码需要在没有值时取得编译期类型，Go 1.22起提供reflect.TypeFor[T]()。 例如，reflect.TypeFor[error]()能直接表示接口类型，不需要构造带nil指针的表达式。

Value同时带有类型与状态

reflect.Value不只有类型和值，还记录有效性、可寻址性、可设置性和可导出性等状态。 ValueOf(nil)返回无效Value；它的IsValid()为false，Kind()为Invalid。 除了少数明确允许的方法外，对无效值继续操作会panic。

种类为Pointer或Interface的值可以用Elem()取得其内容。 但nil指针或nil接口的Elem()会得到无效Value，并非一个可继续解引用的零值。 调用前要先确认当前值有效、种类合适，并按API契约处理nil。

IsNil()也不是通用nil检查。 它只适用于Chan、Func、Interface、Map、Pointer和Slice。 把它用于Struct、Int或无效值会panic，因此必须先根据Kind分支。

修改需要可设置值

ValueOf(record)观察的是装入接口的副本，通常不能用Set修改原变量。 要修改调用方持有的值，应传入非nil指针，再通过Elem()取得所指向的变量。 该变量还必须有合适的类型，并且目标字段必须导出。

CanAddr()与CanSet()不是同一个问题。 可寻址只表示可以取得地址；可设置还受来源和可见性限制。 真正写入前应检查CanSet()，读取为接口前则检查CanInterface()。

Set要求来源值可赋给目标类型。 SetInt、SetString等方法仍要求目标具有兼容Kind，也可能因为溢出策略不符合业务规则而产生错误数据。 边界解析应在进入反射层前完成格式、范围和权限校验。

结构体元数据与方法

结构体的Type提供NumField、Field、FieldByName和VisibleFields等元数据入口。 StructField包含字段名、类型、索引路径、导出状态和 结构体标签（struct tag） 。 标签只是字符串；json、xml或自定义包各自定义其语义。

StructTag.Get无法区分“键不存在”和“键存在但值为空”。 当这一区别会改变行为时，应使用Lookup返回的布尔值。 嵌入字段还可能产生提升或名称冲突，通用库应保存StructField.Index，而不是假设字段都在顶层。

类型的 方法集（method set） 决定反射能找到哪些方法。 T与*T的方法集不同，因此把值传给MethodByName可能找不到只属于指针接收者的方法。 Call还要求参数数量和类型准确匹配，并把被调用函数的panic原样传播出来。

下面四个程序依次加入只读检查、修改、方法调用与nil处理。 第一个只读类型和值，第二个在验证后修改字段，第三个约束动态方法签名，最后一个区分几种容易混淆的nil状态。 每段输出都由本地Go工具链实际运行得到。

读取类型、Kind与标签

Account同时包含命名整数类型、标签和未导出字段。 循环从Type读取字段元数据，再从对应的Value读取内容。 CanInterface让未导出字段留在反射边界内。

ID的完整类型是main.UserID，而Kind是int64。 这正是不能只按Kind判断可赋值性的原因。 未导出字段仍有元数据，但CanInterface()阻止代码把其值暴露为any。

验证后修改字段

SetField接受指针，是因为调用方需要看到修改结果。 它依次验证指针、结构体、字段可设置性和精确赋值关系。 失败路径返回错误，不把reflect的panic当作输入校验机制。

package main

import (
	"fmt"
	"reflect"
)

type Limits struct {
	Host   string
	Port   int
	secret string
}

func SetField(target any, name string, replacement any) error {
	root := reflect.ValueOf(target)
	if root.Kind() != reflect.Pointer || root.IsNil() {
		return fmt.Errorf("target must be a non-nil pointer")
	}
	value := root.Elem()
	if value.Kind() != reflect.Struct {
		return fmt.Errorf("target must point to a struct")
	}
	field := value.FieldByName(name)
	if !field.IsValid() || !field.CanSet() {
		return fmt.Errorf("field %q cannot be set", name)
	}
	next := reflect.ValueOf(replacement)
	if !next.IsValid() || !next.Type().AssignableTo(field.Type()) {
		return fmt.Errorf("%s expects %v, got %T", name, field.Type(), replacement)
	}
	field.Set(next)
	return nil
}

func main() {
	limits := Limits{Host: "api.internal", Port: 8080, secret: "token"}
	fmt.Println(SetField(&limits, "Port", 9090), limits)
	fmt.Println("type:", SetField(&limits, "Host", 42))
	fmt.Println("secret:", SetField(&limits, "secret", "changed"))
}

<nil> {api.internal 9090 token}
type: Host expects string, got int
secret: field "secret" cannot be set

Port通过全部检查，所以写入原结构体。 普通int不能赋给string，而未导出字段即使可寻址也不能设置。 生产代码通常还会用标签建立允许修改的字段清单，避免让外部输入直接选择Go字段名。

约束动态方法调用

动态调度器不能在找到同名方法后立刻调用。 这里的适配器只接受func(string) string这一种签名，并使用TypeFor[string]()做精确比较。 一个更宽的RPC系统还需要认证、参数解码、返回值处理和panic边界。

package main

import (
	"fmt"
	"reflect"
)

type Commands struct{}

func (Commands) Status(orderID string) string {
	return "ready: " + orderID
}

func CallStringMethod(receiver any, name, argument string) (string, error) {
	method := reflect.ValueOf(receiver).MethodByName(name)
	if !method.IsValid() {
		return "", fmt.Errorf("no supported method %q", name)
	}
	typ := method.Type()
	stringType := reflect.TypeFor[string]()
	if typ.NumIn() != 1 || typ.In(0) != stringType ||
		typ.NumOut() != 1 || typ.Out(0) != stringType {
		return "", fmt.Errorf("method %q must have type func(string) string", name)
	}
	output := method.Call([]reflect.Value{reflect.ValueOf(argument)})
	return output[0].String(), nil
}

func main() {
	status, err := CallStringMethod(Commands{}, "Status", "A-104")
	fmt.Println(status, err)
	_, err = CallStringMethod(Commands{}, "Delete", "A-104")
	fmt.Println("missing:", err)
}

ready: A-104 <nil>
missing: no supported method "Delete"

方法值的Type已经绑定接收者，所以NumIn()只计算显式的orderID参数。 不存在的方法返回无效Value，因此先检查IsValid()。 即便签名匹配，被调方法本身仍可能panic；调度边界必须单独决定是否恢复。

区分invalid、typed nil与空切片

空接口、装有nil指针的接口、nil切片和长度为零的非nil切片是四种不同状态。 反射不会把它们折叠成一个“空”概念。 下面的输出显示有效性、Kind、接口比较与IsNil各自回答什么。

package main

import (
	"fmt"
	"reflect"
)

type Problem struct{}

func (*Problem) Error() string { return "problem" }

func main() {
	invalid := reflect.ValueOf(nil)
	fmt.Println("nil interface:", invalid.IsValid(), invalid.Kind())

	var problem *Problem
	var err error = problem
	typedNil := reflect.ValueOf(err)
	fmt.Println("typed nil:", err == nil, typedNil.Kind(), typedNil.IsNil())

	empty := reflect.ValueOf([]string{})
	nilSlice := reflect.ValueOf([]string(nil))
	fmt.Println("empty slice:", empty.IsNil(), empty.Len())
	fmt.Println("nil slice:", nilSlice.IsNil(), nilSlice.Len())
}

nil interface: false invalid
typed nil: false ptr true
empty slice: false 0
nil slice: true 0

err是 带类型的nil（typed nil） ：动态类型为*Problem，动态指针为nil，所以接口本身不等于nil。 两个切片长度都为零，但只有一个切片为nil。 序列化或补丁语义若区分“缺失”与“空集合”，这项差异必须保留下来。

• Go reflect包文档
• Go Blog：The Laws of Reflection
• Go语言规范：类型和值的属性
• Go语言规范：方法集