“9.9 乘 3 等于多少”这问题连刚上二年级的孩子都能一口报出答案可你在 uniapp 里写一句{{ 9.9 * 3 }}界面上很可能蹦出29.700000000000003。前阵子我帮一个做小学数学口算练习的小程序做改版题库里加了“一位小数乘法”这个模块测试同学截了张图丢过来题目是“9.9 × 3”标准答案那栏写着29.700000000000003孩子答 29.7 被判错。那一刻我就知道这不是业务逻辑写错了而是 JavaScript 数值类型本身的老毛病换了个地方冒出来。这篇内容围绕“uniapp 里乘法结果尾巴很长”这件事展开从浮点数在二进制里的存储方式讲起到 uniapp 跨端渲染时这个数字要经过哪几道手再到几种修法的真实效果对比最后落回口算题库这个具体场景——出题、判题、展示三端怎么配合才能彻底绕开精度问题。不管你是刚接手游 uniapp 的新手还是已经做过几个小程序、只是想找一份能直接抄的数值工具模块看完都能少走几段弯路。文中所有代码都是纯前端逻辑不涉及任何平台特定接口换到 H5 或 App 端同样跑得通。1. 那道 9.9×3 的错题长小数尾巴的来历1.1 先把现场复现出来出问题的页面结构很简单上方是题干中间一个输入框孩子填完点“确认”下面显示判定结果。题干和标准答案都来自同一个计算函数。我把它抽出来单独跑了一遍const a 9.9; const b 3; console.log(a * b); // 29.700000000000003 console.log((a * b).toFixed(2)); // 29.70有意思的地方在于toFixed(2)出来的29.70看起来是干净的。那为什么页面上显示的还是长尾巴继续往上翻代码发现展示的地方写的是{{ answer }}answer直接就是a * b的结果toFixed只加在了判题那一步的比较里。也就是说判题逻辑其实没问题后面我会说它其实也有问题只是在这一例刚好蒙对真正出丑的是渲染层。同一个数在两处呈现不同结果这提醒了我一件事浮点数精度问题从来不是“算错了”而是“同一个数在不同环节用了不同的表示”。理清这个前提后面的排查才不容易跑偏。再补一个更典型的例子也是口算题库里高频出现的console.log(0.1 * 3); // 0.30000000000000004 console.log(0.7 0.1); // 0.7999999999999999 console.log(1.1 * 1.1); // 1.2100000000000002三条里有两条偏大、一条偏小。很多人第一反应是“JS 有 bug”其实恰恰相反JS 的行为完全符合国际标准是我们在用十进制思维去要求一个二进制系统。1.2 0.1 在二进制里根本没有“有限写法”要理解这件事得先接受一个反直觉的常识十进制里的0.1换成二进制是无限循环小数就像十进制里的1/3 0.3333...永远写不完一样。二进制小数每一位的权重是 1/2、1/4、1/8、1/16……用这些权重去凑出 0.1得到的是一串0.0001100110011001100...1100这四位无限循环。既然写不完计算机只能截断存一个最接近的近似值。JavaScript 的Number用的是 IEEE 754 双精度格式总共 64 位1 位符号、11 位阶码、52 位尾数隐含最高位 1实际有效精度 53 位。53 位二进制有效数字折算成十进制大约是 15.95 位所以一个Number能可靠表示的十进制有效数字大概是 15 到 17 位。0.1存进去之后实际值是0.1000000000000000055511151231257827021181583404541015625这已经比 0.1 大了一点点。再乘 3误差跟着放大三倍得到0.30000000000000004这是规范化到 53 位有效数字之后的最近可表示值。这里有个细节值得单独说一下为什么控制台打印出来是0.30000000000000004这种看起来“只多了一位”的样子而不是上面那串二十多位的小数因为Number.prototype.toString用的是一种“最短往返表示”算法——在所有能把该二进制值唯一还原回来的十进制写法里挑最短的那个。所以你看到的尾巴已经被“美化”过了真实存储值比它长得多。理解这一点非常关键你看到的长度不代表误差的大小只是最短可还原表示的长度。有些数误差明明很小打印出来却很长有些数误差挺大反而看着很短。1.3 为什么偏偏在乘法上暴露得最明显口算题库里加减乘除都会碰到小数但用户反馈集中在乘法上这不是巧合。原因有三层。第一层是数学层面的。乘法的相对误差会累加(a × (1ε₁)) × (b × (1ε₂)) ≈ a×b × (1ε₁ε₂)。两个操作数各自的相对误差会相加。加法虽然也有误差但只在数量级悬殊时才明显大数吃小数乘法则几乎每次都会带出问题。第二层是业务层面的。小学数学的口算题答案通常是“好看的数”——29.7、1.21、0.08 这种位数少、结尾是 0。恰恰是这种“人类觉得好看”的数最容易落在二进制无法精确表示的位置上。0.5、0.25、0.125 这类能精确表示的反而少见。第三层是展示层面的。“大九九乘法口诀表”里都是整数1×1 到 9×9怎么算都不会出问题。一旦扩展到“小数乘法”章节整张表就塌了。我后来统计了一下题库里出问题的题目几乎全部集中在带小数的乘法上整数乘法一条都没事。提示排查这类问题不要一上来就改代码。先在控制台跑一遍(a * b).toString()和a.toPrecision(20)把实际存储值打出来看看很多“玄学”立刻就有了解释。2. 在 uniapp 里这个数字要过几道手2.1 从输入框到变量你拿到的是字符串做口算练习输入框是必需品。uniapp 里写input v-modelform.answer typedigit /看起来跟 Vue 项目里没什么区别但编译到小程序端之后v-model会被展开成:value加input的组合而e.detail.value拿到的类型是字符串不是数字。这就埋下了第一颗雷。孩子输入29.7form.answer的值是29.7字符串。接下来代码里做比较if (form.answer correctAnswer) { /* 判对 */ }字符串和数字做严格比较永远是false这一题必然判错。如果改成宽松比较29.7 29.7是true看起来能过但宽松比较的隐式转换规则足够写一本书 0也是true0x10 16还是true用在判题场景风险太高我不建议。再往下还有第二颗雷。业务代码里如果写的是加法求和比如统计一页题目的总分29.7 1.3得到的是29.71.3字符串拼接。乘法因为运算符没有重载9.9 * 3会隐式转数字反而“正常工作”这恰恰让问题更隐蔽——同一个表单字段做乘法没事做加法炸了开发者在测试时很容易漏掉。我在这个项目里做的第一件事就是把输入值在进入业务逻辑前统一转成定点整数详见第 4 节的工具模块。原则只有一条表单给什么类型我不管进业务层之前一定转成整数。2.2 逻辑层与渲染层之间的那道坎uniapp 编译到小程序端时采用的是逻辑层与视图层分离的架构。JS 代码跑在逻辑层页面渲染跑在视图层两边不是同一个执行环境数据要通过序列化消息传递。这个机制带来一个容易误解的点很多人以为“经过一次序列化精度就丢了”。实际上Number类型在传递过程中精度是不变的序列化再反序列化同一个0.1 0.2还是那个0.30000000000000004。真正会出问题的是Date、undefined、函数、BigInt这几类其中BigInt的问题后文会专门说。但跨层确实有个实实在在的坑同一个计算不要在两个环境里各做一次。我见过这样的写法模板里画一个合计view合计{{ (price * count).toFixed(2) }} 元/view然后在methods里又算一遍存到data里用于提交。两处算法不一致一处toFixed、一处没做显示和提交的数据就对不上。更麻烦的是模板表达式在每次重渲染时都会重新求值如果有累加逻辑藏在里面页面刷新一次数字就变一次。我的规矩是所有数值计算只在 JS 里做一次模板只负责把算好的值原样吐出来。模板里出现运算符一律视为代码异味。2.3 不同端的表现差异哪些是真的、哪些是心理作用经常听到“这个问题 iOS 上没事安卓上就出来了”。我拿同一个题库在几个环境下跑过对比结论比较朴素环节是否存在端差异实际情况加减乘除运算本身基本没有都遵循 IEEE 754结果一致toFixed/toPrecision极小概率有老版本引擎对“恰好在中点”的舍入处理偶有出入数字转字符串输出轻微最短往返算法实现细节略有不同极少数值打印位数不一致输入框取值类型有某些端返回字符串某些端在typenumber时返回数字长按、滚动等交互有与数值无关但容易被误判成“数字问题”真正值得注意的是输入框取值类型那一行。如果你写死了typenumber并依赖它返回数字在部分端上会拿到字符串接着typeof判断走不同分支行为就分叉了。至于toFixed的端差异我实测下来遇到的次数非常少且都集中在若干年前的老环境上日常开发不用太担心。但有一条经验值得记不要在toFixed之后直接参与运算。它返回的是字符串(1.005).toFixed(2) 1会得到1.001这种错误在真机日志里很难一眼看出来。3. 五种修法的实测对比3.1 toFixed 不是万能药它的坑比想象中深大部分人的第一反应是toFixed(2)一把梭。它确实能解决大多数展示问题但有两个前提必须搞清楚。第一个前提toFixed返回的是字符串。用完之后如果还要接着算得Number()转回来一转回来精度噪声又回来了。所以它只适合做“最后一公里”的展示格式化不适合做中间计算。第二个前提toFixed的舍入结果可能和你的直觉不一致。console.log((1.005).toFixed(2)); // 1.00 而不是 1.01 console.log((1.335).toFixed(2)); // 1.33 而不是 1.34 console.log((8.575).toFixed(2)); // 8.57 而不是 8.58很多人以为这是“四舍六入五成双”的银行家舍入在作祟其实不是。ECMAScript 规范里toFixed的行为是“取最接近的 n 位小数表示如果恰好在中点则取较大的那个”规则本身是“五入”的。问题出在输入值上1.005存进内存时实际是1.00499999999999989341...它压根就不在中点上比中点小自然舍下去。这个现象在口算判题里是致命的。孩子算对了 1.01你用toFixed(2)算标准答案得到 1.00判错。而且这种错误极其隐蔽因为它只在特定的数值上出现测试时十道题可能一道都碰不上。我的做法是toFixed只用于最终的显示绝不用于判题比较。判题走定点整数见 4.2。3.2 放大取整法够用但要知道它的边界放大取整的思路很直白先把两个小数都乘以 100 变成整数乘完再除回去。function mul(a, b, digits 2) { const scale Math.pow(10, digits); return Math.round(a * scale) * Math.round(b * scale) / (scale * scale); } console.log(mul(9.9, 3)); // 29.7 console.log(mul(1.1, 1.1)); // 1.21这个写法对小数量级的场景足够好用但有三条边界必须清楚。第一条Math.round(a * scale)这一步本身就在做浮点乘法1.15 * 100得到的是114.99999999999999Math.round之后是 115这一例蒙对了。但换个值就不一定8.475 * 100得到847.4999999999999Math.round得 847而我们期望的是 848。也就是说放大这一步本身就可能引入误差。第二条溢出。Number.MAX_SAFE_INTEGER是 9007199254740991大约 9×10¹⁵。如果两个操作数放大 100 倍之后都接近 10⁷乘积就到了 10¹⁶超出安全整数范围Math.round之后低位会丢。口算题不会这么大但如果是电商价格计算场景就得掂量了。第三条除法那一步又把结果拉回了浮点域29.7本身在二进制里依旧不精确只是打印出来好看。如果这个结果还要继续参与后续运算误差会继续累积。所以放大取整的定位是适合“一步算完就展示”的场景不适合链式计算。口算判题刚好属于前者用它是可以的但我更推荐直接用字符串解析版本把放大那一步的误差也掐掉。3.3 精度库体积、API 风格与模板渲染的适配一旦业务复杂起来比如要算折扣、税费、分摊放大取整就不够看了这时候上精度库是正解。几个常见的库压缩后体积约特点适用场景big.js6 KB / gzip 约 3 KB极简只做四则运算和比较大多数业务计算decimal.js32 KB / gzip 约 12 KB功能全支持任意精度、三角函数、进制转换科学计算、金融bignumber.js18 KB / gzip 约 7 KB配置项多误差、舍入模式可调需要精细控制舍入小程序主包体积一般有 2 MB 上限具体以各平台文档为准加个 3 KB 的 big.js 完全不心疼。我用得最多的是 big.jsAPI 简单import Big from big.js; const r1 new Big(9.9).times(3); console.log(r1.toString()); // 29.7 console.log(r1.toFixed(2)); // 29.70 // 注意构造函数传字符串比传数字安全 console.log(new Big(0.1).plus(0.2).toString()); // 0.3这里有个容易踩的细节new Big(0.1)和new Big(0.1)结果一样因为构造时会用Number.prototype.toString()把数字转成最短往返字符串再解析。但如果你传的是个计算结果比如new Big(0.1 0.2)它拿到的就是0.30000000000000004这个字符串库再精确也救不回来。所以规矩是能传字符串就传字符串别把已经污染的数字喂给库。第二个坑是渲染。big.js 返回的是 Big 对象不是原始值。模板里写{{ result }}会渲染成一串对象信息。必须先.toString()或.toFixed()转成字符串再塞进data。第三个坑是引入方式。小程序端对环境有要求import Big from big.js在大部分构建配置下没问题少数情况下需要配transpileDependencies或者在vue.config.js里加require(big.js)的 hoisting 处理。项目打包报 “Big is not a constructor” 的时候先看是不是被 Babel 处理成了default包裹。3.4 BigInt能力很强但在跨端环境里要慎用BigInt是 ES2020 的特性能做任意精度的整数运算理论上非常适合做定点计算。在 Node 环境里跑得好好的搬到小程序上就得留神两件事。第一是引擎支持。较新的基础库环境下BigInt是可用的但项目如果还要兼容一些老设备得先做能力检测const hasBigInt typeof BigInt function;第二是序列化。BigInt类型的值一旦进入setData的数据流序列化会直接抛错JSON.stringify({ n: 1n }); // TypeError: Do not know how to serialize a BigInt因为跨层传数据本质上是序列化所以BigInt绝对不能出现在要渲染的数据里。变通办法是转成字符串再传但这又回到了字符串处理绕了一圈。我的结论是口算题库这种场景用不上BigInt定点整数完全够BigInt更适合处理超大整数比如身份证号、超长订单号的运算且只在逻辑层内部使用结果转字符串后再往外传。3.5 字符串竖式乘法极端场景下的兜底还有一种“笨办法”——用字符串模拟小学生竖式乘法一位一位地算。这个方法在需要绝对精度的场合比如超过 15 位有效数字的超长小数是唯一可靠的路子。我做过一版核心就是按位乘、按位进位最后根据小数位数点小数点。function stringMul(a, b) { // 只处理非负数字符串省略符号判断 const da (a.split(.)[1] || ).length; const db (b.split(.)[1] || ).length; const ia a.replace(., ); const ib b.replace(., ); const res new Array(ia.length ib.length).fill(0); for (let i ia.length - 1; i 0; i--) { for (let j ib.length - 1; j 0; j--) { const p res[i j 1] Number(ia[i]) * Number(ib[j]); res[i j 1] p % 10; res[i j] Math.floor(p / 10); } } let s res.join().replace(/^0/, ) || 0; const total da db; if (total 0) { s s.padStart(total 1, 0); s s.slice(0, s.length - total) . s.slice(s.length - total); } return s; } console.log(stringMul(9.9, 3)); // 29.7 console.log(stringMul(1.1, 1.1)); // 1.21这个函数没有精度问题但它慢、代码长、边界多符号、前导零、末位零。我把它作为工具模块里的“兜底函数”只在检测到操作数位数超过 12 位时才调用日常走定点整数路径。绝大多数项目根本用不到它知道有这条路就行了。4. 口算应用场景从结果精度倒推出题策略4.1 出题端就锁定小数位比事后修省事得多前面折腾了半天都是“算完了怎么修”。真正的转折点是我意识到口算题库根本不需要真的做小数乘法。题目是程序生成的答案也是程序生成的那为什么不从源头就生成整数原来的写法是先生成随机小数再相乘const a (Math.random() * 10).toFixed(1); // 已经变成字符串了 const b Math.floor(Math.random() * 9) 1; const answer Number(a) * b; // 噪声从这里进来改成生成整数再拼装// 以 0.1 为最小单位生成 1.0 ~ 9.9 之间的一位小数 const aInt Math.floor(Math.random() * 90) 10; // 10 ~ 99 const bInt Math.floor(Math.random() * 9) 1; // 1 ~ 9 const stem ${aInt / 10} × ${bInt}; // 仅用于展示 const answerInt aInt * bInt; // 精确整数单位是 0.1 const answerText formatFixed(answerInt, 1); // 29.7注意aInt / 10这一步也有浮点但它只用于拼接题干字符串不参与任何后续运算。答案aInt * bInt全程在整数域297这个值精确无误。展示时用formatFixed(297, 1)得到29.7纯字符串操作零误差。这个思路可以推广所有涉及小数的业务内部一律用“最小货币单位”式的整数存储只在展示层做一次缩放。价格用分、成绩用千分位、时长用毫秒都是同一套逻辑。4.2 判题不能直接比相等即使用了定点整数判题也得留个心。因为用户的答案是从输入框来的字符串得先解析成同单位整数function parseFixed(input, digits) { let s String(input null ? : input).trim(); if (!/^-?\d*(\.\d*)?$/.test(s) || s || s - || s .) return null; const neg s.charAt(0) -; if (neg) s s.slice(1); let [intPart 0, fracPart ] s.split(.); fracPart (fracPart 0.repeat(digits)).slice(0, digits); const v Number(intPart fracPart); if (!Number.isSafeInteger(v)) return null; return neg ? -v : v; }这段的关键在于用字符串拼接做放大而不是Number(s) * 100彻底避开了 3.2 里提到的 1.15×100 那个坑。解析完再比较const userInt parseFixed(form.answer, 1); const correctInt answerInt; const isRight userInt correctInt;整数比较绝对可靠。用户输入29.70解析成297输入29.7也是297输入29.75因为只取一位小数会被切成297这就有问题了。所以还得加一步校验解析时要检查原始输入的小数位数是否超过题目要求超了就判格式错误提示“本题答案保留一位小数”。function fracLen(s) { const i String(s).indexOf(.); return i 0 ? 0 : String(s).length - i - 1; } if (fracLen(form.answer) 1) { return showTip(答案请保留一位小数); }如果确实需要容差比较比如允许孩子多写一位有效数字再退到浮点比较用相对误差const diff Math.abs(Number(form.answer) - Number(answerText)); const ok diff Math.abs(Number(answerText)) * 1e-9;1e-9这个阈值不是随便定的它是给“15 到 17 位有效数字里有 1 位不确定”留出的余量日常业务够用。4.3 口诀表、顺口溜这类静态内容和动态计算的混排标题后半段提到的“大九九乘法口诀表”和“数学顺口溜”在这个项目里占的篇幅其实比动态出题还大。大九九是 1×1 到 9×9 的完整 81 条口诀小九九只保留 45 条去掉交换律重复项。做练习册页面两种都要支持。这部分内容全是静态的用二维数组写死最省事const BIG_TABLE []; for (let i 1; i 9; i) { const row []; for (let j 1; j 9; j) { row.push({ a: i, b: j, text: ${CN[i]}${CN[j]}${resultText(i * j)} }); } BIG_TABLE.push(row); }i * j最大 81远在安全整数范围内不会有任何精度问题。这里真正要花心思的是格式化文本因为口诀是中文表达“二三得六”和“三四十二”的句式不一样乘积小于 10 用“得”大于等于 10 直接跟数字。function resultText(n) { return n 10 ? 得${CN[n]} : CN[n]; }至于顺口溜本质是一段富文本跟计算无关。我把它做成独立的静态配置和题库数据分开管理避免编辑内容时误碰数值逻辑。混排页面的坑主要在两处一是长列表渲染性能81 个格子如果用v-for嵌套两层的写法在低端机上首屏会卡顿建议用scroll-view加分页加载二是文字对齐“一一得一”三个字和“六八四十八”五个字挤在同一列里用等宽字体加text-align: center才看得舒服。4.4 一个可以整段抄走的数值工具模块把上面所有东西收拢成一个文件大概长这样。这个模块不依赖任何第三方库压缩后不到 1 KB全部用字符串和整数运算适合直接丢进utils/目录。// utils/fixed.js export function parseFixed(input, digits) { let s String(input null ? : input).trim(); if (s || !/^-?\d*(\.\d*)?$/.test(s)) return null; const neg s.charAt(0) -; if (neg) s s.slice(1); let [ip 0, fp ] s.split(.); fp (fp 0.repeat(digits)).slice(0, digits); const v Number(ip fp); if (!Number.isSafeInteger(v)) return null; return neg ? -v : v; } export function mulFixed(aInt, bInt, digits) { const raw aInt * bInt; // 放大 10^(2*digits) 倍 if (!Number.isSafeInteger(raw)) return null; return Math.round(raw / Math.pow(10, digits)); } export function formatFixed(intVal, digits) { if (!Number.isFinite(intVal)) return ; const neg intVal 0; let s String(Math.abs(intVal)).padStart(digits 1, 0); const ip s.slice(0, s.length - digits); let fp s.slice(s.length - digits).replace(/0$/, ); const out fp ? ${ip}.${fp} : ip; return neg ? -${out} : out; }三个函数的职责划分很清晰parseFixed负责“外部字符串进整数域”mulFixed负责“整数域内做乘法”formatFixed负责“整数域回字符串”。业务代码只在这三个函数的边界上打交道中间永远不出现浮点数。配套的单元测试我建议至少覆盖这几组值0.1、9.9、1.15、-3.75、空字符串、1.、.5、十六位以上的超长数字。这几组跑通基本就能拦住 90% 的边界问题。5. 上真机之前的自查清单5.1 三个最容易被测试打回来的细节第一输入框的键盘类型和实际允许输入的内容对不上。typedigit在很多端上带小数点但少数端只给整数键盘孩子根本输不进小数。稳妥做法是typedigit再加一层输入过滤非法字符直接拦掉别指望键盘类型能兜住。第二末尾的零被吃掉了。29.70存在整数域里是2970按两位小数格式化能得到29.70如果按一位小数格式化就变成29.7。题目要求保留两位时展示必须严格按两位来别在格式化函数里统一replace(/0$/,)。我在formatFixed里做了去尾零所以业务代码要判断是否走这个函数——要求固定位数的题目直接调toFixed(digits)更保险。第三负号和零的组合。-0在 JS 里是存在的formatFixed(-0, 2)会因为neg判断为false而输出0.00看着没问题但formatFixed(-1, 2)输出-0.01如果孩子答错方向显示上没问题。真正要防的是parseFixed(-0)正则放行走进来是-0Number(-00)是-0参与比较时-0 0为true会误判。加上if (v 0) return 0;这一句就干净了。5.2 我踩过的一次排查弯路说一个我自己的教训。项目上线后有家长反馈“9.8 × 5 显示成了 49孩子答 49 被判错”。第一反应是精度问题我翻来覆去检查格式化函数跑了十几组数都没复现。后来把用户的题目 ID 捞出来发现那道题的答案字段存的是49.0但孩子输入的49被parseFixed按一位小数解析成了490而标准答案因为某次数据迁移存成了整数49没有放大490 ! 49判错。问题不在浮点数在数据单位不统一。一部分老题目的答案以“元”为单位存整数新题目以“分”为单位存放大值两套标准混在一张表里。这件事让我在后来的项目里养成了一个硬规矩所有入库的数值字段必须带单位后缀叫answerInt还是answerText一眼就能看出来别叫answer。排查这类问题有个很有效的办法把标准答案和用户答案在比较前都console.log打出来连同它们的typeof和放大倍数。很多“精度问题”其实都是单位问题、类型问题伪装的。5.3 后续还能怎么扩展这套定点整数的思路不只适用于口算题。分数运算可以按“最小公倍数放大”处理单位换算可以按“最小单位”处理甚至连“统计平均分保留两位”这种需求也能先把总分乘以 100 再除以题数全程整数。如果后面要加混合运算比如(1.5 2.5) × 3只要保证每一步都在整数域完成、每步之后用对应的digits收敛链式计算也不会出问题。我给自己定的规则是任何进入表达式的值必须是已经转换好的整数中间不允许出现Number()的临时转换。这条规则执行得越严格后期排查成本越低。另外那个字符串竖式乘法的兜底函数虽然在口算场景用不上但我一直留着。遇到用户输入超长数字、或者要做大数交易金额计算的场景它能救急。放在utils/里不占多少空间比临时抓瞎强。最后分享一个我自己一直在用的小习惯每接一个新的 uniapp 项目第一件事就是在utils/里建好这个fixed.js然后在项目的README里写一行“所有小数计算走 fixed 模块禁止直接乘除”。写在最前面的约定比事后再改二十个页面省事得多。
