在Go语言里，interface{} 可以接收任意类型的值，因此在写通用函数或组装异构数据时经常会出现 []interface{} 切片。一个典型的场景是切片中放了结构体，然后希望通过类型断言拿到结构体并修改某个字段，结果运行后发现原始切片里的数据并没有变化。这个问题的本质不是断言语法错误，而是接口装箱和值拷贝共同作用的结果。

一、为什么直接断言修改结构体字段不生效

要理解这个问题，先要搞清楚 interface{} 在Go里是怎么存储数据的。当你执行 slice = append(slice, Person{Name:"Tom", Age:20}) 时，Person 值会被复制一份放进接口变量。接口内部保存的是原值的副本，而不是引用。此时如果把接口里的数据取出来，无论使用类型断言 p := slice[0].(Person) 还是 p, ok := slice[0].(Person)，得到的 p 都只是另一个Person副本。

在Go中，所有赋值和传参默认都是值传递。对于结构体这种值类型，副本一旦产生，修改副本的字段自然不会反映到原值上。下面这段代码是最容易踩坑的写法：

package main
import "fmt"
type Person struct {
    Name string
    Age  int
}
func main() {
    list := make([]interface{}, 0)
    list = append(list, Person{Name: "Tom", Age: 20})
    if p, ok := list[0].(Person); ok {
        p.Age = 21
    }
    fmt.Println(list[0]) // 输出 {Tom 20}，Age 没有变成 21
}

上面代码里 p 是断言出来的副本，对 p.Age 赋值只是修改了这个临时变量。接口中的 Person 值仍然保持原来的 20。这也解释了为什么很多刚接触Go的开发者会觉得断言后修改好像不生效。

还有一种情况是从接口切片里取元素后取地址，比如 p := &list[0].(Person)，这种写法在Go中同样不能通过编译，因为接口值的动态值不一定可寻址。解决思路主要有两种：要么让接口里存放的内容本身是指针，要么借助反射从切片底层拿到可寻址的值。

二、正确方法一：在 interface{} 切片中存放结构体指针

最直接、性能最好、代码也最容易理解的办法，就是不要让接口保存结构体值，而是保存结构体指针。指针本身是一个可以被复制的地址，无论复制多少次，指向的都是同一块内存。把 *Person 放进 []interface{} 后，断言回 *Person，然后通过指针修改字段，原对象会立刻更新。

下面是使用指针版本的完整示例：

package main
import "fmt"
type Person struct {
    Name string
    Age  int
}
func main() {
    list := make([]interface{}, 0)
    list = append(list, &Person{Name: "Tom", Age: 20})
    if p, ok := list[0].(*Person); ok {
        p.Age = 21
    }
    fmt.Println(list[0].(*Person)) // 输出 &{Tom 21}
}

这里的 &Person{Name: "Tom", Age: 20} 创建了一个 Person 指针，接口保存的是这个指针的值。断言为 *Person 得到的 p 仍然是一个指针副本，但它指向的地址和原对象一致，因此 p.Age = 21 会直接修改堆上那个结构体。即使后面又把同一个指针放进多个 interface{} 变量，修改也会同步。

这种方式适合大多数业务场景，尤其是你能够决定切片元素类型的时候。如果外部传入的切片已经确定为 []interface{}，但里面的元素是值而不是指针，那就要看调用方能否配合调整。若调用方无法修改，只能使用反射方案。

三、正确方法二：使用反射修改切片中的结构体字段

如果函数接收到的确实是一个 []interface{}，且元素是结构体值，反射可以帮我们从底层拿到可寻址的字段。核心思路是先反射拿到切片值，再通过 Index 方法定位到某个元素，然后通过 Elem 或直接使用 Index 返回的可寻址 Value 来修改字段。

不过需要特别注意：[]interface{} 中的元素是接口类型，反射看到的每个元素类型是 interface{}，直接取 Index(0) 得到的是接口的 reflect.Value，并不是具体的结构体 Value。要拿到具体结构体，需要先调用 Interface() 取出接口内容，再对结果做 reflect.ValueOf，但这样得到的仍然可能是不可寻址的副本。真正能修改原切片的前提是：切片本身可寻址，或者传入的是指向切片的指针。

下面这个例子演示了传入 *[]interface{}，通过反射修改切片第一个结构体的 Age 字段：

package main
import (
    "fmt"
    "reflect"
)
type Person struct {
    Name string
    Age  int
}
func modifyAge(listPtr *[]interface{}, index int, newAge int) {
    listValue := reflect.ValueOf(listPtr).Elem() // 拿到切片本身的可寻址Value
    elemValue := listValue.Index(index)          // 下标元素的接口Value
    concreteValue := elemValue.Elem()            // 接口里实际的结构体Value
    if concreteValue.Kind() == reflect.Struct {
        field := concreteValue.FieldByName("Age")
        if field.CanSet() {
            field.SetInt(int64(newAge))
        }
    }
}
func main() {
    list := []interface{}{Person{Name: "Tom", Age: 20}}
    modifyAge(&list, 0, 21)
    fmt.Println(list[0]) // 输出 {Tom 21}
}

这里为什么要传指向切片的指针？因为只有拿到切片的可寻址 Value，Index(0) 返回的元素 Value 才是可寻址的。elemValue 是接口类型的 Value，调用 Elem 得到接口内部具体结构体的 Value，此时 field.CanSet() 才为 true。如果直接对 list 做 reflect.ValueOf(list)，Index(0).Elem() 得到的结构体 Value 仍然是不可寻址的，Set 时会 panic。

反射方案虽然能够解决问题，但代码明显复杂，并且需要处理字段不存在、字段类型不匹配、不可导出字段不能 Set 等情况。如果切片里的元素不是结构体而是指针，反射代码还要再做 Elem 判断。因此建议仅在无法控制调用方类型时使用，并且要做充分的错误处理和单元测试。

四、最佳实践：优先使用具体类型切片，避免过度依赖 interface{}

从工程维护角度说，如果切片元素类型在编译期就能确定，应当直接使用 []Person 或 []*Person，而不是 []interface{}。具体类型切片在遍历和修改字段时不需要类型断言，编译器还能帮助检查字段名是否拼写正确。尤其是当结构体字段较多、调用链较长时，直接修改元素字段的代码会简单很多。

例如定义 []*Person 后，业务代码可以这样写：

package main
import "fmt"
type Person struct {
    Name string
    Age  int
}
func main() {
    list := make([]*Person, 0)
    list = append(list, &Person{Name: "Tom", Age: 20})
    list[0].Age = 21
    fmt.Printf("%+v\n", list[0]) // 输出 &{Name:Tom Age:21}
}

这里不需要断言，也不需要反射，编译器保证 list[0] 是 *Person，修改字段非常直观。即使你需要把 []*Person 传给接收 []interface{} 的函数，接口转换也只会复制指针，不会复制整个结构体。

如果必须使用 []interface{} 承载不同类型的元素，也要尽量往里面放指针而不是值。类型断言失败时用 ok 模式处理，避免 panic。对于已经存在的值类型 []interface{} 数据，若确实需要在原处更新字段，再考虑反射，但应在文档中明确说明原因和限制。

总结一下：接口切片修改结构体字段的关键在于能不能拿到原值的可寻址引用。存指针是首选，反射是兜底，具体类型切片是更稳妥的代码设计。理解Go的值传递和接口装箱规则后，这类问题就能少踩很多坑。