math.floor返回float64，需显式转换为int或int64，注意溢出和负数向下取整（如-2.3→-3.0），nan/inf需预先检查，非必要时优先用int()截断。
math.Floor 返回的是 float64，不是 int
很多人调 math.Floor 后直接赋值给 int 变量，结果编译报错：cannot convert float64 to int。它不自动转类型，这是 Go 类型安全的体现，不是 bug。
正确做法是显式转换，但要注意：浮点数可能超出 int 范围（比如 math.Floor(1e20)），直接转会溢出，变成未定义值（通常是负数或 0）。
- 先用
math.Floor得到向下取整后的float64 - 再用
int()或int64()显式转换（选哪个取决于你预期的数值范围） - 如果原始值可能很大（> 9e18），建议先判断是否在
int64范围内，再转
示例：
val := 3.9 floored := math.Floor(val) // → 3.0，类型仍是 float64 n := int(floored) // → 3，安全（因为 3.0 在 int 范围内）
负数的 floor 行为和直觉可能相反
math.Floor(-2.3) 返回 -3.0，不是 -2.0。因为它“向下”指的是数轴方向（更小的方向），不是“往零靠近”。这点和 int(-2.3) 截断不同，也和 Python 的 int() 不同。
如果你要的是“向零取整”（即去掉小数部分），别用 math.Floor，改用类型转换：
-
int(-2.3)→-2（截断，向零） -
math.Floor(-2.3)→-3.0（向下，远离零） -
math.Trunc(-2.3)等价于int()，但返回float64
常见误用场景：计算分页偏移量时传入负 offset，用 math.Floor 会导致越界。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
math.Floor 对 NaN 和 Inf 有明确定义但容易忽略
math.Floor 对特殊值的行为是标准规定的，但实际代码里很少测试这些分支，上线后可能出乎意料：
-
math.Floor(math.NaN())→NaN -
math.Floor(+Inf)→+Inf -
math.Floor(-Inf)→-Inf
如果你的输入来自用户、API 或日志解析，可能混入无效浮点字符串（如 "NaN"），strconv.ParseFloat 会返回 NaN，接着 math.Floor 仍返回 NaN，后续转 int 就变成 0（因为 int(math.NaN()) == 0）。这比 panic 更难排查。
稳妥做法：在调 math.Floor 前加检查：
if math.IsNaN(x) || math.IsInf(x, 0) {
// 按业务逻辑处理：报错 / 默认值 / 跳过
}
性能上没优势，别为了“整数感”硬套
math.Floor 是标准库函数，底层调用 CPU 的 floor 指令，速度很快，但如果你只是想把正数 3.9 变成 3，且确定非负，int(x) 更快、更直观、不依赖 math 包。
只有当你明确需要“数学意义下的向下取整”（尤其涉及负数、边界条件、或与 IEEE 754 标准对齐）时，才该用 math.Floor。
容易被忽略的一点：Go 的 int() 转换对正数和负数行为不一致（截断），而 math.Floor 行为统一（向下），但代价是多一次函数调用 + 类型转换。要不要换，得看你的业务语义是否真需要那个“向下”。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
