企业官网建设流程全解析

1. 先把“保留了很多小数”这件事拆开看

1.1 一个到处都在上演的现场

做小学数学练习类 uniapp 项目的同行，大概率撞过同一个画面：题目是0.7 × 0.1，答案本该是0.07，学生填了0.07，判分逻辑却给了个叉。打日志一看，前台算出来的结果是0.07000000000000001，跟标准答案一比，===直接判不等。再往下翻，成绩页还挂着一行正确率 66.66666666666666%，家长截图来问“这是什么意思”。

这就是标题里那个问题的真身：uniapp 乘法结果保留了很多小数。它跟 uniapp 本身没多大仇，uniapp 跑的是 JavaScript 引擎，Vue 模板、v-model、computed、小程序逻辑层全都是 JS 在处理数字，所以 JS 的浮点数精度问题会原封不动地出现在你的页面上。你写的是十进制乘法的业务，机器算的是二进制乘法的结果，两边对不上，误差就露出来了。

这篇文章想解决的就是这件事：先讲清楚误差从哪来，再把几条可选路线摊开对比，最后给一套能直接抄进项目的数字处理工具，以及口算判分、正确率统计、口诀表练习进度这些具体业务该怎么改。适合已经能写 uniapp 页面、正在做教育类或带数值展示的小程序/App 的开发者看，也适合被产品经理一句“为什么这里有十几个小数”问住过的同学。

1.2 教育类项目里浮点误差的三个高发区

很多人以为浮点问题只出现在金融系统里，做小学口算用不上。实际恰恰相反，越是围绕“乘法口诀”“口算练习”这类内容做产品，数值出现的地方越密集，只是平时不显眼。

第一类是判分环节。整数乘法（大九九乘法表 81 条、小九九 45 条）怎么算都不会错，因为都在安全整数范围内。可一旦练习范围扩到小数乘法、分数化小数、单位换算，判分就比较的是两个浮点数是否相等，误差立刻变成业务事故。

第二类是统计环节。正确率、平均分、连对率、班级排名、用时均值，这些全是除法算出来的。right / total * 100这种写法，在 total 为 3、7、9 这类数时，必然吐出一长串小数。页面上不格式化，就是一行十几个 6。

第三类是展示环节。计时器从毫秒换算成秒、进度条百分比、积分和小红花数量、单元测评的加权得分，都是“算完直接渲染”。模板里没有统一的出口，误差就一路冲到用户眼前。

我在几个不同规模的项目里都见过同一个现象：开发自己测试时输入的都是能整除的数字，一切正常；上线后真实用户数据一多，各种0.30000000000000004就冒出来了。所以这个问题不能等报障了再补，得在工具层一次性收口。

2. 原理：为什么二进制里装不下一个干净的 0.1

2.1 双精度到底存了什么

JavaScript 里所有数字都是 IEEE 754 双精度浮点数，64 位，拆开来是 1 位符号位、11 位指数位、52 位尾数位。能精确表示的是形如m × 2^e的数，其中 m 是一个 53 位以内的二进制整数。

问题出在十进制小数转二进制这一步。0.1换成二进制是0.00011001100110011...，0011无限循环，永远写不完。机器只能截到 52 位尾数就停手，剩下那截被舍掉，于是内存里的0.1其实是一个比 0.1 稍大一点点的数，误差量级在 1e-17 左右。

单独看这个误差小到无所谓，但它不是随机噪声，而是一个固定的、系统性的偏移。你把它拿去参与运算，误差会跟着一起被算进去。0.1 + 0.2得到0.30000000000000004，就是这个偏移在加法里被暴露出来的结果。

2.2 乘法为什么把小误差放大

乘法比加法更麻烦的地方在于，误差会随着数值规模变化。你在算0.7 × 0.1时，被乘数和乘数各自都带着一点偏差，相乘之后偏差也相乘、相加，再叠加一次舍入。结果就是0.07000000000000001。

这个误差的量级通常落在小数点后第 16、17 位，属于“正常人不会关心”的范围。可业务代码不这么看：

• 用===比较两个数，差 1e-17 就是不相等；
• 用toFixed(2)再比较字符串，多数时候能过，但遇到 5 的边界就会翻车（下一节细说）；
• 直接把结果丢进模板，用户看到的就是十几个小数位。

所以真正的应对思路不是“消灭误差”——在双精度下消灭不了——而是在误差进入业务判断和界面展示之前，把它拦下来。

2.3 toFixed 为什么也不是灵丹妙药

大部分人的第一反应是.toFixed(2)，这确实能挡掉一大半问题，但它有两个必须知道的坑。

第一个坑是舍入方向不由你决定。toFixed的行为取决于那个数在内存里真实存的是什么，而不是你眼睛看到的十进制字面量。经典例子：

(1.005).toFixed(2) // "1.00"，不是 "1.01" (0.615).toFixed(2) // "0.61"，不是 "0.62" (8.575).toFixed(2) // "8.57"，不是 "8.58"

原因很直白：1.005在内存里实际是1.00499999999999989...，它对第二位小数来说确实该舍。你觉得它该进位，是因为你看到的是十进制写法。

第二个坑是返回值是字符串。"1.00"拿去再参与运算会被隐式转成数字1，末尾的零没了；如果拿去和另一个字符串拼接，就会得到"1.00"拼"2.00"变成"1.002.00"这种鬼东西。接口返回的分数、价格字段经常是字符串形式，直接相加得到字符串拼接结果，这是我在真实项目里见过频率最高的 bug 之一，比浮点误差还常见。

还有一个不太被提及的点：精度参数超过 100 时某些引擎会直接抛RangeError，虽然业务上不会这么写，但如果你把用户输入当精度传进去，就成了一个隐患。

3. 方案选型：四条路线，按场景挑，别一刀切

3.1 路线一：整数化放大法

核心思想很简单：把小数乘上一个 10 的幂变成整数，整数运算在安全范围内是精确的，算完再除回去。0.7 × 0.1变成7 × 1 / 100，结果是0.07，一位不多。

这条路线的优势是不引依赖、体积零增加、执行快，缺点是要自己处理倍数和边界，遇到位数很深的数（比如科学计数法表示的数）会吃力。它最适合的正是我们这类场景：口算题、分数、百分比，数值范围小、小数位少、调用频率高。

3.2 路线二：只在展示层做格式化

如果你确认业务逻辑里所有比较都发生在整数上，只有渲染时需要好看，那最省事的做法是“计算不动，出口统一格式化”。写一个formatNumber(value, precision)塞进 computed 或者预处理函数，所有模板都走它。

这条路成本最低，但它只是遮住了症状。判分逻辑如果还在用===比浮点，问题依然存在。所以我一般建议：展示层格式化必须有，但它不能替代计算层的处理。

3.3 路线三：引入 decimal.js / bignumber.js

这类库用字符串或者数组来存数字，完全绕开二进制浮点，四则运算的结果跟你手算的一致，还支持任意精度和多种舍入模式。金额结算、复杂统计、精度要求高的场景，用它最稳。

代价也要说清楚：包体积增加（decimal.js 压缩后几十 KB 量级，小程序对主包体积敏感的话要掂量）、运算速度比原生慢一到两个数量级、API 需要学习成本。对一个小学口算练习工具来说，为了0.7 × 0.1引入整个大数库，性价比不高。我的判断标准是：出现金额结算、跨表对账、需要精确到分以下、需要处理超过 15 位有效数字的 ID 或订单号，才值得上库。

3.4 路线四：后端算，前端只展示

最后一条容易被忽略：把正确率、平均分、排名这类统计放到服务端算好，前端只负责显示字符串。服务端有 Decimal 类型、有成熟的数值库，还能统一口径，前端不用背这个锅。

适合的场景是统计口径复杂、跨端要一致（小程序、H5、App 三端显示必须完全一样）的项目。缺点是交互型的即时反馈（比如学生做完一道题立刻出对错）不适合走接口，还是得前端自己算。

3.5 选型对照表

我的实际做法是组合拳：计算层用整数化放大，展示层统一格式化，涉及金额或超长数字的地方单独引 decimal，统计口径复杂的走服务端。四条路不冲突，各管一段。

4. 实操：给 uniapp 项目封一套数字工具

4.1 目录约定与导出方式

先在utils/下建一个number.js，所有数值处理都从这里出，页面里禁止直接写.toFixed()和裸的a / b * 100。这条规矩看着死板，但它能挡住 80% 的回归问题——因为一旦出口唯一，改一次就全站生效。

// utils/number.js // 统一数值处理出口，页面层禁止直接使用 toFixed

用 ES module 导出，uniapp 的 Vue2 和 Vue3 版本都支持。如果你项目里还有 CommonJS 的老文件，按需做一层兼容导出即可，不建议两种规范混着写。

4.2 核心代码：取位数、加减乘除

第一步是取小数位数。别用正则去匹配字符串里的点，1e-7这种科学计数法会直接漏掉。基础版按字符串处理，够用且直观：

export function decimalLength(num) { const s = String(num) if (s.includes('e') || s.includes('E')) { // 科学计数法兜底：交给调用方处理，或统一转成定点再算 return 0 } const idx = s.indexOf('.') return idx === -1 ? 0 : s.length - idx - 1 }

接着是乘法和加法。乘法把两个数各自放大成整数，相乘后再按位数之和除回去；加法把两个数放大到同样的位数再加。这里用Math.round而不是parseInt，因为放大过程中0.7 * 10可能得到6.999999999999999，取整会直接丢掉一位。

export function mul(a, b) { const x = Number(a) const y = Number(b) const dx = decimalLength(x) const dy = decimalLength(y) const ix = Math.round(x * Math.pow(10, dx)) const iy = Math.round(y * Math.pow(10, dy)) return (ix * iy) / Math.pow(10, dx + dy) } export function add(a, b) { const x = Number(a) const y = Number(b) const d = Math.max(decimalLength(x), decimalLength(y)) const scale = Math.pow(10, d) return (Math.round(x * scale) + Math.round(y * scale)) / scale } export function sub(a, b) { return add(a, -Number(b)) }

减法直接复用加法并取负，省一份维护成本。这个技巧在处理0.3 - 0.1 = 0.19999999999999998时同样有效。

除法的写法要稍微绕一点，因为不能简单地先放大再除：

export function div(a, b, precision = 4) { const x = Number(a) const y = Number(b) if (y === 0) return NaN const dx = decimalLength(x) const dy = decimalLength(y) const ix = Math.round(x * Math.pow(10, dx)) const iy = Math.round(y * Math.pow(10, dy)) const factor = Math.pow(10, precision) // (x / y) = (ix * 10^dy) / (iy * 10^dx) const numerator = ix * Math.pow(10, dy) const denominator = iy * Math.pow(10, dx) return Math.round((numerator / denominator) * factor) / factor }

最后的Math.round(... * factor) / factor是关键的一步，它把除法结果按指定精度截断，避免把无限小数带进业务。默认给 4 位是我踩出来的经验值：口算场景用 2 位够，正确率类统计用 4 位再展示时降到 1 到 2 位，中间留一点缓冲不会丢信息。

4.3 舍入与格式化：绕开 toFixed 的坑

要解决1.005.toFixed(2)舍错方向的问题，得先把数“扶正”再做舍入。做法是乘完倍数之后，用toPrecision把有效数字收一收，把100.49999999999999变成100.5，再交给Math.round。

export function round(num, precision = 2) { const n = Number(num) if (!isFinite(n)) return 0 const factor = Math.pow(10, precision) const shifted = Number((n * factor).toPrecision(15)) return Math.round(shifted) / factor } export function fixed(num, precision = 2) { return round(num, precision).toFixed(precision) }

toPrecision(15)这个数字不是随便写的。双精度能保证的可靠有效数字是 15 位，取 15 位刚好把尾部那点噪声抹掉，又不会误伤真实数据。如果你把它写成 20，噪声又回来了；写成 10，大数就会被截断。这个参数我在多个项目里验证过，日常业务量级下非常稳。

但必须说清楚它的局限：超过 15 位有效数字的数（比如 19 位的订单号）绝对不能走这条路，那种场景请上 decimal 或者全程按字符串处理。工具的适用边界写不清楚，比没有工具更危险。

百分比单独封一个：

export function percent(part, total, precision = 1) { if (!total) return (0).toFixed(precision) + '%' const rate = div(part, total, precision + 2) * 100 return fixed(rate, precision) + '%' }

注意这里先用div多留两位再乘 100，最后格式化到目标精度。直接part / total * 100再格式化，在part = 2, total = 3时会经过两次误差，虽然结果通常也对，但没必要冒这个险。

4.4 模板里怎么安全地调用

这一步是 uniapp 多端项目最容易翻车的地方，得看你用的是 Vue2 还是 Vue3。

Vue2 版本可以用 filter，写法简洁：

filters: { rateText(v, p = 1) { return fixed(v, p) + '%' } }

模板里{{ score | rateText }}就行。但 filter 在 Vue3 里被移除了，如果你在升级或者新开项目用的是 Vue3 语法，这条路直接断掉。

Vue3 版本我推荐在computed里预处理数据，而不是在模板里调方法：

computed: { displayList() { return this.rawList.map(item => ({ ...item, rateText: percent(item.right, item.total, 1), avgText: fixed(item.avgScore, 1) })) } }

理由有两个。一是在模板里调用 methods 每次重渲染都会执行，列表长的时候性能不划算；二是 uniapp 编译到某些端（尤其是 nvue 页面）时，模板表达式的处理能力有限，复杂函数调用可能不生效或者行为不一致。预处理成纯数据再渲染，是最稳的做法。

还有一类坑来自输入框。v-model.number在小程序端清空输入时会给你空字符串，Number('')得到 0，Number('abc')得到 NaN，后面一路 NaN 传下去，页面上显示NaN%。在提交前做一次兜底：

const val = Number(this.inputValue) const safe = Number.isFinite(val) ? val : 0

Number.isFinite比isNaN严谨，它同时排除Infinity和NaN，也不会像全局isNaN那样做隐式类型转换。

5. 落到乘法口诀练习这个具体业务上

5.1 出题与判分的精度设计

标题后半段提到“大九九乘法口诀表”，这个业务细节值得说清楚：小九九是 1 到 9 中两数相乘且不重复的 45 条，大九九是允许交换顺序的一共 81 条。做练习出题时，如果只练整数乘法，压根不会碰到浮点问题——这也是很多团队上线初期一切正常的原因。

真正的分水岭在练习范围扩展到小数乘法和单位换算之后。这时候判分逻辑必须从“相等比较”改成“容差比较”或者“定点比较”：

export function isSame(a, b, precision = 4) { return fixed(a, precision) === fixed(b, precision) }

四个参数的容差在小数乘法里完全够用，0.07和0.07000000000000001格式化后都是"0.0700"，判定通过。这里千万别图省事用Math.abs(a - b) < 1e-6之外的相对误差方案，对小学生的题目来说，绝对误差更直观也更好调。

出题端也要注意：随机生成小数因子时，别用Math.random() * 10直接当因数，那会生成一长串小数，题目本身就不像小学题。用整数随机再除以 10 或 100，题目才干净：

const factor = Math.floor(Math.random() * 90 + 1) / 10 // 0.1 ~ 9.0

5.2 统计页的数字规范

练习类产品的统计页信息密度高：本次正确率、历史平均分、连对次数、用时、超越百分比。每一处都要定好精度，不要留给开发者临场决定。

我给这类页面定过一套规范，可以直接拿去用：

两个细节。第一，进度条宽度要钳位，Math.min(100, Math.max(0, value))，因为四舍五入和脏数据都可能让它超出 0 到 100 的区间，进度条宽度写成103%会直接撑破布局。第二，除数为 0 的情况必须显式处理，count为 0 时返回--而不是NaN或者Infinity——Infinity.toFixed(1)返回字符串"Infinity"，这个字符串一旦进了模板，用户就看到四个英文字母。

还有个小坑：-0。某些减法算出来是-0，fixed(-0, 1)得到"-0.0"，页面上会显示一个负零。加一句if (Object.is(n, -0)) return 0就能避免，虽然出现频率低，但真出现时排查起来很费劲。

5.3 多端编译的差异要留意

同样的代码，H5、小程序、App 三端表现不一定一致。我遇到过几次差异都集中在两类地方。

一是模板表达式的解析能力。H5 端基于浏览器，模板里怎么算都行；小程序端走的是自己的逻辑层和渲染层通信，表达式里做复杂运算可能出问题，尤其是涉及可选链、模板字符串这类语法，低版本基础库支持不全。所以前面反复强调：把计算挪到 JS 里，模板只绑定结果。

二是输入框的数值类型。H5 上<input type="number">拿到的event.detail.value是字符串，小程序也是字符串，但两者对小数点、负号的过滤策略不同，有的端允许连续输入多个小数点。稳妥做法是在@input里做一次清洗，把非法字符直接挡掉，而不是等提交时才发现Number("1..2")是NaN。

6. 问题排查速查表

6.1 症状对照

排查这类问题最有效的方式不是读代码，而是按症状倒推。

6.2 排查顺序建议

第一步永远是打日志确认源头：console.log(typeof value, value, String(value))，三个信息一起看，能立刻区分“是字符串拼接”还是“是浮点误差”。很多人一上来就怀疑精度，结果查了半天发现是接口把"19.90"当字符串返回了。

第二步是找出口。全项目搜.toFixed(和* 100，把所有出现位置列出来，逐个改成工具函数调用。这一步做完，多数展示类问题当场消失。

第三步才是改计算逻辑。判分、统计这些核心路径，把相等比较改成容差比较，把裸除法改成div，跑一遍边界用例：除以 0、除以 3、0.1 系列、负数、超大数。

第四步回归验证。我习惯把这几组数字写成一个自测函数，改完跑一遍：0.1+0.2、0.7*0.1、1.005舍两位、2/3转百分比、100/0、-0。一分钟的事，能挡住后面几天的返工。

7. 踩过几次坑之后的一些体会

最先想说的是，这类问题的成本大头不在修复，在发现。浮点误差不会让程序崩溃，它只会安静地显示一串不体面的数字，或者悄悄判错一道题。所以最开始做项目时就把数值工具建起来，比出了事故再补要便宜得多。

第二点体会关于“统一出口”的价值。我做过一个统计页，最初每个组件各自toFixed，结果同一份数据在概览卡片里是一位小数，在详情列表里是两位，在导出报表里又变成没有小数。用户不一定会说这是 bug，但他会觉得这个产品“不专业”。后来把所有格式化收到一个文件里，这类不一致一天之内全消失了，改口径也只需要动一处。

第三点是想提醒别过度工程。看到浮点问题的第一反应往往是引一个大而全的库，但对口算练习这种场景，几行整数化代码就够了。库的价值在金额和超长数字上，用错地方就是给自己加体积和心智负担。判断标准前面说过，这里再重复一遍：看数值范围、看精度要求、看是否涉及钱，三个问题问完，选型基本就定了。

最后分享一个实用的小习惯：在number.js顶部写一段注释，把适用边界标清楚——支持多少位、不支持科学计数法、不支持超过 15 位有效数字。这份说明看起来是给别人看的，实际上更主要的作用是提醒三个月后的自己，别在一个本就不该用它的地方硬套。工具用得对，前提是知道它什么时候不对。