Go中不能直接用(T)v转换任意类型，仅允许底层表示一致且满足规范的类型转换（如[]byte↔string），类型断言v.(T)仅用于interface{}还原具体类型，unsafe.Pointer需谨慎使用。
Go 里不能直接用 (T)v 转任意类型
Go 没有“类型强制转换”这个概念，只有类型转换（conversion）和类型断言（type assertion），两者语义和使用条件完全不同。硬写 ([]int)(mySlice) 或 (string)(bytes) 会直接编译失败——不是语法错，是类型系统明确禁止。
常见错误现象：cannot convert x (type T1) to type T2；或者更隐蔽的：转完发现数据乱码、长度突变、panic。
- 只有底层表示完全一致、且满足 Go 规范定义的“可转换”关系时，
(T)v才合法（比如[]byte↔string，int32↔int64） -
int和int64之间不能直接转——因为int在 32 位系统是 32 位，在 64 位是 64 位，Go 不保证可移植性 - struct 之间即使字段名/类型全一样，也不能互相转换，必须显式赋值或用第三方库（如
mapstructure）
什么时候必须用 v.(T) 类型断言
只在 interface{} 值需要还原为具体类型时才用，比如从 map[string]interface{} 取值、接收 JSON 解析结果、或处理反射返回值。这不是“转换”，而是“我确定它本来就是 T，帮我拿出来”。
使用场景：HTTP 请求 body 解析后取 data["id"]，它类型是 interface{}，你想当 int64 用。
立即学习“go语言免费学习笔记（深入）”；
在 Go 中使用 google/wire 实现编译时依赖注入——wire.NewSet、wire.Build、wire.Bind（接口→实现）、wire.Struct、wire.Value、wire.Interface
- 安全写法是带 ok 判断：
if id, ok := data["id"].(int64); ok { ... }，否则 panic - 如果原值其实是
float64（JSON 数字默认是 float64），.(int64)会失败，得先转float64再用int64(f) - 嵌套 map 或 slice 时，断言要一层层来，不能
data["items"].([]map[string]interface{})[0]["name"].(string)一气呵成——中间任何一步失败就 panic
unsafe.Pointer 不是类型转换工具，是危险操作开关
有人搜“Go 强制转换”最后翻到 unsafe.Pointer，以为能绕过类型系统。它确实可以，但代价是：失去内存安全、编译器优化失效、跨平台行为不可控，且 Go 1.22+ 对其使用加了更多限制。
典型误用：*(*string)(unsafe.Pointer(&b)) 把 []byte 当 string 解释——这仅在 b 是底层数组连续、未被修改时偶然有效。
- 真正需要它的场景极少：实现高性能序列化、与 C 交互、或写 runtime 级别代码
- 只要涉及
unsafe，就必须写完整注释说明为什么非用不可、对齐要求、生命周期约束 - CI 流程里建议加检查：禁止除特定目录外的任何
unsafe导入
实际项目中该选哪种方式
95% 的需求靠组合标准库函数就能解决，不需要“强制”。关键看数据来源和目标用途。
- JSON → struct：用
json.Unmarshal，别手动断言每个字段 - 数据库 scan → 自定义类型：实现
driver.Valuer和sql.Scanner接口，而不是转 interface{} 再断言 - 数值计算前统一转成明确宽度类型：
int64(v)而不是int(v)，避免 32/64 位差异 - 字符串和字节切片互转：只用
string(b)和[]byte(s)，这是语言唯一保证的“可转换对”，其他都算 hack
最容易被忽略的是：interface{} 值的动态类型在运行时是固定的，你不能“改变它”，只能“解释它”。所谓转换，本质是告诉编译器“请按这个类型去读内存”，而读得对不对，取决于你对数据来源的理解是否准确。
