在后臺系統(tǒng)里做金額展示的前端同學(xué)大概率都經(jīng)歷過這樣一幕接口返回 1.005代碼里規(guī)規(guī)矩矩寫了個toFixed(2)頁面渲染出來卻是 1.00運營截個圖丟到群里問少的那一分錢去哪了。你去控制臺敲一遍發(fā)現(xiàn)還真是 1.00再敲Math.round(1.005 * 100) / 100得到的是 1一樣不對。于是開始懷疑人生JS 的四舍五入到底怎么回事toFixed是不是有 bug這篇就把 JS 里跟四舍五入、保留小數(shù)相關(guān)的所有東西一次講透Math.round家族的邊界行為、toFixed在規(guī)范層面究竟做了什么、為什么它會在某些數(shù)字上失靈、js里五種保留小數(shù)方案的橫向?qū)Ρ纫约耙粋€可以直接抄走的生產(chǎn)級精確舍入函數(shù)。不管你是剛接觸前端的新手還是寫了幾年業(yè)務(wù)代碼、被金額精度折磨過的老手看完都能對JS 里怎么正確地四舍五入有一套穩(wěn)定的判斷標(biāo)準(zhǔn)而不是出了問題再去搜零散的帖子。1. 為什么 JS 的四舍五入總在關(guān)鍵時刻翻車1.1 先把浮點數(shù)這筆賬算清楚要理解四舍五入為什么不聽話得先接受一個反直覺的事實JS 里所有的 Number 都是 64 位雙精度浮點數(shù)沒有整數(shù)類型也沒有定點小數(shù)類型。它的存儲結(jié)構(gòu)是 1 位符號位、11 位指數(shù)位、52 位尾數(shù)位加起來 64 位。52 位尾數(shù)加上隱含的最高位 1實際能表達(dá) 53 位二進制有效數(shù)字換算成十進制大約是 15 到 17 位有效數(shù)字。問題就出在這里十進制里看著很干凈的小數(shù)比如 0.1、0.2、1.005在二進制下大多數(shù)是無限循環(huán)小數(shù)。就像十進制寫不出 1/3 的精確值一樣二進制也寫不出 0.1 的精確值。0.1 在 double 里真正存的值是0.1000000000000000055511151231257827021181583404541015625它比 0.1 大了一點點。而 0.2 存的值比 0.2 也大了一點點。兩個都偏大的數(shù)相加誤差累積就得到了那個著名的結(jié)果0.1 0.2 // 0.30000000000000004 0.1 0.2 0.3 // false反過來1.005 在 double 里存的值比 1.005小1.00499999999999989341858963598497211933135986328125這個細(xì)節(jié)非常重要后面講toFixed的坑全靠它解釋。你可以用一行代碼自己驗證任意數(shù)字的真實存儲值function exact(n) { // 用足夠多的小數(shù)位把 double 的真實值打出來 return n.toFixed(20); } exact(1.005); // 1.00499999999999989342 exact(2.55); // 2.54999999999999982236 exact(8.575); // 8.57499999999999928946toFixed(20)在規(guī)范允許的范圍內(nèi)0 到 100會把 double 的真實十進制展開輸出雖然末尾會有二次舍入但前 17 位基本可信足夠看清真值到底偏大還是偏小。這個技巧我在排查精度問題時用得最多比憑感覺猜靠譜得多。1.2 三個真實業(yè)務(wù)里的翻車現(xiàn)場場景一金額計算。電商訂單里商品單價 19.9 元買 3 件19.9 * 3得到 59.699999999999996。如果你直接toFixed(2)展示結(jié)果倒是能看59.70但如果中間參與的是滿減判斷這類邏輯比如判斷是否大于 59.7就會得到false優(yōu)惠券不發(fā)用戶投訴。這類問題最麻煩的地方在于它偶發(fā)——大部分?jǐn)?shù)字碰巧是對的只有特定組合才炸測試環(huán)境不一定復(fù)現(xiàn)得出來。場景二成績與統(tǒng)計。學(xué)生總分 84.5 分按四舍五入取整應(yīng)該是 85但如果總分是0.1 0.2 84.2累加出來的真實值可能是 84.49999999999999取整變成 84。學(xué)生來找你你打開控制臺一看明明是 84.5 啊。這時候你得知道你看到的 84.5 只是toString做了最短往返表示后的結(jié)果真實值不是它。場景三百分比與比例分?jǐn)偂?00 元按 3 個人平均分每人 33.33 元加起來 99.99少了一分錢。這個問題本質(zhì)上跟浮點數(shù)無關(guān)是分?jǐn)偤笥鄶?shù)歸屬的算法問題但只要涉及保留兩位小數(shù)就一定繞不開舍入函數(shù)的選型。誰該承擔(dān)那一分錢取決于業(yè)務(wù)規(guī)則代碼里必須顯式處理。這三個場景有個共同點出錯的從來不是四舍五入這個動作本身而是參與四舍五入的那個數(shù)到底是多少。想清楚這一點后面所有的坑都能自己推出來。2. toFixed() 的完整行為拆解2.1 規(guī)范層面 toFixed 究竟做了什么很多人把toFixed當(dāng)成四舍五入工具其實它的規(guī)范定義比這精細(xì)得多。ECMAScript 規(guī)范里Number.prototype.toFixed(fractionDigits)的執(zhí)行步驟大致是這樣對fractionDigits做ToIntegerOrInfinity如果結(jié)果不在 0 到 100 之間含拋RangeError。令x為這個 Number 的數(shù)值。如果x不是有限數(shù)NaN 或 Infinity直接返回ToString(x)。如果x的絕對值大于等于 10^21直接返回ToString(x)。否則令n為一個整數(shù)使得n / 10^f與x在數(shù)值上最接近如果存在兩個這樣的n與x距離相等取較大的那個 n。按十進制格式輸出小數(shù)位不足f位時補零。關(guān)鍵在于第 4 步它比較的是n / 10^f與x的真實數(shù)值而x是那個有二進制誤差的 double。所以toFixed的舍入依據(jù)不是人類看到的十進制字符串而是內(nèi)存里那個真實的近似值。拿 1.005 舉例。x的真實值是 1.00499999999999989...保留兩位時候選的n是 100 和 101候選 nn / 100與 x 的距離1001.000.004999999999999891011.010.00500000000000010100 更近所以輸出1.00。從內(nèi)存里的數(shù)值這個角度看toFixed完全正確一點沒算錯。只不過它不是你要的那個四舍五入——你要的是對十進制字面量 1.005 做舍入它給的是對 1.00499999999999989 做舍入。這是兩種完全不同的需求toFixed只滿足后一種。而 1.035 恰好相反它在 double 里存的值是 1.03500000000000003...比 1.035 大所以(1.035).toFixed(2)會給出1.04。同一個寫法在不同的數(shù)字上一個偏小一個偏大表現(xiàn)出來就像是隨機失靈這是所有人第一次踩坑時最迷惑的地方。2.2 破除一個流傳很廣的誤解toFixed 不是銀行家舍入網(wǎng)上有大量文章說toFixed用的是銀行家舍入round half to even所以 1.005 變成 1.00、2.5 變成 2。這個說法是錯的而且錯得挺離譜照著這個理解去寫代碼會踩更大的坑。銀行家舍入的規(guī)則是恰好在中點時取最近的偶數(shù)。而toFixed的規(guī)范明確寫著距離相等時取較大的 n也就是標(biāo)準(zhǔn)的 round half up向正無窮方向的半值進位。用一組數(shù)字就能驗證(0.5).toFixed(0); // 1 如果是 half-even0.5 應(yīng)該進位到 0 (1.5).toFixed(0); // 2 如果是 half-even1.5 應(yīng)該變成 2碰巧一致 (2.5).toFixed(0); // 3 如果是 half-even2.5 應(yīng)該變成 2 (3.5).toFixed(0); // 4 如果是 half-even3.5 應(yīng)該變成 4碰巧一致如果真是銀行家舍入(0.5).toFixed(0)必須是0、(2.5).toFixed(0)必須是2。實測都不是。這些數(shù)字有個共同特點它們在二進制里都能精確表示沒有誤差所以能干凈地反映規(guī)范里的規(guī)則。真正會翻車的 1.005、2.55 之所以看起來像銀行家舍入純粹是因為它們的 double 真值恰好落在中點的下方跟舍入模式毫無關(guān)系。理解了這個區(qū)別你排查問題時的思路就完全不一樣了看到toFixed結(jié)果不對第一反應(yīng)不該是它用了什么奇怪模式而應(yīng)該是這個數(shù)字在內(nèi)存里到底是幾然后toFixed(20)打出來看看。2.3 參數(shù)邊界、返回類型與幾個必須知道的使用限制toFixed還有一堆容易忽略的細(xì)節(jié)我整理成一張表情況行為示例參數(shù)小于 0 或大于 100拋RangeError(1).toFixed(101)報錯參數(shù)是小數(shù)先截斷成整數(shù)(1.23).toFixed(1.9)等價于toFixed(1)得1.2參數(shù)是undefined按 0 處理(1.6).toFixed()得2數(shù)值絕對值 ≥ 1e21退化成toString(1e21).toFixed(2)得1e21是 NaN / Infinity原樣輸出字符串(NaN).toFixed(2)得NaN小數(shù)位不足補零到指定位數(shù)(1).toFixed(3)得1.000返回類型始終是字符串(1.005).toFixed(2) 1得1.001最后一條是新手最常犯的錯誤。toFixed返回的是 String如果直接參與算術(shù)運算會觸發(fā)隱式類型轉(zhuǎn)換如果參與運算會變成字符串拼接(0.1).toFixed(2) (0.2).toFixed(2); // 0.100.20不是 0.3 Number((0.1).toFixed(2)) Number((0.2).toFixed(2)); // 0.30000000000000004還有個小語法坑數(shù)字字面量后面直接跟點號會被解析成小數(shù)點1.toFixed(2)會報語法錯誤。正確寫法是(1).toFixed(2)或者1..toFixed(2)。我在代碼評審里見過不止一次這個失誤特別是寫測試用例的時候。一般建議全程用括號包裹可讀性也更好。3. Math 家族整數(shù)舍入的四種姿勢與半值陷阱3.1 Math.round 對負(fù)數(shù)的詭異行為Math.round的規(guī)范是返回最接近的整數(shù)如果兩個整數(shù)距離相等取較大的那個即向 ∞ 方向。這條規(guī)則對正數(shù)符合直覺對負(fù)數(shù)就會產(chǎn)生一個讓所有人第一次見都愣住的后果Math.round(0.5); // 1 Math.round(1.5); // 2 Math.round(-0.5); // -0 注意是負(fù)零 Math.round(-1.5); // -1 不是 -2 Math.round(-2.5); // -2 Math.round(-0.4); // -0 Math.round(-0.6); // -1Math.round(-0.5)返回的是-0一個符號位為負(fù)的零。Object.is(-0, 0)為 false-0 0為 trueJSON.stringify(-0)輸出0但它出現(xiàn)在除法里會得到-Infinity。這些特性湊在一起在取整后做分母的場景里能整出很隱蔽的 bug建議拿到結(jié)果后統(tǒng)一過一遍x 0或者Object.is判斷把負(fù)零規(guī)范化掉。Math.round(-1.5)返回 -1 這件事在業(yè)務(wù)上經(jīng)常是錯的。用戶直覺是負(fù)一點五四舍五入到負(fù)二代碼給的卻是 -1。如果你的業(yè)務(wù)涉及負(fù)數(shù)金額退款、負(fù)數(shù)庫存并且要求對稱的遠(yuǎn)離零舍入Math.round不能直接用必須先取絕對值處理再補回符號。3.2 floor / ceil / trunc 的選擇邏輯四個取整函數(shù)的分工用一張表最清楚。取x分別為 1.7、-1.7函數(shù)含義f(1.7)f(-1.7)典型用途Math.round就近取整半值向 ∞2-2通用取整正數(shù)場景Math.floor向下向 -∞取整1-2分頁、桶排序、按天歸檔Math.ceil向上向 ∞取整2-1分頁總頁數(shù)、分片數(shù)量Math.trunc截斷小數(shù)部分1-1去掉小數(shù)、不支持時的兜底最容易混的是floor和trunc正數(shù)時兩者一樣負(fù)數(shù)時floor(-1.7) -2而trunc(-1.7) -1。Math.trunc是 ES6 加入的老環(huán)境沒有可以用x 0 ? Math.ceil(x) : Math.floor(x)兼容。分頁是ceil最經(jīng)典的用場?？倵l數(shù) 101、每頁 20 條Math.ceil(101 / 20)得 6 頁。但這里有個隱藏問題如果總條數(shù)是浮點計算出來的比如按比例估算得到100.00000000000001ceil會給你 6 頁而實際只需要 5 頁頁面上就多出一個空白頁。所以凡是ceil之前的除法結(jié)果最好先做一次精度收斂比如Math.ceil((total / size).toFixed(10))。3.3 用 Math.round 保留小數(shù)為什么還是不準(zhǔn)最廣為人知的保留兩位小數(shù)寫法是這樣的const round2 (n) Math.round(n * 100) / 100; round2(1.005); // 1期望 1.01 round2(2.675); // 2.67期望 2.68為什么還是錯因為n * 100這一步引入了新的浮點誤差。1.005 在內(nèi)存里是 1.00499999999999989乘以 100 之后二進制乘法的結(jié)果舍入到最近的 double得到 100.49999999999999 而不是 100.5。于是Math.round只能進位到 100除以 100 又是 100 / 100而 100 / 100 的二進制除法結(jié)果正好是 1得到 1。換句話說這條鏈路上有兩個獨立的誤差源原始數(shù)字的表示誤差以及中間乘除法的舍入誤差。你想控制舍入行為卻讓兩次不可控的浮點運算夾在中間結(jié)果自然不穩(wěn)定。要精確舍入核心思路是減少參與二進制運算的環(huán)節(jié)后面幾節(jié)的所有方案都是圍繞這個原則設(shè)計的。4. 五種保留小數(shù)的實現(xiàn)方案橫向?qū)Ρ?.1 指數(shù)位移法改動最小、收益最大的寫法先說結(jié)論日常業(yè)務(wù)里指數(shù)位移法也有人叫e計數(shù)法是改動量最小、穩(wěn)定性提升最大的方案。原理很樸素——把乘以 10 的 n 次方從浮點運算換成字符串解析function roundByExponent(value, digits 2) { const shifted Number(${value}e${digits}); const rounded Math.round(shifted); return Number(${rounded}e-${digits}); } roundByExponent(1.005, 2); // 1.01 roundByExponent(2.55, 1); // 2.6 roundByExponent(1.005 * 100 / 100, 2); // 1第三行說明了一個重要的邊界這個方法修的是位移引入的誤差修不了value 本身已經(jīng)是臟的。1.005 * 100 / 100的結(jié)果雖然打印出來是 1.005但它的 double 真值已經(jīng)不是 1.005 了乘除過程中又丟了一次精度再位移也沒用。所以這個方案的適用前提是你要舍入的那個數(shù)字來自用戶輸入或接口的十進制字符串還沒被算過。它為什么有效因為${value}會調(diào)用Number.prototype.toString輸出最短往返表示就是那個能唯一還原 double 的、位數(shù)最少的十進制字符串。Number(1.005e2)解析時按十進制字符串 100.5 精確計算而 100.5 恰好是二進制可精確表示的100.5 100 0.5 1100100.1?于是拿到干凈的 100.5。相比1.005 * 100走二進制乘法路徑字符串解析這條路上的十進制語義被保留了。這個方法也不是萬能的。它有四個明確的限制超過Number.MAX_SAFE_INTEGER9007199254740991的大數(shù)位移后同樣丟精度。digits超過 15 左右基本沒意義double 的有效位就那么些。value本身如果已經(jīng)是被算臟的浮點數(shù)救不回來。負(fù)數(shù)要單獨處理因為Math.round的半值方向不對稱。4.2 字符串法徹底擺脫二進制誤差如果你要的是跟用戶看到的一模一樣的舍入結(jié)果最徹底的辦法是全程不碰浮點數(shù)把數(shù)字當(dāng)字符串操作。思路是拆出整數(shù)部分和小數(shù)部分看第digits 1位是不是大于等于 5是就用字符串加法進位。整條鏈路只有字符處理和整數(shù)加法不存在任何精度損失。// 字符串加法只用于純數(shù)字串 function incString(s) { const arr s.split(); let i arr.length - 1; while (i 0) { if (arr[i] 9) { arr[i] 0; i--; } else { arr[i] String(Number(arr[i]) 1); break; } } if (i 0) arr.unshift(1); return arr.join(); } // 把各種輸入歸一化成 { sign, intPart, fracPart } function normalize(input) { const s String(input).trim(); const m /^([-]?)(\d)(?:\.(\d))?(?:[eE]([-]?\d))?$/.exec(s); if (!m) throw new TypeError(不是合法的十進制數(shù)字: ${input}); const sign m[1] - ? - : ; const intPartRaw m[2]; const fracPartRaw m[3] || ; const exp m[4] ? Number(m[4]) : 0; const all intPartRaw fracPartRaw; const pointIdx intPartRaw.length exp; let intPart, fracPart; if (pointIdx 0) { intPart 0; fracPart 0.repeat(-pointIdx) all; } else if (pointIdx all.length) { intPart all 0.repeat(pointIdx - all.length); fracPart ; } else { intPart all.slice(0, pointIdx); fracPart all.slice(pointIdx); } intPart intPart.replace(/^0(?\d)/, ) || 0; return { sign, intPart, fracPart }; }normalize處理了科學(xué)計數(shù)法輸入、前導(dǎo)零、純小數(shù).5這種等情況輸出三段結(jié)構(gòu)符號、整數(shù)部分、小數(shù)部分。有了它舍入就是純粹的位操作。4.3 五種方案橫向?qū)Ρ仍诮o出完整的舍入函數(shù)之前先把市面上的方案擺在一起看。測試輸入統(tǒng)一為1.005保留兩位方案代碼結(jié)果是否達(dá)標(biāo)適用場景直接 toFixed(1.005).toFixed(2)1.00否僅用于純展示、數(shù)據(jù)來源可信乘除 Math.roundMath.round(1.005*100)/1001否不推薦誤差源最多指數(shù)位移法Number(${1.005}e2)后回退1.01是日常業(yè)務(wù)輸入未被污染字符串法逐位判斷進位1.01是金額、精度敏感場景Intl 格式化Intl.NumberFormat1.00否純展示仍受 double 真值影響關(guān)于最后一行需要補充說明Intl.NumberFormat的默認(rèn)舍入模式roundingMode是halfExpand半值遠(yuǎn)離零規(guī)則本身比toFixed更符合業(yè)務(wù)直覺但它依然是在 double 真值上做舍入。1.005在內(nèi)存里小于 1.005格式化出來照樣是1.00。所以它適合做最后一公里的展示不適合做參與后續(xù)計算的值。選型建議很直接展示且數(shù)據(jù)可信用Intl.NumberFormat需要參與計算或?qū)扔幸笥米址ń橛趦烧咧g、想低成本改造用指數(shù)位移法。5. 手寫一個生產(chǎn)可用的精確舍入函數(shù)5.1 設(shè)計取舍為什么采用遠(yuǎn)離零而不是向正無窮前面提到Math.round(-1.5)返回 -1而業(yè)務(wù)上大多數(shù)人對負(fù)數(shù)的直覺是 -2。我在寫通用舍入函數(shù)時選擇了round half away from zero半值遠(yuǎn)離零理由是對稱性round(1.5) 2且round(-1.5) -2正負(fù)對稱財務(wù)對賬時不會出現(xiàn)借方貸方規(guī)則不一致的問題。符合直覺非技術(shù)同事看到 -0.5 變成 -1 不會有疑問看到 0 反而會來問。和主流語言一致很多語言和數(shù)據(jù)庫的默認(rèn)舍入都是 half away from zero前后端聯(lián)調(diào)時省事。但要注意它不是所有場景的最優(yōu)解。如果是分?jǐn)傤悩I(yè)務(wù)100 元分 3 份理論最優(yōu)是讓每個人承擔(dān)的平均誤差最小通常的做法是先算基礎(chǔ)值余數(shù)按規(guī)則補給特定人跟舍入模式關(guān)系不大。如果是統(tǒng)計報表、科學(xué)計算可能更希望用銀行家舍入half to even來減少長序列求和的累積偏差。選哪種取決于業(yè)務(wù)但必須顯式選定并寫進代碼注釋最怕的就是我以為是四舍五入你以為是截斷。5.2 完整代碼實現(xiàn)基于前面的normalize和incString補上舍入主體/** * 精確舍入半值遠(yuǎn)離零 * param {string|number} input - 待舍入的值推薦傳字符串 * param {number} digits - 保留的小數(shù)位數(shù)0 ~ 100 * returns {string} 舍入后的十進制字符串 */ function roundExact(input, digits 0) { if (!Number.isInteger(digits) || digits 0 || digits 100) { throw new RangeError(digits 必須是 0 到 100 之間的整數(shù)); } const { sign, intPart, fracPart } normalize(input); const full intPart fracPart; // 去掉小數(shù)點后的全部數(shù)字 const pointIdx intPart.length; // 小數(shù)點在 full 中的位置 const keepLen pointIdx digits; // 需要保留的數(shù)字個數(shù) let kept; if (keepLen full.length) { kept full 0.repeat(keepLen - full.length); } else { kept full.slice(0, keepLen); if (Number(full[keepLen]) 5) kept incString(kept); } let out; if (digits 0) { out kept; } else { const cut kept.length - digits; out kept.slice(0, cut) . kept.slice(cut); } out out.replace(/^0(?\d)/, ); const isZero /^0(\.0*)?$/.test(out); return (sign - !isZero ? - : ) out; }再包一層返回 Number 的版本方便需要參與計算的場合function roundExactToNumber(input, digits 0) { return Number(roundExact(input, digits)); }5.3 測試用例與邊界驗證寫精度相關(guān)的工具函數(shù)我最看重的不是實現(xiàn)有多巧妙而是測試用例覆蓋得夠不夠狠。下面這組是我實際項目里在用的直接抄進單測就能跑const cases [ [1.005, 2, 1.01], [2.55, 1, 2.6], [8.575, 2, 8.58], [0.145, 2, 0.15], [1.004999, 2, 1.00], [9.995, 2, 10.00], // 進位后整數(shù)位增加 [99.999, 2, 100.00], [-1.5, 0, -2], // 半值遠(yuǎn)離零 [-0.5, 0, -1], [-0.4, 0, 0], // 結(jié)果為零時不帶負(fù)號 [0, 2, 0.00], [1, 3, 1.000], // 位數(shù)不足補零 [0.5, 0, 1], [.5, 1, 0.5], [1.5e2, 1, 150.0], // 科學(xué)計數(shù)法輸入 [1.23456789e-3, 5, 0.00123], [000123.456, 1, 123.5], // 前導(dǎo)零 ];有幾個用例值得單獨說9.995保留兩位得到10.00這是進位后位數(shù)進位的經(jīng)典場景。很多簡化實現(xiàn)只處理了末位加一遇到9不會往前進位結(jié)果輸出9.10這種離譜的東西。incString里的while循環(huán)就是為這個寫的。-0.4保留零位應(yīng)該輸出0不能輸出-0。字符串法天然不產(chǎn)生負(fù)零因為是字符串拼接但如果你把這個結(jié)果Number()一下Number(0)是正零沒問題而如果實現(xiàn)里用-0去算就可能帶出負(fù)零。這個isZero判斷就是專門防這個的。1.23456789e-3保留五位得到0.00123驗證科學(xué)計數(shù)法展開邏輯。normalize里pointIdx intPartRaw.length exp這一行是關(guān)鍵1.23456789e-3中intPartRaw 1all 123456789exp -3pointIdx 1 - 3 -2落到pointIdx 0分支前面補兩個零得到0.00123456789。邏輯是對的。6. 金額與業(yè)務(wù)場景的落地建議6.1 存儲層用整數(shù)分是最省心的架構(gòu)選擇前面所有的討論都建立在一個前提上你得在某個時刻把一個十進制小數(shù)交給 JS 的 Number。而最徹底的解決方案其實是根本不這么做。金額場景下我的建議是數(shù)據(jù)庫用DECIMAL(18,2)或者BIGINT存分絕對不用FLOAT/DOUBLE。接口傳字符串19.90或者傳整數(shù)分1990。傳 Number 是給未來埋雷。前端狀態(tài)如果傳的是分全程用整數(shù)運算只在渲染的最后一步除以 100。渲染roundExact(cents / 100, 2)或者用Intl.NumberFormat對cents / 100格式化。為什么整分存儲這么有效因為 double 能精確表示的整數(shù)范圍到了 2^53也就是 9007199254740991換算成分是 90 萬億元任何正常業(yè)務(wù)都用不完。在這個范圍內(nèi)加減乘都是精確的不存在任何舍入問題。把小數(shù)問題消滅在數(shù)據(jù)入口比在數(shù)據(jù)出口做補救要可靠得多。如果接口實在只能給小數(shù)也要在解析的第一時間轉(zhuǎn)成分function yuanToCents(input) { // 先按字符串處理再轉(zhuǎn)整數(shù)避免 19.9 * 100 1989.9999999999998 const s String(input).trim(); const str roundExact(s, 2); // 先對齊到兩位 const [i, f ] str.split(.); const sign i.startsWith(-) ? -1 : 1; return sign * (Math.abs(Number(i)) * 100 Number(f.padEnd(2, 0))); } yuanToCents(19.9); // 1990 yuanToCents(-0.015); // -2半值遠(yuǎn)離零 yuanToCents(19.9 * 3); // 5970最后一行值得注意19.9 * 3是59.699999999999996roundExact對齊兩位得到59.70再轉(zhuǎn)分是 5970。如果你直接Math.round(19.9 * 3 * 100)得到的是Math.round(5969.999999999999) 5970碰巧也對但換個數(shù)字就不一定了。用字符串法走一遍邏輯上是確定的。6.2 展示層的格式化選型展示層的選擇取決于三件事要不要千分位、要不要貨幣符號、要不要處理多語言。只做基礎(chǔ)保留兩位roundExact輸出字符串就夠了。需要加千分位最省事的是Intl.NumberFormatconst fmt new Intl.NumberFormat(zh-CN, { minimumFractionDigits: 2, maximumFractionDigits: 2, }); fmt.format(1234567.891); // 1,234,567.89Intl.NumberFormat的舍入模式默認(rèn)是halfExpand規(guī)則本身是合理的但依然基于 double 真值。所以如果輸入是算出來的數(shù)先roundExact一遍再交給它格式化兩條防線疊加最穩(wěn)。如果輸入本來就是整分可以自己拼function formatCents(cents) { const sign cents 0 ? - : ; const abs Math.abs(cents); const yuan Math.floor(abs / 100); const fen String(abs % 100).padStart(2, 0); const withSep String(yuan).replace(/\B(?(\d{3})(?!\d))/g, ,); return ${sign}${withSep}.${fen}; } formatCents(123456789); // 1,234,567.89 formatCents(-1990); // -19.90這個函數(shù)全程整數(shù)運算沒有任何浮點參與\B(?(\d{3})(?!\d))是給整數(shù)部分加千分位的經(jīng)典正則。它還有個額外好處不依賴Intl在任何 JS 環(huán)境里行為完全一致包括各種小程序和嵌入式 JS 引擎比如js宏這類自動化腳本環(huán)境里Intl的支持情況常常不完整。6.3 什么時候該引入專業(yè)庫自己寫一套精度工具好處是體積小、可控、沒有依賴代價是要自己維護測試用例而且只覆蓋了舍入這一個環(huán)節(jié)。什么情況下該上專業(yè)庫判斷標(biāo)準(zhǔn)是如果業(yè)務(wù)涉及多步運算加減乘除混合、需要可配置的舍入模式和精度、或者要處理非常大的數(shù)就應(yīng)該上庫。原因很簡單舍入只是浮點問題的冰山一角真正難的是(a b) * c / d這種表達(dá)式鏈上的誤差傳播自己手寫會沒完沒了地打補丁。常見的幾類方案方案類型思路適合場景任意精度十進制庫用字符串或數(shù)組模擬十進制運算金融、計費、報表大整數(shù)方案全程整數(shù)運算手動管理小數(shù)點位置已有整分存儲的架構(gòu)內(nèi)置國際化格式化只負(fù)責(zé)展示層純前端展示數(shù)據(jù)可信服務(wù)端計算精度敏感邏輯放服務(wù)端前后端分離的成熟系統(tǒng)最后一行其實是最容易被忽略、但工程上最靠譜的方案。凡是涉及錢的計算如果服務(wù)端能算就別在前端算。前端拿到的應(yīng)該是已經(jīng)算好的、可以直接展示的結(jié)果前端只負(fù)責(zé)格式化和交互。這條原則能消滅掉 90% 的精度事故。7. 常見問題速查與排查技巧7.1 十二個高頻問題速查表這張表是我這幾年被問得最多的問題匯總遇到問題先查表現(xiàn)象根本原因處理辦法1.005.toFixed(2)得1.00double 真值略小于 1.005用字符串法或先轉(zhuǎn)分做整數(shù)運算Math.round(1.005*100)/100得1乘法引入新誤差換指數(shù)位移法Number(1.005e2)0.1 0.2 ! 0.3二進制無法精確表示用Math.abs(a-b) 1e-10比較0.3 - 0.1得0.19999999999999998同上轉(zhuǎn)成分整數(shù)再運算toFixed返回值參與加法變成拼接返回 String 類型用Number()或parseFloat()包一層(1e21).toFixed(2)得1e21超過 1e21 退化成toString大數(shù)場景用字符串法Math.round(-0.5)得-0規(guī)范定義半值向 ∞結(jié)果加 0 或用Object.is判斷Math.round(-1.5)得-1同上需要對稱舍入時先取絕對值大整數(shù)相加結(jié)果末位變了超過Number.MAX_SAFE_INTEGER用BigInt處理1.toFixed(2)報語法錯誤點號被解析成小數(shù)點寫(1).toFixed(2)累加 1000 筆金額后總額差幾分每次舍入都有偏差誤差累積全程整分累加最后一次性格式化Vue / React 里 computed 每次結(jié)果不同中間某處產(chǎn)生了負(fù)零或不同精度在數(shù)據(jù)源統(tǒng)一轉(zhuǎn)分禁止小數(shù)進狀態(tài)7.2 我實際踩過的幾個坑第一個坑把toFixed當(dāng)成了四舍五入。這是我最早做電商項目時犯的錯。當(dāng)時線上跑得好好的因為大部分價格乘數(shù)量之后的小數(shù)位恰好不落在中點上。上線一個促銷活動某款商品單價 8.575 元、買 3 件按規(guī)則該打 9 折前后端算出來的應(yīng)付金額差了一分錢對賬對不上。后來把整條鏈路改成接口傳分、前端整數(shù)運算問題就再沒出現(xiàn)過。教訓(xùn)是toFixed不是舍入函數(shù)是格式化函數(shù)這兩個角色的職責(zé)要分清楚。第二個坑用toFixed做相等判斷。曾經(jīng)寫過這樣的代碼判斷兩個價格是否相等if (a.toFixed(2) b.toFixed(2)) { /* 認(rèn)為相等 */ }但字符串比較會踩字母順序的坑而且精度上也不對比如1.005和1.004保留兩位都得到1.00或1.00與1.00看起來相等但其實差了 0.001。這個判斷后來被替換成了整數(shù)分比較邏輯清爽了很多。第三個坑在 Vue 的 computed 里做浮點累加。購物車總價用reduce累加每個商品的小計每個小計都是小數(shù)。由于計算屬性會在依賴變化時重新求值實時輸出上看著是 199.99 還是 200取決于數(shù)據(jù)更新的順序和緩存命中的情況。用戶刷新頁面看到的總價跟下單頁面的總價不一致。最后改成每個小計存分總價用整數(shù)累加只在一處格式化徹底消掉了這類隨機性。第四個坑忘了負(fù)零。退款場景里Math.round(-0.4)得到-0直接用來做JSON.stringify時輸出0但用它做除數(shù)會得到-Infinity在分頁計算里把 pageSize 算成負(fù)數(shù)后端接口直接報錯。后來我在所有取整函數(shù)的出口統(tǒng)一加了一句x 0把負(fù)零規(guī)范化成正零簡單粗暴但有效。7.3 排查精度問題的三步法最后分享一套我現(xiàn)在排查精度問題的固定流程比漫無目的地翻代碼快很多第一步先看數(shù)據(jù)源。打開 Network 面板找到出問題的那個字段看接口返回的原始類型。如果返回的是 Number 且小數(shù)位數(shù)超過 2 位問題大概率在傳輸層。如果返回的是字符串看看有沒有被前端某處Number()或parseFloat()轉(zhuǎn)掉。第二步把中間的每一步都打印出來。用toFixed(20)看每一步的真實值別用console.log直接看它會走最短往返表示把小的誤差藏起來const step (label, v) console.log(label, typeof v, v, 真值:, Number(v).toFixed(20)); step(接口原始, raw); step(轉(zhuǎn)數(shù)字后, Number(raw)); step(乘以數(shù)量, Number(raw) * qty); step(舍入后, roundExactToNumber(raw, 2) * qty);我給這個step函數(shù)寫過好幾次后來干脆抽成了項目里的調(diào)試工具。它能一眼看出是哪一步開始偏的比打斷點看變量快得多。第三步定位到具體環(huán)節(jié)后再決定改法。如果是數(shù)據(jù)源問題推后端改類型如果是中間計算問題把這段換成整數(shù)分運算如果只是最后一公里展示問題加一個roundExact就夠了。不要一上來就把全鏈路都換成十進制庫那樣改動面太大、風(fēng)險太高而且往往解決不了真正的問題。我見過有團隊為了一個展示層的舍入問題引入了完整的精度庫包體積漲了幾十 KB結(jié)果因為用法不對問題還在。順帶說一句ES2020 起全面支持的BigInt在金額整數(shù)運算里非常好用尤其是需要處理超過 2^53 的場景。BigInt不支持小數(shù)但支持任意大的整數(shù)所以配合整分存儲的思路正好互補。唯一要注意的是它不能和 Number 混用1n 1會直接拋TypeError必須寫成1n 1n在類型轉(zhuǎn)換那一層要格外小心。