前阵子接手一个数学口算练习的小程序用 uniapp 一套代码同时跑到 H5、小程序和 App 三端。上线第三天反馈区里就出现了这样一张截图题目是 1.1 × 3孩子填的答案其实没错可答案框里却显示成 3.3000000000000003系统给出了判错。这就是很典型的uniapp 乘法结果保留了很多小数的问题跟 uniapp 本身没多大关系根子在 JavaScript 的浮点数。很多做教育类工具的同行第一次碰到它都会以为是渲染出了错或者怀疑是某端某个运行端的兼容问题其实换个浏览器也一样。顺着这个问题往下扒还能牵出一大串事情乘法口诀表的数据怎么生成、口算题判题为什么老是差那么一点点、正确率为什么显示成 66.66666666666667、家长群里那些“数学顺口溜”和“大九九乘法口诀表”的内容要怎么组织才能让孩子背得下去。这篇就把这条线从头到尾捋一遍包括我为啥最后选了“整数化计算 统一格式化”这套方案中间踩过哪些坑以及可以直接复刻粘贴的代码。不管你是刚接触 uniapp 的新手还是已经维护过几个教育类项目的老手下面这些内容基本都能拿去用。1. 先把现象锁死3.3000000000000003 到底从哪儿冒出来的1.1 出问题的那几行代码基本都是同一个套路先说最常见的写法。页面上有个答案输入框用户输入完点提交代码大概是这样的// 页面里的判题逻辑错误示范 const a 1.1 const b 3 const right a * b if (Number(this.userAnswer) right) { this.score 1 }看起来没毛病但a * b在 JavaScript 里算出来的值是3.3000000000000003。用户输入3.3Number(3.3)得到3.3两个数严格相等比较的结果是false这道题就被判错了。孩子明明算对系统却说错家长的情绪可想而知。还有一种更隐蔽的写法是在模板里直接算text classanswer{{ a * b }}/textH5 端页面上就会直接渲染出3.3000000000000003这一长串。有人会说“我用toFixed(2)了啊”可toFixed返回的是字符串3.30 3.3依然是false。所以这个问题的完整链条是计算值本身不精确 → 显示和比较用的又是这个不精确的值 → 判题失败。三个环节里任意一个没处理好问题都会冒出来。1.2 二进制浮点数为什么 1.1 从一开始就“不是 1.1”JavaScript 里的数字只有一种类型就是双精度 64 位浮点数遵循 IEEE 754 标准。它的结构是 1 位符号、11 位指数、52 位尾数。问题在于十进制里的 0.1、1.1 这类数转成二进制是无限循环小数0.1(十进制) 0.0001100110011001100110011...(二进制无限循环)52 位尾数存不下无限循环只能截断成最接近的那个值。所以计算机里根本没有精确的 0.1只有 0.1000000000000000055511151231257827。这就是所有麻烦的源头。1.1 同理它存的其实是比 1.1 稍微大一点点的那个数。乘 3 之后误差被放大到末位就变成了3.3000000000000003。经典例子是0.1 0.2结果0.300000000000000040.1 0.2 0.3是false。这跟平台无关跟语言实现无关纯属标准本身的行为。顺带说一个相关的概念安全整数。双精度浮点能精确表示的整数范围是-(2^53 - 1)到2^53 - 1也就是9007199254740991。超过这个范围加减法都可能出错。这个数字后面讲乘法口诀表扩展时会用到因为 19 × 19 才 361离安全整数边界差着好几个数量级完全不用担心。1.3 为什么在 uniapp 项目里这个坑特别容易被放大浮点误差是所有 JavaScript 环境共有的但 uniapp 项目有几个特点会把它放大成线上事故。第一是多端并存。同一份代码要跑 H5、小程序、App很多人会在 H5 上调试完毕就发版结果小程序端的输入框v-model拿到的一直是字符串Number()转换的时机不同判题逻辑就跟着跑偏。H5 的input typenumber和小程序的typedigit行为也不完全一样一个允许输入负号一个默认只允许数字和小数点。第二是模板表达式的能力限制。小程序端的 WXS 只支持 ES5 语法Number.EPSILON、padStart、padEnd这些想都别想模板里算复杂逻辑很容易出问题。比较稳的做法是所有数值都在逻辑层算好、格式化好再传给视图层模板里只做展示。第三是数据来源混杂。题库数据可能从后台接口取返回的选项值、题干里的数字可能是字符串类型的1.10本地 Storage 里存的错题记录读出来也是字符串。这些数据一旦直接参与运算1.10 * 3会得到3.3000000000000003字符串被隐式转换误差照旧。我在项目里就遇到过同样的题在“随机练习”里对得在“错题重练”里错排查了两小时最后发现是存储层把数字序列化成了字符串。2. 方案选型四种修法各自能走到哪一步2.1 toFixed 和 Math.round看起来能用其实只能应付展示先说最容易被抓起来就用的两个。toFixed(2)的问题不只是“返回字符串”。它的舍入行为在很多情况下反直觉(1.005).toFixed(2) // 1.00不是 1.01 (0.615).toFixed(2) // 0.61不是 0.62原因还是那个1.005 在内存里实际是 1.0049999999999998934...0.615 实际是 0.61499999999999999112...它们本来就小于“中点”所以被舍掉了。这不是 bug是规范允许的实现相关行为。拿它做财务金额是灾难拿它做口算题的展示倒是勉强能用因为口算题答案一般只有一两位小数。Math.round(x * 100) / 100也有类似陷阱。0.615 * 100的结果是61.49999999999999Math.round得到 61除以 100 是 0.61正确答案应该是 0.62。这个“放大到整数”的思路本身是对的但乘100这一步又引入了新的浮点误差等于把问题从 A 挪到了 B。我的结论是这两个方法只适合纯展示场景不要拿它们的结果去做任何比较或二次计算。2.2 放大取整法原理最简单但必须处理三个边界真正靠谱的路线是把十进制的小数“抬”成整数再算。原理不复杂a ia / 10^da (ia 是 a 去掉小数点后的整数da 是小数位数) b ib / 10^db a × b (ia × ib) / 10^(da db)ia × ib是两个整数相乘只要结果不超过安全整数范围就是精确的。真正会出问题的只有最后那一步除法但配合合适的格式化输出视觉上和逻辑上都不会有偏差。真要做会撞上三个边界科学计数法String(0.0000001)得到1e-7里面根本没有小数点靠indexOf(.)数小数位会直接返回 0计算全错。教育场景里数值范围小不容易触发但工具函数既然写了就该把这个分支堵上。负数String(-1.25)长度是 6但去掉负号后的有效部分只有 5 位小数位数要算length - indexOf(.) - 1都不用减负号因为小数点位置本身已经把负号带过去了。看起来不用处理但toInt里拼字符串时一定要记得先剥离-或者直接对绝对值操作。超范围ia × ib超过9007199254740991就失去精度。三个三位数相乘是 9 位安全金额到“分”再乘个利率就不一定了。2.3 高精度库值不值算一笔包体积的账decimal.js、bignumber.js这类库确实能把上面的问题全解决API 也友好。但对 uniapp 项目来说得算账。小程序主包一般 2MB 上限一个 decimal 库压缩后大约 30KB 到 60KB听起来不多可教育类小程序里图片资源占大头每加一个库都在挤空间。更关键的是这类库在 WXS 环境里跑不了只能放在逻辑层每道题的判题都要做一次跨层调用几十道题的练习页面在低端安卓机上会有肉眼可见的卡顿。我的判断是口算练习、口诀表、成绩统计这类场景数值范围小、精度要求明确自己写 60 行工具函数完全够用上库是杀鸡用牛刀。如果是计费、优惠券叠加、跨币种结算这种别犹豫直接上库省下来的排查时间比包体积值钱得多。2.4 我给这个项目定的三条铁律定完这几条之后同类问题再没复发过计算归计算所有涉及小数的运算先抬成整数算完再按需要的精度落回来中间不做任何格式化。显示归显示视图层只接收格式化好的字符串模板里不出现任何乘除运算。判题归判题用户输入统一转成数值后按题目的精度要求比对比如题目答案精度是 1 位就把用户答案也按 1 位截断再比而不是拿两个浮点数硬碰硬。这三条看起来是废话但真按它改代码会发现很多原来“玄学”的错误都不见了。3. 动手实现从工具函数到乘法口诀表生成3.1 一个 60 行的精度工具模块覆盖了口算练习的全部需求新建utils/decimal.js把下面这几个函数放进去。我不追求大而全只保留口算练习真正用得到的部分。// utils/decimal.js // 数一个数字有几位小数兼容科学计数法 export function decimalPlaces(num) { const s String(num) if (s.indexOf(e) -1 || s.indexOf(E) -1) { // 简单降级指数形式一律用原始字符串精度兜底 const parts s.toLowerCase().split(e) const baseDec parts[0].indexOf(.) -1 ? parts[0].split(.)[1].length : 0 return Math.max(0, baseDec - Number(parts[1])) } const i s.indexOf(.) return i -1 ? s.length - i - 1 : 0 } // 去掉小数点转成整数保留符号 export function toInt(num) { const s String(num) if (s.indexOf(e) -1 || s.indexOf(E) -1) { return Math.round(num * Math.pow(10, decimalPlaces(num))) } return Number(s.replace(., )) } // 精确乘法 export function mul(a, b) { const da decimalPlaces(a) const db decimalPlaces(b) const result toInt(a) * toInt(b) return result / Math.pow(10, da db) } // 精确加法错题累加、分数累计都会用到 export function add(a, b) { const d Math.max(decimalPlaces(a), decimalPlaces(b)) const p Math.pow(10, d) return (Math.round(a * p) Math.round(b * p)) / p }mul的逻辑值得多说一句。toInt(1.1)得到11toInt(3)得到3乘起来是33小数位总数是1 0等于 1最后33 / 10得到3.3。这一次除法得到的结果恰好就是能精确表示的那个双精度值所以比较和展示都没问题。注意最后这一步除法在极端情况下仍会引入误差比如1 / 3这种无限循环小数任何方案都救不了。所以判题时不要靠“算出来的值相等”来判要靠“格式化后的字符串相等”来判具体在 3.4 节说。3.2 大九九乘法口诀表用整数生成压根不会有小数讲完工具函数回到那个把人带偏的“乘法口诀表”。项目的实际需求有两块一是给孩子一个可以翻看的完整口诀表二是根据易错点自动出题。先说口诀表的数据。传统上常见两种分法一种只列a ≤ b的 45 句叫“小九九”一种列全部两张的乘积、含交换律共 81 句叫“大九九”。我选择两种都生成让用户自己切换因为低年级背 45 句负担小高年级练全表更有用。// 生成大九九全表81 句 export function buildFullTable() { const list [] for (let a 1; a 9; a) { for (let b 1; b 9; b) { list.push({ a, b, result: a * b, // 整数乘法绝对精确 text: ${a} × ${b} ${a * b}, group: a // 按乘数分组方便做折叠面板 }) } } return list } // 生成小九九45 句只保留 a b export function buildHalfTable() { return buildFullTable().filter(item item.a item.b) }这里能顺带印证前面说的整数相乘根本没有精度问题7 * 8永远是56。所有小数麻烦都是“题目里出现了小数”带来的。所以我在题库设计上做了个取舍低年级题目只用整数三年级以上引入一位小数的乘除法。这样既控制住了精度风险又符合教学进度。再往下就是内容组织。光有表没用孩子记不住。项目里做了“易混组”的归类把6×742、7×856、6×848、7×963这几句单独拎出来因为它们读音接近、数值相邻是错得最多的一组。配上自己编的短句帮助记忆比如“六七四十二抬头看日历七八五十六一周差一天”。这类顺口溜没有标准答案每个老师编的都不一样重要的是节奏顺口、能和数字挂钩。有些家长更认“大九九”的扩展版也就是把范围从 9×9 扩到 19×19。技术上完全没问题361远在安全整数范围内生成逻辑一行不用改只要把循环上限从 9 改成 19 就行。但内容上要提醒一句扩展版的记忆负担陡增一般作为学有余力孩子的加餐不建议一上来就全背。3.3 除法、正确率、平均分小数误差的另外几个出没地乘法搞定了还有三个地方会漏。第一个是除法。口算题里如果出现7 ÷ 2结果3.5精确但10 ÷ 3就是无限循环任何方案都只能保留几位。项目里的处理是出题时只出能整除的或者明确标注“保留两位小数”然后统一走格式化函数。第二个是正确率。8 / 12 * 100会得到66.66666666666667直接显示很难看。这里不涉及乘法精度纯粹是需要一个统一的百分比格式化export function formatPercent(done, total, digits 1) { if (!total) return 0% const rate (done / total) * 100 return formatFixed(rate, digits) % }第三个是分数累加。每答对一题给 0.5 分这种设定几十道题累加下来0.1 0.2 0.3的结果可能变成0.6000000000000001。这里用前面写的add函数就稳了或者干脆把分数单位改成整数内部统一用“半分”计数显示时再除以 2。后者更省事我在后来的版本里就改成了这样。3.4 显示层的统一格式化为什么我不用 toFixed判题和展示都依赖一个可靠的格式化函数。它的职责是给定一个数和小数位数返回一个长度稳定、舍入合理的字符串。const EPS 1e-12 function padZero(str, len) { // 手动补零避开小端环境不支持 padEnd 的问题 let s str while (s.length len) s 0 return s } export function formatFixed(num, digits 2) { const n Number(num) if (!isFinite(n)) return -- const sign n 0 ? - : const p Math.pow(10, digits) // 加一个极小偏移规避 1.005 这类“卡在中点偏下”的情况 const scaled Math.abs(n) * p const rounded Math.round(scaled (scaled 1 ? EPS : 0)) const s String(rounded / p) if (digits 0) return sign s const dot s.indexOf(.) const intPart dot -1 ? s.slice(0, dot) : s let decPart dot -1 ? s.slice(dot 1) : decPart padZero(decPart, digits).slice(0, digits) return sign intPart . decPart }这个函数有几个设计点。一是加了个EPS偏移。(1.005).toFixed(2)的问题在于实际值略小于中点加一个1e-12量级的偏移后它会越过中点被正确舍入成1.01。偏移只在数值大于等于 1 时加是怕极小数值被推得跨了量级。二是手动补零。padEnd在部分小程序环境的 WXS 里不可用逻辑层虽然没问题但为了万一要把这段逻辑挪到 WXS还是手写更保险。三是先算再格式化不做链式调用。判题时统一走这条路径// 判题字符串对字符串而不是浮点对浮点 const rightText formatFixed(mul(a, b), 2) const userText formatFixed(Number(this.userAnswer), 2) const passed rightText userTextNumber(3.3)再格式化成两位得到3.30formatFixed(3.3, 2)也是3.30比较相等。这样不仅判题稳定还能顺便实现“3.3 和 3.30 都算对”的宽松策略。3.5 多端验证清单改完别只在 H5 上看一眼工具函数写完得跑一轮多端验证。我用的清单是这样的验证项H5小程序App说明1.1 × 3 显示3.303.303.30模板不做运算输入 3.3 判对通过通过通过格式化后比较输入 3.30 判对通过通过通过同上输入 3.33 判错通过通过通过精度不匹配输入空字符串提示提示提示避免 Number() 为 0连算 100 题累加无漂移无漂移无漂移整数计分表里最后两行是我特意加的。Number()等于0如果不拦用户不填直接提交会被判成“答案是 0”这个错判在低年级题目里尤其容易蒙混过关。连算累加用整数计分是从源头切断了漂移。小程序端还有个细节input typedigit在部分安卓机型上允许输入多个小数点比如3..3。这在逻辑层要做一次清洗只保留第一个小数点3..3处理成3.3否则Number()会返回NaN。4. 排查实录那些让人怀疑人生的 case4.1 问题速查表先看现象再对症下药这一节整理成表出问题时先对号入座能省不少时间。现象常见原因处理方式页面显示一长串小数模板里直接写了乘除表达式逻辑层算好并格式化后传入答案对却判错浮点值直接比较格式化后字符串比较正确率显示过长小数未做百分比格式化formatPercent统一处理同样的题两处结果不同存储层把数字转成了字符串读出来统一Number()累加分数有尾差浮点累加改整数计分或add累加空输入被判成 0Number()为 0提交前做空值校验输入框能输多个小数点端上输入控件行为差异逻辑层清洗字符串老安卓机显示异常用了较新的字符串 API手动补零、避免 padStart4.2 五个踩过的坑值得单独拎出来说坑一在模板里算平均分。一开始图省事写成{{ total / count }}H5 上刚好整除没发现问题上线后有个孩子的成绩是83.33333333333333截图上直接被家长截图发群。改成逻辑层算完再传一劳永逸。坑二toFixed拿去比较。早期版本用toFixed(1)做比对3.0 3.0看着没问题但两个数一个是字符串一个是数字时就出事了。后来统一用格式化函数返回的永远是字符串比较的两边类型一致。坑三存储层的隐式转换。uni.setStorageSync(wrongList, list)存进去读出来字段类型可能变。我当时的错题对象里answer: 3.3取出来变成了字符串参与运算后判题全错。解决办法是在读取入口处做一次类型规整写个normalizeQuestion函数统一处理。坑四WXS 里的语法限制。想把格式化逻辑放进 WXS 提升渲染性能结果发现Number.EPSILON、模板字符串、箭头函数全不支持。最后放弃老老实实放在逻辑层。坑五科学计数法的偷袭。有个“单位换算”的扩展练习题目里有0.0000001米这种东西String()出来是1e-7小数位数函数直接返回 0乘出来的结果大了一亿倍。虽然这个场景在口算里少见但工具函数既然写了就得兜住所以decimalPlaces里加了指数分支。提示如果不想写科学计数法的兼容逻辑最省事的办法是在入口处限制输入范围比如“小数点后不超过 4 位、绝对值不小于 0.0001”。业务上够用代码也简单。4.3 一套可以照抄的测试用例写完工具函数别靠肉眼验。我在项目里放了一个test/number.test.js用最朴素的断言跑几个用例CI 里顺手带一下import { mul, formatFixed, decimalPlaces } from /utils/decimal.js const cases [ { a: 1.1, b: 3, expect: 3.30 }, { a: 0.1, b: 0.2, expect: 0.02 }, { a: 0.615, b: 1, expect: 0.62 }, { a: 1.005, b: 1, expect: 1.01 }, { a: -1.25, b: 2, expect: -2.50 }, { a: 12.34, b: 0, expect: 0.00 } ] cases.forEach(c { const got formatFixed(mul(c.a, c.b), 2) if (got ! c.expect) { console.error(失败: ${c.a} × ${c.b} 期望 ${c.expect} 实际 ${got}) } }) // 精度位数自检 console.assert(decimalPlaces(1.1) 1, 1.1 应为 1 位小数) console.assert(decimalPlaces(0.001) 3, 0.001 应为 3 位小数)注意第三个用例0.615的期望值是0.62这正好能把Math.round(x * 100) / 100那种写法筛出来。第五个用例验证负数第六个验证乘零。这套用例一共不到 20 行但每次改工具函数跑一遍心里就有底。5. 内容侧的延伸口诀表和顺口溜怎么组织才好维护5.1 数据结构先行别让文案散落在模板里技术问题解决了回到内容本身。项目里的口诀和顺口溜一开始是直接写死在.vue模板里的几十条view硬编码改一个字都要动页面。后来抽成了独立的 JSON 结构// data/mnemonic.js export const mnemonicGroups [ { id: hard-67, title: 容易混淆的一组, items: [ { a: 6, b: 7, result: 42, tip: 六七四十二抬头看日历 }, { a: 7, b: 8, result: 56, tip: 七八五十六一周差一天 }, { a: 6, b: 8, result: 48, tip: 六八四十八两桌坐满啦 } ] }, { id: square, title: 平方数口诀, items: [ { a: 7, b: 7, result: 49, tip: 七七四十九爬山不回头 }, { a: 8, b: 8, result: 64, tip: 八八六十四棋盘摆得齐 } ] } ]这样做的好处有三点。第一内容和技术彻底分离编口诀的人不需要懂代码改 JSON 就行。第二a、b、result三个字段是纯数字随时能拿去生成题目、做判题、算统计不用再从文案里正则提取。第三方便做多套内容比如“低年级版”和“拓展版”各自一份数据通过配置切换。注意result字段一定要和a * b保持一致人工录入容易错。可以在构建时加一个校验脚本遍历所有条目检查item.result item.a * item.b把错别字挡在发布之前。5.2 内容与计算解耦之后能玩的花样就多了解耦之后页面上的组合方式一下子灵活起来。练习模式可以从mnemonicGroups里随机抽题抽到之后直接拿a、b生成题干用mul算答案用formatFixed格式化全链路都是数字没有任何字符串拼接的中间态。错题记录里只存{ a, b, groupId }三个字段体积小读出来还能还原到原分组方便跳回对应的顺口溜去看。统计也变简单了。想知道哪一组最容易错把错题按groupId分组计数就行不需要解析文本。我有一次拿这个数据看了下发现“六七”这一组的错误率明显高于其他组就把对应的顺口溜调到了页面更显眼的位置第二周测试下来错误率降了一些。这种基于数据的微调靠硬编码文案是做不出来的。还有一个意外收获解耦之后同一份数据可以复用到不同的展示形态。同一个口诀表在小程序上是折叠面板在 H5 上是卡片瀑布流用的都是同一个数组只是渲染组件换了一下。这也是我后来坚持把内容全部抽成 JSON 的主要原因。回到最开始那个 3.3000000000000003它本质上不是一个 uniapp 的问题也不是一个“口诀表”的问题而是一个“数值在计算机里怎么存”的基础问题。只不过它恰好撞上了一个给孩子用的产品用户对“对错”的敏感度被放到了最大所以必须处理得干净。我的做法是把所有运算收拢到几个工具函数里视图层只负责展示字符串内容层只存数字和文案三层各管各的出错的时候一眼就能定位在哪一层。这套结构后来我又用到过两个类似的项目上同样的坑一个都没再踩过。