Go中int转int64必须显式转换，因类型间无隐式转换；需用int64(x)并确保值在范围内，跨平台时不可依赖int=int64假设，外部输入须检查溢出，字符串解析优先用strconv.ParseInt(s,10,64)。
int 转 int64 必须显式转换，不能隐式
Go 不允许整数类型之间隐式转换，哪怕只是位宽扩大。写 int64(x) 看似简单，但背后有明确的语义：你确认 x 的值在 int64 表示范围内，且不希望编译器帮你“猜意图”。
常见错误现象：cannot use x (type int) as type int64 in argument to foo —— 这不是 bug，是 Go 在拦你犯错。
- 所有
int到int64（或反向）都必须加括号强制转换，例如int64(x)或int(x64) -
int是平台相关类型：在 64 位系统上通常等价于int64，但代码必须跨平台可移植，不能依赖这个假设 - 如果
x来自外部输入（如 JSON 解析、数据库读取），先检查是否溢出再转，否则可能静默截断
用 strconv 包转换字符串数字时注意类型选择
当你从 string 解析整数（比如配置文件、HTTP 参数），strconv.Atoi 返回 int，而很多标准库函数（如 time.Unix、os.OpenFile 的 flag）要求 int64。这时候别直接套 int64(strconv.Atoi(s)) —— Atoi 本身可能失败，且它返回的是 int，不是你最终要的精度。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 优先用
strconv.ParseInt(s, 10, 64)，它直接返回int64和 error，一步到位 -
strconv.Atoi(s)等价于strconv.ParseInt(s, 10, 0)，其中0表示“用当前平台的int位宽”，结果不可控 - 如果字符串可能超
int64范围（如大时间戳），ParseInt会返回strconv.ErrRange，必须检查 error，不能忽略
和 Cgo 交互时 int/int64 混用会触发 cgo 检查失败
Cgo 接口里，C 的 long 在不同平台可能是 32 或 64 位，而 Go 的 int 也随平台变化。如果你在 C 函数签名里写了 long，却在 Go 侧传 int64，cgo 编译阶段就会报错：cgo: cannot convert int64 to C.long。
立即学习“go语言免费学习笔记（深入）”；
- 对应 C 的
long，应使用C.long类型，而不是硬套int64；需要转换时用C.long(x) - 对应 C 的
int64_t，才该用C.int64_t和int64(C.xxx) - 不要用
unsafe.Pointer(uintptr(unsafe.Pointer(&x)))强转绕过 —— 这会破坏内存对齐或触发 cgo 的 unsafe 检查
性能与逃逸：小整数转换几乎零开销，但别在热路径反复转
int64(x) 是编译期常量折叠或单条 CPU 指令（如 movsxd），没有函数调用、无内存分配、不逃逸。但它不是“免费”的 —— 如果你在循环里把同一个 int 反复转成 int64 再传给函数，编译器未必能完全优化掉冗余转换。
- 转换本身不分配内存，不会导致变量逃逸到堆上
- 但如果转换后立即传给一个接收
interface{}的函数（比如fmt.Println），那值会被装箱，产生接口数据结构 —— 这才是逃逸点，不是转换本身 - 在高频循环中，建议提前转好并复用变量，比如
i64 := int64(i)放在循环外，而非每次写int64(i)
int 行为就可能不一致。别信“我这跑得通”，要测目标环境。 
