Go 不允许 map[string]T 直接转为 map[string]Interface，因二者类型签名不同、内存布局各异；必须手动遍历赋值或直接构造目标 map。
为什么 map[string]T 不能直接转成 map[string]Interface
因为 Go 的类型系统不认为它们是同一类型，哪怕 T 实现了那个 Interface。编译器看到的是两个完全独立的类型签名：map[string]T 和 map[string]Interface，内存布局、哈希计算、键值对存储方式都不同。
常见错误现象：
cannot use items (type map[string]baz) as type map[string]foo- 试图用
interface{}中间层强制转换，结果 panic：“invalid type assertion”
正确做法只有两种：
- 手动遍历原 map，逐个赋值到新 map：
newMap[k] = interface{}(v).(foo)（需确保 v 确实实现了 foo） - 直接构造目标类型 map：
items := make(map[string]foo); items["a"] = baz{}
别指望编译器帮你做结构体层面的批量转换——它连 slice 都不许 []T → []interface{}，更别说 map。
立即学习“go语言免费学习笔记（深入）”；
接口转换的本质是 itab 查表，不是数据拷贝
当你写 var w Writer = &File{}，Go 并没把 File 数据复制一遍，而是填了一个 iface 结构：一个指针指向 itab（含接口类型 + 具体类型 + 方法地址），另一个指针指向原始 File 实例内存地址。
所以接口转换（比如从 interface{} 转成具体接口）实际调用的是 convI2I 函数，核心逻辑是：
- 查全局
itab哈希表，看<interface></interface>这个组合是否已缓存 - 没命中就动态生成并插入哈希表（带锁）
- 只更新
iface.tab，data指针复用原值
这意味着：接口转换开销主要在首次查表，后续基本是零成本；但频繁跨包、跨模块做接口断言，可能触发大量 itab 构建，影响初始化性能。
类型断言失败时 panic 还是返回 false？取决于写法
这是线上最易踩的坑之一。写法不同，行为天差地别：
-
v := i.(Writer)—— 断言失败直接 panic，适合你 100% 确认类型时 -
v, ok := i.(Writer)—— 安全断言，失败时ok == false，v是Writer的零值（如 nil 指针）
特别注意：interface{} 到空接口的断言永远成功（因为所有类型都实现它），但反过来不行；而 nil 接口变量做断言时，ok 是 false，但不会 panic。
别在循环里无脑用第一种写法——一次意外的 nil 或错类型，整个 goroutine 就崩了。
空接口 interface{} 和非空接口 iface 的内存布局差异
interface{} 是 eface，只存两字段：_type* 和 data unsafe.Pointer；而非空接口是 iface，多一层 tab *itab，里面还带方法表指针数组。
这意味着：
- 传
interface{}比传io.Reader少一次指针跳转，理论上更快（但差别微乎其微） - 如果函数参数是
interface{}，你无法直接调用任何方法，必须先断言成具体接口或类型 - 反射操作
reflect.ValueOf(x)底层就是把x包进eface，所以反射本身不改变原始值内存布局
真正影响性能的从来不是接口本身，而是你为绕过类型限制写的那些额外判断、转换、中间 map 构造——这些才是 profiling 里真正该砍掉的部分。
