Go中整型与浮点型编译期严格分离、不可隐式转换；int系列和byte/rune为整型，float32/float64为浮点型；常量无类型，赋值时才确定类型；混用需显式转换并注意精度与溢出风险。
Go语言中整型和浮点型在编译期就完全分离，类型不兼容、不能隐式转换，写错会直接报错——这不是运行时问题，是编译器立刻拦下的硬性约束。
如何一眼识别变量是整型还是浮点型
看声明或推导出的类型名：int、int8、uint32、int64 等都属于整型；float32、float64 是浮点型。注意：byte 是 uint8 的别名，rune 是 int32 的别名，它们仍是整型。
常见误判点：
-
42是未定类型整数字面量，默认可赋给任意整型变量，但不会变成float64 -
3.14是未定类型浮点数字面量，默认可赋给float32或float64，但无法直接赋给int -
var x = 5→x类型是int（取决于平台，通常是int）；var y = 5.0→y类型是float64
为什么 int + float64 会编译失败
Go 不支持任何数值类型的隐式转换。整型和浮点型属于不同底层表示，编译器拒绝自动桥接。
立即学习“go语言免费学习笔记（深入）”；
必须显式转换，例如：
var a int = 10 var b float64 = 3.14 c := float64(a) + b // ✅ 正确：先转成 float64 // d := a + int(b) // ⚠️ 危险：float64 转 int 会截断小数部分，且 b 可能超出 int 范围
关键提醒：
- 转换方向要符合语义：计数用整型，度量用浮点型，混用前先想清楚精度和范围是否合理
-
int到float64在 64 位整数范围内是精确的；但float64转int会丢失小数，且可能溢出（如float64(math.MaxInt64) + 1转int结果未定义）
函数参数或结构体字段类型选 int 还是 float64？
取决于业务含义，不是“哪个更通用”：
- 索引、长度、计数、状态码 → 必须用整型（
int或带符号/无符号明确位宽的类型，如uint32） - 坐标、温度、权重、比例 → 优先用
float64（除非内存敏感且精度要求低，才考虑float32） - 不要为“以后可能有小数”提前用浮点型存 ID 或版本号——这会导致比较误差、JSON 序列化歧义、数据库映射混乱
一个典型坑：json.Unmarshal 默认把 JSON 数字解析为 float64，如果结构体字段声明为 int，会直接解包失败（json: cannot unmarshal number into Go struct field X of type int）。此时要么改字段为 float64，要么用自定义 UnmarshalJSON 方法处理。
常量与类型推导的边界在哪
Go 的常量是“无类型”的，只在赋值或参与运算时才绑定具体类型。这意味着同一常量在不同上下文可表现为不同数值类型：
const pi = 3.14159265358979323846 var x float32 = pi // ✅ 推导为 float32 var y float64 = pi // ✅ 推导为 float64 // var z int = pi // ❌ 编译错误：cannot convert pi (untyped float constant) to int
但要注意：
- 无类型常量参与运算时，结果仍保持无类型，直到被赋予变量或用于需要具体类型的场景
1 在 32 位系统上可能溢出 <code>int，但作为常量它合法；一旦赋给var n int = 1 ，就可能触发编译错误（取决于 <code>int实际位宽）
真正容易被忽略的是：常量的“无类型”特性只适用于编译期确定的值，对运行时计算（比如函数返回值、变量相加）完全不适用——那些必须严格匹配类型。
