JavaScript 的 toFixed(2) 不准是因为浮点数二进制表示导致精度丢失，如 1.005.toFixed(2) 返回 "1.00" 而非 "1.01"；应优先用 Math.round(num * 100) / 100 配合 toFixed(2) 补零，确保数值准确后再格式化。
JavaScript 中 toFixed(2) 为什么有时不准
因为 toFixed 基于浮点数二进制表示做舍入，而很多十进制小数（比如 0.1、0.2）在二进制中是无限循环小数。直接对 0.1 + 0.2 调用 toFixed(2) 会得到 "0.30"，看似正常，但对 1.005 调用却可能返回 "1.00" 而非预期的 "1.01"——这是 IEEE 754 精度丢失导致的舍入偏差。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 不要依赖
toFixed做金融类精确四舍五入；它本质是“就近舍入”，且受底层浮点误差影响 - 若只是展示用、误差可接受（如价格预览），
Number(val).toFixed(2)可快速生效，但务必先转Number防字符串误判 - 遇到
1.005.toFixed(2) === "1.00"这种反直觉结果，说明已踩坑，需换方法
更可靠的四舍五入：乘加再除的整数法
绕过浮点运算，把小数放大成整数处理，是稳定取两位小数的核心思路。关键不是“格式化”，而是“先正确计算再格式化”。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 用
Math.round(num * 100) / 100得到数值型结果，再配合.toFixed(2)补零（如(Math.round(1.005 * 100) / 100).toFixed(2)→"1.01"） - 注意
Math.round对.5的处理是“向偶数舍入”（银行家舍入），多数场景够用；若必须传统四舍五入，改用Math.floor(num * 100 + 0.5) / 100 - 对字符串输入，先用
parseFloat转，避免隐式转换出错（+"1.234"比Number("1.234")更宽松，但parseFloat("1.23abc")会得1.23，需按需校验）
HTML input 输入时实时限制小数位数
input[type="number"] 的 step 属性可约束合法值，但浏览器实现不一；纯前端拦截需结合事件监听，否则用户仍可粘贴或拖动输入非法小数位。
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 设
step="0.01"并配合min/max，但别指望它阻止手动输入三位小数（Chrome 允许，Firefox 可能截断） - 监听
input事件，用正则/^\d+(\.\d{0,2})?$/实时过滤，匹配失败就event.target.value = prevValue - 注意
onchange太晚（失焦才触发），oninput才能实时响应；移动端还需处理compositionend防中文输入法干扰
CSS 无法控制小数位数，别白费劲
text-align、font-variant-numeric 或 tabular-nums 只影响数字排版对齐和字形，对数值精度、舍入、显示位数完全无效。试图用 CSS 格式化数字等于在 HTML 里写 <div>3.14159</div> 后幻想它自动变 3.14。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 所有小数位控制逻辑必须落在 JavaScript 层；CSS 只负责让
3.14看起来整齐，不负责让它变成3.14 - 服务端返回数据前就做好精度处理（如后端用
round(val, 2)），比前端补救更可靠 - 如果用模板引擎（如 Handlebars、Vue 插值），确认其过滤器是否调用了 JS 的
toFixed——很多默认过滤器有同样精度陷阱
事情说清了就结束。真正难的不是写 toFixed(2)，是意识到什么时候它已经悄悄给你错了。
