Go是一门强类型的静态编译语言，编译期就确定了每个变量的类型。但在不少实际场景里，我们又不得不面对类型不确定的数据，比如函数接收了一个interface{}类型的参数，或者从JSON中解析出来的结果是map[string]interface{}，这时候就需要在运行时判断数据的真实类型。Golang提供了类型断言、type switch和反射三种主要手段来完成这件事，本文将逐一展开讲解它们的用法、原理和适用场景。
一、类型断言：最直接的类型判断方式
类型断言是Go中最基础也是最常用的类型判断手段。它的语法形式是x.(T)，意思是断言接口变量x的动态类型就是T。类型断言有两种写法，第一种是直接赋值形式：
var i interface{} = "hello"
// 第一种写法：单返回值形式，如果类型不匹配会直接panic
s := i.(string)
fmt.Println(s) // 输出 hello
// 下面的写法会触发panic，因为i的实际类型是string而不是int
// n := i.(int)
第一种写法的风险很明显：一旦断言失败，程序会立即panic。在生产环境中，这种写法是相当危险的，尤其当数据来源是外部输入时，几乎等于埋了一颗地雷。因此更推荐使用第二种写法，即带ok的comma-ok模式：
var i interface{} = "hello"
// 第二种写法：comma-ok模式，断言失败时ok为false，不会panic
s, ok := i.(string)
if ok {
fmt.Println("是字符串，值为：", s)
} else {
fmt.Println("不是字符串")
}
// 多类型依次判断的常见写法
if s, ok := i.(string); ok {
fmt.Println(s)
} else if n, ok := i.(int); ok {
fmt.Println(n)
} else {
fmt.Println("未知类型")
}
comma-ok模式让断言失败变成一个可控的分支，而不是让整个程序崩溃。这里有一个容易被新手忽略的细节：如果断言的目标是接口类型而不是具体类型，那么断言判断的是x是否实现了该接口，而不是底层具体类型是否等于该接口。这个特性在设计插件式架构时非常有用，比如判断某个对象是否实现了error接口或某个自定义接口。
二、type switch：多类型分支判断的最佳选择
当需要对同一个值判断多种可能的类型时，连续写多个if-else会让代码变得冗长难读。Go专门为此提供了type switch语法，它看起来像switch语句，但case里写的是类型：
func describe(i interface{}) {
switch v := i.(type) {
case nil:
fmt.Println("值为nil")
case int:
fmt.Println("整数：", v)
case float64:
fmt.Println("浮点数：", v)
case string:
fmt.Println("字符串，长度：", len(v))
case []interface{}:
fmt.Println("切片，元素个数：", len(v))
case map[string]interface{}:
fmt.Println("映射，键个数：", len(v))
case error:
fmt.Println("错误接口实现：", v.Error())
default:
fmt.Printf("未处理的类型：%T\n", v)
}
}
type switch有几个值得注意的语法特点。首先，赋值语句v := i.(type)中关键字是type而不是具体类型，这是固定写法。其次，在每个case分支内，v会被自动识别为该case对应的类型，不需要再做一次断言，比如在case int分支里可以直接对v做算术运算。最后，case可以写接口类型，匹配时会判断底层值是否实现了该接口，多个类型还可以合并在一个case里，此时v保持接口类型。
type switch在处理JSON解析结果时特别实用。标准库的encoding/json把未知结构的JSON解析到interface{}后，数字统一变成float64，字符串是string，数组是[]interface{}，对象是map[string]interface{}，用type switch可以清晰地覆盖所有情况。此外，type switch底层由编译器直接支持，性能比反射好得多，在能满足需求的条件下应优先使用它。
三、反射reflect包：应对更复杂的运行时类型操作
类型断言和type switch都有一个前提：你必须提前知道可能出现的类型。如果连有哪些类型都无法枚举，或者需要动态获取结构体字段、动态调用方法，就要用到反射包reflect了。反射的核心入口是两个函数：reflect.TypeOf获取动态类型，reflect.ValueOf获取运行时的值：
package main
import (
"fmt"
"reflect"
)
type User struct {
Name string `json:"name"`
Age int `json:"age"`
Email string `json:"email"`
}
func inspect(v interface{}) {
t := reflect.TypeOf(v)
val := reflect.ValueOf(v)
// 判断种类，Kind表示底层的类型类别
if t.Kind() == reflect.Struct {
for i := 0; i < t.NumField(); i++ {
field := t.Field(i)
fv := val.Field(i)
fmt.Printf("字段名：%s，类型：%s，json标签：%s，值：%v\n",
field.Name, field.Type, field.Tag.Get("json"), fv)
}
}
}
func main() {
inspect(User{Name: "张三", Age: 28, Email: "zhangsan@ipipp.com"})
}
使用反射时要分清两个概念：Type和Kind。Type表示完整的类型信息，比如main.User；而Kind表示底层的类型类别，比如结构体的Kind是reflect.Struct，自定义的type MyInt int的Type是main.MyInt，但Kind仍然是reflect.Int。很多反射代码的bug都源于混淆了这两者，比如想判断自定义整型时用Type == reflect.TypeOf(0)就会失败，正确做法是用Kind() == reflect.Int。
反射还常用于通用校验和零值检查。通过Value.IsZero()可以判断任意类型的值是否为零值，通过Value.Kind()配合递归可以遍历任意嵌套的数据结构。需要注意反射不能获取未导出字段的值，强行访问会panic，这一点在处理第三方结构体时要格外小心。
四、三种方式的对比与选型建议
三种方式各有定位，简单总结如下表：
| 方式 | 适用场景 | 性能 | 是否需要预知类型 |
|---|---|---|---|
| 类型断言 | 判断单一已知类型 | 极高，接近直接访问 | 是 |
| type switch | 枚举有限的多种类型 | 高，编译器优化 | 是 |
| 反射 | 任意类型、动态字段和方法操作 | 较低，有装箱和运行时开销 | 否 |
从性能角度看，类型断言和type switch的开销都非常小，type switch甚至会被编译器优化成类似哈希查找或二分比较的机器码，绝大多数业务场景无需担心。反射则明显昂贵，它涉及大量的内存分配和接口转换，在每秒百万级调用的热路径上要谨慎使用。如果确实需要频繁反射，可以考虑缓存reflect.Type结果，或者把反射逻辑放在初始化阶段执行。
选型上可以遵循一个简单原则：能用类型断言就不用type switch，能用type switch就不用反射。比如实现一个通用的ToString函数，先断言几种基础类型，最后用default兜底处理实现fmt.Stringer接口的情况，就没必要一上来就用反射。只有在编写ORM、依赖注入容器、通用序列化框架这类框架级代码时，反射才是必要的工具。
五、常见坑点与最佳实践
第一个坑是断言nil接口。一个接口值实际上由动态类型和动态值两部分组成，当动态类型为nil时接口才等于nil，如果只是动态值为nil而类型不为nil，i == nil会返回false，这是Go最经典的陷阱之一。解决办法是在断言前先检查i == nil，或者用type switch的case nil分支统一处理。
第二个坑是误解map和切片断言的结果。断言i.([]interface{})只能匹配元素类型恰好是interface{}的切片，[]string并不能匹配成功，遇到这种情况只能借助反射的reflect.Value.Kind()配合Index()来处理。第三个坑是go1.18之后的泛型，很多原本依赖interface{}加类型断言的代码可以用泛型改写，编译期就能保证类型安全，能重构的应优先考虑泛型方案。
总结一下：类型断言适合单一类型的快速判断，type switch适合多类型分支，反射适合完全动态的场景。写代码时永远优先使用带ok的断言形式，避免panic扩散到线上；处理反射时严格区分Type和Kind，注意未导出字段的访问限制。掌握了这三板斧，Golang中绝大部分动态类型判断的问题都能从容应对。