math.floor(math.log10(n)) + 1 在 n≤0 时失效，因 math.log10(0) 返回 -infinity、math.log10(负数) 返回 nan，而位数仅对正整数有定义，故需先校验 n > 0。
用 Math.log10() 算整数位数时，为什么 Math.floor(Math.log10(n)) + 1 在 n=0 或负数时崩了
直接对 0 或负数调用 Math.log10() 会返回 -Infinity 或 NaN，导致后续 Math.floor() 失效。位数定义本身只对正整数有意义，所以必须先做输入过滤。
- 对
n ，应单独返回 <code>1（比如0算 1 位）或抛错，取决于业务需求 - 对浮点数如
99.9，若目标是“整数部分位数”，需先Math.abs(Math.trunc(n))，避免小数干扰 -
Math.log10(100)返回2，Math.floor(2) + 1才得 3——别漏掉+1，这是位数公式的固定偏移
对数缩放时，Math.log10() 和 Math.log() 的结果能混用吗
不能直接混用。缩放本质是把值映射到新量级，底数不同只是线性缩放关系：Math.log10(x) === Math.log(x) / Math.LN10。但如果你硬写成 Math.log(x) * 0.5，和 Math.log10(x) * 0.5 结果差约 2.3 倍（因为 1 / Math.LN10 ≈ 0.434），视觉上就偏了。
- 统一用
Math.log10()最直观：每 +1 表示原值 ×10，符合人类对“数量级”的直觉 - 如果后端返回的是自然对数，前端缩放前先除
Math.LN10对齐，别靠经验系数硬调 - 缩放后常需截断或归一化，例如
Math.min(10, Math.max(1, Math.log10(val) + 1))，避免极端值拉垮图表
处理 1 到 999 这类小范围数据时，对数缩放反而让差异看不清？
对数压缩会把 1→10→100→1000 拉成等距，但 1→2→3 全挤在开头一小段，肉眼难分辨。这不是函数错了，而是对数本身的设计特性。
- 若原始数据跨度小（比如全在
[1, 50]），优先考虑线性缩放或分段处理（如val ） - 加个偏移再取对数可缓解：用
Math.log10(val + 1)避免log10(1)=0导致的堆叠，但会轻微扭曲比例 - 真要保留小值区分度，不如直接用
Math.cbrt()（立方根）或Math.sqrt()，它们压缩更温和
精度问题：为什么 Math.log10(1000) 有时返回 2.9999999999999996
浮点数二进制表示导致的固有误差。1000 在 IEEE 754 中无法精确存储，Math.log10() 输入已是近似值，输出自然带误差。
- 位数计算时，别直接
Math.floor(x)，改用Math.round(x * 1e10) / 1e10预先微调，再Math.floor - 更稳妥的做法是转字符串：
String(Math.abs(n)).replace('.', '').replace('-', '').length，虽慢但绝对可靠 - 缩放用于可视化时，误差
±0.001通常无感；但若用于索引或分桶，必须用Math.round()或阈值判断兜底
对数操作里最易被忽略的，是“输入域”和“用途目标”的匹配——不是所有数字都适合扔进 Math.log10()，也不是所有场景都需要严格数学意义上的对数缩放。
