Go中无强制类型转换，仅支持显式转换；底层表示一致时可用T(v)，如int64(x)、[]byte(s)；string与数字互转必须用strconv包；interface{}取值需用类型断言而非string(v)；unsafe.Pointer应避免在业务代码中使用。
Go 里没有“强制类型转换”这回事——只有显式类型转换，且必须手动写清楚目标类型，编译器绝不帮你猜。
什么时候能直接用 T(v)？
仅当两个类型底层内存表示完全一致、长度相同、且 Go 编译器允许时，才能直接写 int64(x)、string(b)、[]byte(s) 这类转换。
-
int→int32或int64：可以，但不检查溢出；32 位系统上int可能只有 4 字节，转int64没问题，反过来可能丢数据 -
[]byte↔string：可以，string([]byte{97, 98})得"ab"，[]byte("中")得 UTF-8 字节序列（3 字节），但二者共享底层内存的假设不成立——每次转换都拷贝 -
float64→int：可以，但直接截断小数部分（不是四舍五入），int(3.9)是3 -
string→int：❌ 不行！int("123")编译失败；这是常见误判，以为像 Python 那样能“强转”，实际必须走strconv
字符串和数字互转必须用 strconv 包
因为 string 和数字在内存里根本不是同一类东西：一个是字节序列，一个是数值。Go 不允许跨语义层直接解释。
-
string→int：用strconv.Atoi("123")或strconv.ParseInt("123", 10, 64)；后者可指定进制和位宽，前者只支持十进制 int -
int→string：用strconv.Itoa(42)（最简）或strconv.FormatInt(int64(42), 10) -
float64→string：用strconv.FormatFloat(3.14, 'f', 2, 64)，第三个参数控制小数位数（'f'表示定点格式） - 别写
string(42)：它返回的是 Unicode 码点 42 对应的字符，即"*"，不是你想转的数字字符串
从 interface{} 拿值？别用 string(v)，用类型断言
当你从 map、函数返回值或接口变量里取值，想当 string 用，string(v) 不是类型断言，而是“把 v 当 rune/byte 转成单个字符”，运行时 panic 几乎必然发生。
Colly Golang Web Scraper and Crawler Framework
下载
Colly 是一个用于 Go 语言的快速开源爬取和爬虫框架。它适用于从简单的页面提取到异步爬虫处理大量页面集合，支持请求回调和结构化解析。
立即学习“go语言免费学习笔记（深入）”；
- 正确写法是：
s, ok := v.(string)；ok为 false 表示 v 实际不是string，此时不该继续用s - 如果确定 v 一定是
string（比如你刚存进去），可写s := v.(string)，但无保护，panic 风险自负 - 对结构体、自定义类型也一样：
u, ok := v.(*User)，注意是指针还是值类型，别漏了* - 别试图用
string强转interface{}来“绕过类型系统”——那不是转换，是找 panic
别碰 unsafe.Pointer，除非你在写标准库
它不是“高级类型转换工具”，而是绕过整个类型安全机制的紧急出口。业务代码里 99.9% 的所谓“零拷贝需求”，都有更安全替代方案。
-
*(*uint32)(unsafe.Pointer(&data[0]))看似高效，但要求len(data) >= 4、字节序匹配、且data地址对齐；错一点就读垃圾值或 panic - 把
*[]byte强转成*string来避免拷贝？标准库内部有，但你写出来就是技术债：GC 可能提前回收底层数组，导致 string 指向野内存 - 真正该用
unsafe的场景极少：比如高性能网络包解析（且已有binary.Read可用）、或跟 C 交互；日常开发请优先用bytes.Buffer、encoding/binary、reflect
最常被忽略的一点：Go 的类型转换从来不是“告诉编译器怎么解释某个内存块”，而是“创建一个新值”。哪怕 string([]byte) 看似零成本，背后仍是分配+拷贝。想省这点开销，先确认它真是瓶颈，再考虑是否值得用 unsafe ——通常不值。
