math.floor 返回 float64 是为保持精度一致性并避免整型溢出，不承担类型转换职责，必须显式转为 int 或 int64 且需检查 nan/inf。
Go 的 math.Floor 不是“舍位”，它是严格按数轴方向向下取整，返回 float64；直接赋值给 int 会编译失败，必须显式转换，且负数行为易踩坑。
为什么 math.Floor 返回 float64 而不是 int
Go 类型系统禁止隐式转换，math.Floor 设计上只做数学运算，不承担类型裁剪职责。它返回 float64 是为了保持精度一致性（比如处理极大值如 1e17 + 0.9 时，int 可能溢出，而 float64 还能表示）。常见错误是写成：
var n int = math.Floor(3.9) // 编译错误：cannot convert float64 to int
正确路径只有两步：先 math.Floor，再用 int() 或 int64() 显式转。
- 若原始值确定在
int范围内（≈ ±2.1e9），用int(math.Floor(x)) - 若可能超限（如时间戳毫秒、大金额计算），优先用
int64(math.Floor(x))，并加范围检查：if !math.IsInf(x, 0) && !math.IsNaN(x) && x = math.MinInt64 - 别依赖
int(x)替代math.Floor：它向零截断，int(-2.7)得-2，而math.Floor(-2.7)得-3.0
math.Floor 对负数的处理不符合直觉
它“向下”指朝负无穷方向，不是朝零。所以 math.Floor(-2.3) → -3.0，不是 -2.0。这在分页、索引、坐标格子计算中极易引发越界：
- 分页场景：若
offset = -5，math.Floor(float64(offset)/10)得-1.0，导致查第 -1 页 - 坐标格子：点
(-2.8, 4.3)经math.Floor得(-3.0, 4.0)，对应左下格子索引，这是合理用法；但若误用于“取整显示”，就会把 -2.3 显示成 -3 - 需要“向零取整”时，改用
int(x)或math.Trunc(x)（后者也返回float64）
替代方案：何时不该用 math.Floor
真正需要“舍位到某倍数”（如 Excel 的 FLOOR.PRECISE）或“保留小数位向下截断”，math.Floor 无法直接满足：
- 向下舍入到小数点后两位：用
math.Floor(x*100) / 100，但注意浮点误差累积，1.235 * 100可能是123.49999999999999，math.Floor后得123.0→1.23（错失预期的 1.24） - 安全做法是先用
github.com/shopspring/decimal转为定点数再.Floor()，或用文中提到的Round(val, precision)辅助函数（内部用math.Floor(val*p + 0.5) / p实现四舍五入，非向下） - 整数除法
/在操作数为整型时自动向下取整（-7 / 3→-2），但这属于向零截断，和math.Floor行为不一致，不可混用
最常被忽略的一点：所有 math.Floor 输入都应预先检查 NaN 和 ±Inf，否则结果未定义；生产代码里漏掉 if math.IsNaN(x) || math.IsInf(x, 0) 判断，可能让整个计算流程静默崩坏。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
