Go要求所有类型转换必须显式声明，如int64(x)、string(b)，整型互转不检查溢出，字符串与数字互转须用strconv包，interface{}转具体类型需用类型断言s, ok := v.(string)，unsafe.Pointer转换极危险且应避免。
Go里不能隐式转换，必须显式写类型名
Go语言不支持像Python或JavaScript那样的自动类型推导转换，比如int和int64之间、string和[]byte之间，编译器会直接报错。这不是语法糖缺失，而是设计上强制你明确表达“我清楚这个转换的语义和风险”。
最基础的写法就是用目标类型作为函数调用： int64(x)、string(b)、[]byte(s)。注意这不是函数调用，而是类型转换表达式——没有括号包裹参数列表，只有单个值。
-
int64(42)合法，int64("42")编译失败（字符串不能直接转整型） -
string([]byte{97, 98})得到"ab"；但[]byte("中文")是合法的，结果是UTF-8字节序列 - 不同宽度的整型互转（如
int→int32）不会检查溢出，截断发生时不报错也不警告
字符串和数字互转要用 strconv 包，不是 type()
把"123"变成int，或者把42变成"42"，不能用int("123")或string(42)——后者实际得到的是Unicode码点为42的字符（即"*"），完全不是你想要的。
必须用strconv包里的函数：
立即学习“go语言免费学习笔记（深入）”；
-
strconv.Atoi("123")→(123, nil)，返回int和error -
strconv.ParseInt("123", 10, 64)→ 更细粒度控制进制和位宽，返回int64 -
strconv.Itoa(42)→ 最快的int转string方式（只支持int） -
strconv.FormatInt(int64(42), 10)→ 支持任意int64和进制
别漏掉错误检查。很多线上panic就来自忘记处理strconv.Atoi返回的error。
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
interface{} 转具体类型要类型断言，不是强制转换
当你从map、函数返回值或interface{}变量中取出一个值，想当string用，不能写string(v)——那会触发运行时panic（如果v实际不是string）。
必须用类型断言：v.(string)（带panic风险）或更安全的双值形式：s, ok := v.(string)。
- 单值断言
v.(string)：如果v不是string，程序立即崩溃 - 双值断言
s, ok := v.(string)：安全，ok为false时s是string零值（空字符串），可继续分支处理 - 对
nil做断言：如果v是nil（且原类型是接口），v.(string)会panic；v.(*MyStruct)在v == nil时不会panic，但结果是nil指针
unsafe.Pointer 转换极危险，除非你真懂内存布局
用unsafe包绕过类型系统，比如把*[]byte转成*string来避免拷贝，这种操作在标准库内部存在（如strings.Builder），但业务代码中几乎不该出现。
它绕过了Go的内存安全机制，一旦底层结构变化（比如Go 1.22调整了string头结构字段顺序）、或跨平台编译（GOOS/GOARCH不同），行为就不可预测。
- 不要为了省几个字节分配而用
unsafe，GC优化和逃逸分析已经让多数场景开销可控 - 如果非用不可，确保两端类型大小一致、对齐方式兼容，并加充分注释说明为什么这里值得冒险
- CI里建议禁用
unsafe导入，或至少用//go:build !unsafe隔离
类型转换在Go里从来不是“怎么写”的问题，而是“为什么必须这么写”的问题。每个转换背后都对应着内存表示、语义承诺或运行时约束，跳过理解直接套用模板，迟早会在边界 case 上栽跟头。
