Go整数除法向零截断，浮点除法存在IEEE 754精度误差；金融等场景应选用decimal或big.Rat，避免float64中间计算。
Go 语言里除法精度丢失不是“能不能避免”的问题，而是“用什么场景选什么方案”的问题。直接用 float64 做除法再四舍五入，表面看能凑合，但金融、ID 分片、对账等场景下，一次误差就可能引发连锁问题。
int / int 为什么结果不对？
Go 的整数除法永远向零截断，不保留小数，也不四舍五入。比如 7 / 3 得 2，-7 / 3 得 -2。这不是 bug，是语言定义——但它常被误认为“该有小数”。如果你写了 slope := q / w，而 q 和 w 都是 int，那从第一步起就丢掉了全部小数信息。
- 必须显式转成浮点：用
float64(q) / float64(w)才触发浮点除法 - 别依赖变量名暗示类型，
slope是int类型，再像数学公式也没用 - 除零 panic 在运行时才暴露，
if w == 0检查不能省
float64 除法 + fmt.Printf("%.4f") 能否四舍五入到 4 位？
可以显示上四舍五入，但只是“展示层”处理，底层值仍是 IEEE 754 近似值。例如 190.0 / 13.0 真实结果在 float64 中无法精确表示，fmt.Printf("%.4f", 190.0/13.0) 输出 14.6154 是格式化做的舍入，不是计算过程可控的精度。
-
fmt.Printf("%.4f", x)是输出控制，不影响x本身精度 - 后续若拿这个
x再做加减乘除，误差会累积 - 对非科学计算（如金额、计费、分桶）不推荐此法
需要真精度时该用什么？
取决于你的数据来源和业务要求：
立即学习“go语言免费学习笔记（深入）”；
- 如果是十进制小数（如货币、价格、配置比例），用
github.com/shopspring/decimal：它用字符串+整数模拟十进制运算，a.DivRound(b, 4)可控地四舍五入到 4 位小数，无二进制失真 - 如果是分数类精确拆分（如 1 分钱均分 3 份），用
math/big.Rat：以分子/分母形式存，new(big.Rat).Quo(oneCent, big.NewRat(3, 1))结果就是精确的1/300 - 如果只是整数间“向上/向下取整商”，别转浮点——用
int(math.Ceil(float64(a)/float64(b)))不如直接写整数逻辑，比如(a + b - 1) / b实现正数向上取整
最易被忽略的一点：精度问题往往不出现在第一行除法，而出现在“把 float64 当作中间值反复参与后续计算”时。哪怕你只在最后一步 fmt 格式化，只要之前用过 float64 存中间结果，误差就已埋下。真要可靠，就得从第一个操作数开始就选对类型。
