前陣子在把項(xiàng)目從 Android/iOS 雙端往鴻蒙端遷移時(shí)團(tuán)隊(duì)里吵了三次架核心原因全是“數(shù)字顯示不一致”同一個(gè) 1234567.8iOS 上顯示￥1,234,567.80Android 上顯示￥1,234,567.8同一個(gè) 0.126有的端是 12.6%有的端是 13%。問(wèn)題的根子不是 UI 沒(méi)對(duì)齊而是每個(gè)端各自維護(hù)了一套格式化邏輯格式規(guī)則、舍入策略、空值兜底全不統(tǒng)一。后來(lái)我們借著 React Native 鴻蒙適配的契機(jī)把貨幣格式化formatCurrency和百分比格式化formatPercent兩個(gè)工具函數(shù)徹底收斂到了 JS 層做成了一套跨端共用的核心資產(chǎn)。這篇文章就把當(dāng)時(shí)的完整設(shè)計(jì)思路、實(shí)現(xiàn)代碼、踩坑過(guò)程和測(cè)試方案都放出來(lái)給同樣在搞 React Native 鴻蒙跨端、尤其是金融類應(yīng)用的團(tuán)隊(duì)一個(gè)可以直接參考的樣板。1. 為什么金融應(yīng)用的“數(shù)字顯示”值得專門抽一層工具沉淀很多團(tuán)隊(duì)一開(kāi)始都覺(jué)得格式化不就是toFixed(2)加個(gè)逗號(hào)不值得單獨(dú)做一層。這個(gè)想法在普通工具類 App 里問(wèn)題不大但在金融類應(yīng)用里數(shù)字顯示絕不是 UI 小事它是數(shù)據(jù)正確性的最后一道防線。1.1 金額和百分比出錯(cuò)不是 UI 瑕疵是事故金融應(yīng)用里金額和百分比直接關(guān)聯(lián)到用戶資產(chǎn)、收益、費(fèi)率、還款計(jì)劃等關(guān)鍵信息。一個(gè)￥1,234,567.80如果被格式化成￥1,234,567.8用戶可能覺(jué)得只是顯示風(fēng)格不一致但如果是利率從3.45%被顯示成3.5%用戶會(huì)認(rèn)為平臺(tái)擅自改了他的利率這事直接上升到客訴和合規(guī)層面。更隱蔽的是舍入規(guī)則不一致。同一筆0.005元的利息A 端四舍五入成0.01B 端直接截?cái)喑?.00兩邊對(duì)賬對(duì)不上查半天才發(fā)現(xiàn)是格式化層的差異。這類問(wèn)題在金融項(xiàng)目里就不是“顯示 bug”而是資金對(duì)賬事故。所以把格式化邏輯收斂到一處首要?jiǎng)訖C(jī)是保證跨端行為一致。1.2 多端重復(fù)實(shí)現(xiàn)帶來(lái)的連鎖問(wèn)題在沒(méi)有鴻蒙之前不少金融團(tuán)隊(duì)的現(xiàn)狀是Android 用DecimalFormatiOS 用NumberFormatterWeb 端用Intl.NumberFormat三段代碼各自維護(hù)規(guī)則還經(jīng)常不一樣。Android 的DecimalFormat(#,##0.00)和 iOS 的NumberFormatter在舍入行為上雖然都遵循四舍五入但遇到浮點(diǎn)精度問(wèn)題、負(fù)數(shù)格式括號(hào)還是負(fù)號(hào)、貨幣符號(hào)前后置這些細(xì)節(jié)很容易各搞各的。再加上不同產(chǎn)品經(jīng)理在不同時(shí)期提出不同需求比如 A 端要求-$100.00B 端要求($100.00)兩邊代碼越來(lái)越分叉。鴻蒙端加入之后這個(gè)問(wèn)題被放大了三倍鴻蒙原生用的是 ArkTS格式化能力儲(chǔ)備和生態(tài)成熟度都不如 Android/iOS再寫第四套TextFormatter邏輯維護(hù)成本直接失控。我們當(dāng)時(shí)算過(guò)一筆賬四個(gè)端各自維護(hù)格式化代碼每次格式規(guī)則調(diào)整的排期成本是 4 天而統(tǒng)一到 JS 層后是 1 天。1.3 React Native 鴻蒙架構(gòu)下JS 層是收斂的天然位置選擇把格式化工具收斂到 JS 層不是因?yàn)椤癛eact Native 本來(lái)就是這么寫的”而是因?yàn)檫@個(gè)位置有天然優(yōu)勢(shì)不管最終運(yùn)行在 iOS、Android 還是鴻蒙上RN 的 JS 引擎層都能執(zhí)行同一份代碼。只要團(tuán)隊(duì)約定“所有金額和百分比必須走 formatCurrency / formatPercent 這兩個(gè)函數(shù)”三端行為一致性就由代碼結(jié)構(gòu)保證了而不是靠 Code Review 時(shí)人工提醒。同時(shí)要注意React Native 在鴻蒙上通常跑在 ArkTS 運(yùn)行時(shí)提供的 JS 引擎里比如借助鴻蒙的兼容層方案雖然底層引擎可能不同但如果我們的格式化工具不依賴任何原生能力、不依賴Intl的不穩(wěn)定行為單純用純 JS/TypeScript 實(shí)現(xiàn)就幾乎不受宿主引擎差異影響。這一點(diǎn)在后面第 4 章會(huì)詳細(xì)展開(kāi)。2. formatCurrency把錢顯示對(duì)從理解需求邊界開(kāi)始寫 formatCurrency 之前我建議先別急著寫代碼而是把業(yè)務(wù)需求完整列一遍。貨幣格式化的完整要素遠(yuǎn)不止“四舍五入加逗號(hào)”這么簡(jiǎn)單。2.1 先列清需求再寫代碼貨幣格式化的完整要素一個(gè)健壯的貨幣格式化函數(shù)至少要回答這幾個(gè)問(wèn)題需求維度典型選項(xiàng)說(shuō)明貨幣符號(hào)￥、$、€、?不同市場(chǎng)的默認(rèn)符號(hào)不同符號(hào)位置prefix 前置、suffix 后置如$100.00vs100.00€小數(shù)位數(shù)0、2、3、動(dòng)態(tài)加密貨幣可能到 6 位千分位開(kāi)啟、關(guān)閉部分場(chǎng)景如圖表軸會(huì)關(guān)閉負(fù)數(shù)展示-100.00、-￥100.00、(100.00)會(huì)計(jì)慣例常用括號(hào)舍入方式half-up、floor、ceil金融場(chǎng)景強(qiáng)制要求空值和異常兜底--、0.00、空串接口異常時(shí)必須可讀列完這張表你會(huì)發(fā)現(xiàn)toFixed(2)只是其中一小塊。金融應(yīng)用中真正要命的不是“加不加逗號(hào)”而是負(fù)數(shù)格式和舍入方式這兩個(gè)維度直接關(guān)系到用戶看到的盈虧數(shù)字是否正確。2.2 第一版實(shí)現(xiàn)基于浮點(diǎn)數(shù)的常規(guī)方案第一版我們?yōu)榱丝焖偕暇€寫了一個(gè)基于 number 的常規(guī)實(shí)現(xiàn)。核心思路是輸入金額數(shù)字定義好選項(xiàng)然后做舍入、取絕對(duì)值、拆整數(shù)和小數(shù)、加千分位、拼接符號(hào)。type RoundType half-up | floor | ceil; interface FormatCurrencyOptions { symbol?: string; // 貨幣符號(hào)默認(rèn) ￥ decimalPlaces?: number; // 小數(shù)位默認(rèn) 2 thousandSeparator?: boolean; // 千分位默認(rèn) true symbolPosition?: prefix | suffix; // 符號(hào)位置 negativeFormat?: sign | parenthesis; // 負(fù)數(shù)格式 roundType?: RoundType; // 舍入方式 emptyPlaceholder?: string; // 空值占位 } export function formatCurrency( amount: number | string | null | undefined, options: FormatCurrencyOptions {} ): string { const { symbol ￥, decimalPlaces 2, thousandSeparator true, symbolPosition prefix, negativeFormat sign, roundType half-up, emptyPlaceholder --, } options; if (amount null || amount undefined || amount ) { return emptyPlaceholder; } const num typeof amount string ? parseFloat(amount) : amount; if (isNaN(num) || !isFinite(num)) { return emptyPlaceholder; } const factor Math.pow(10, decimalPlaces); let rounded: number; switch (roundType) { case floor: rounded Math.floor(num * factor) / factor; break; case ceil: rounded Math.ceil(num * factor) / factor; break; default: rounded Math.round(Math.abs(num) * factor) / factor * Math.sign(num); break; } const negative rounded 0; const absValue Math.abs(rounded); const fixedStr absValue.toFixed(decimalPlaces); const [intPart, decimalPart] fixedStr.split(.); const formattedInt thousandSeparator ? intPart.replace(/\B(?(\d{3})(?!\d))/g, ,) : intPart; const decimalStr decimalPart ? .${decimalPart} : ; if (negativeFormat parenthesis negative) { return (${symbol}${formattedInt}${decimalStr}); } const sign negative ? - : ; if (symbolPosition suffix) { return ${sign}${formattedInt}${decimalStr}${symbol}; } return ${sign}${symbol}${formattedInt}${decimalStr}; }這版代碼在絕大多數(shù)場(chǎng)景下都能用但有一個(gè)金融場(chǎng)景繞不開(kāi)的隱患浮點(diǎn)誤差。拿0.1 * 100來(lái)說(shuō)在 JS 里結(jié)果是10.000000000000002如果恰好遇到這種中間值舍入結(jié)果就可能偏移。這類問(wèn)題不常出現(xiàn)但金融應(yīng)用不允許“偶發(fā)錯(cuò)誤”。2.3 精度進(jìn)階整數(shù)分方案與浮點(diǎn)陷阱金融行業(yè)有個(gè)約定俗成的做法涉及金額的內(nèi)部傳輸盡量用“分”為單位用整數(shù)表示從根上避開(kāi)浮點(diǎn)誤差。我們最終在項(xiàng)目里使用的也是這個(gè)方案上游接口直接返回分cents格式化函數(shù)接收整數(shù)分作為主輸入內(nèi)部全部用整數(shù)運(yùn)算。/** * 基于整數(shù)分格式化貨幣避免浮點(diǎn)誤差 * 例如formatCurrencyFromCents(12345678) ￥123,456.78 */ export function formatCurrencyFromCents( cents: number | string | null | undefined, options: FormatCurrencyOptions {} ): string { const { symbol ￥, decimalPlaces 2, thousandSeparator true, symbolPosition prefix, negativeFormat sign, roundType half-up, emptyPlaceholder --, } options; if (cents null || cents undefined || cents ) { return emptyPlaceholder; } let centsNum typeof cents string ? parseInt(cents, 10) : cents; if (isNaN(centsNum) || !isFinite(centsNum)) { return emptyPlaceholder; } const negative centsNum 0; const absCents Math.abs(centsNum); let intPart: string; let decimalPart: string; if (decimalPlaces 0) { const rounded roundCents(absCents, 0, roundType); intPart String(rounded); decimalPart ; } else { const scale Math.pow(10, decimalPlaces - 2); let scaled: number; if (decimalPlaces 2) { // 例如只需要 1 位小數(shù)先把分轉(zhuǎn)成角再舍入 scaled Math.floor(absCents / 10); if (roundType half-up) { scaled Math.round(absCents / 10); } else if (roundType ceil) { scaled Math.ceil(absCents / 10); } } else { // 常見(jiàn)場(chǎng)景整數(shù)分直接拆成元和分 // 更多位小數(shù)時(shí)用 scale 放大處理 scaled roundCents(absCents, decimalPlaces, roundType); } intPart String(Math.floor(scaled / Math.pow(10, decimalPlaces))); const rawDecimal String(scaled % Math.pow(10, decimalPlaces)).padStart(decimalPlaces, 0); decimalPart rawDecimal; } const formattedInt thousandSeparator ? intPart.replace(/\B(?(\d{3})(?!\d))/g, ,) : intPart; const decimalStr decimalPart ? .${decimalPart} : ; const body symbolPosition suffix ? ${formattedInt}${decimalStr}${symbol} : ${symbol}${formattedInt}${decimalStr}; if (negativeFormat parenthesis negative) { return (${body}); } return ${negative ? - : }${body}; } function roundCents(absCents: number, decimalPlaces: number, roundType: RoundType): number { const scale Math.pow(10, decimalPlaces - 2); const target absCents / scale; switch (roundType) { case floor: return Math.floor(target); case ceil: return Math.ceil(target); default: return Math.round(target); } }核心區(qū)別在于整個(gè)格式化過(guò)程不出現(xiàn)浮點(diǎn)數(shù)乘除12345678分直接拆成123456元和78分千分位也是打在整數(shù)字符串上完全不依賴toFixed。這樣就徹底規(guī)避了0.1 0.2這類經(jīng)典問(wèn)題。但實(shí)際業(yè)務(wù)中并不是所有上游都返回分有些接口返回的是“元”且是浮點(diǎn)數(shù)。這種場(chǎng)景我們不直接在格式化層修浮點(diǎn)而是先提供一個(gè)yuanToCents轉(zhuǎn)換函數(shù)在數(shù)據(jù)進(jìn)入業(yè)務(wù)層時(shí)就完成轉(zhuǎn)換/** 元轉(zhuǎn)分在數(shù)據(jù)入口統(tǒng)一轉(zhuǎn)換后續(xù)所有金額展示都走整數(shù)分 */ export function yuanToCents(yuan: number | string): number { const num typeof yuan string ? parseFloat(yuan) : yuan; if (isNaN(num) || !isFinite(num)) { return 0; } return Math.round((num Number.EPSILON) * 100); }這里用Number.EPSILON也是為了抵消部分浮點(diǎn)噪聲。建議團(tuán)隊(duì)定一條硬性規(guī)范數(shù)據(jù)層拿到金額后立刻轉(zhuǎn)成整數(shù)分業(yè)務(wù)層和展示層只認(rèn)分。3. formatPercent比貨幣格式化更隱蔽的“單位刺客”百分比格式化比貨幣格式化更容易踩坑因?yàn)樗妮斎胝Z(yǔ)義經(jīng)常不統(tǒng)一。同樣是利率0.126有的接口直接傳0.126讓你自己乘 100有的接口直接傳12.6表示已經(jīng)是百分比數(shù)值。如果不做統(tǒng)一約定格式化函數(shù)輸出就亂套。3.1 百分比輸入到底是 0.1234 還是 12.34必須顯式約定我見(jiàn)過(guò)很多團(tuán)隊(duì)在這個(gè)問(wèn)題上互相甩鍋業(yè)務(wù)組說(shuō)“后端返回的就是 0.1234 嘛”后端說(shuō)“我們文檔寫的是百分比數(shù)值 12.34”最后前端在展示層臨時(shí)除以 100 或者乘以 100一個(gè)端一個(gè)樣子。formatPercent 的第一個(gè)設(shè)計(jì)決策就是輸入統(tǒng)一按“原始比例”處理也就是 0.1234 表示 12.34%。這樣和國(guó)際化慣例一致后端存的是什么單位不會(huì)影響前端展示。但為了避免以后被“傳 12.34 的接口”坑到我提供了valueToPercent的擴(kuò)展參數(shù)如果你的上游字段穩(wěn)定地傳入已經(jīng)放大 100 倍的值可以顯式聲明inputScaled: true讓函數(shù)內(nèi)部不再乘 100。這個(gè)參數(shù)一旦設(shè)置代碼里就必須寫清楚不能猜。3.2 百分比格式化實(shí)現(xiàn)interface FormatPercentOptions { decimalPlaces?: number; // 小數(shù)位默認(rèn) 2 thousandSeparator?: boolean; // 千分位默認(rèn) true withSign?: boolean; // 是否顯示正號(hào)如 3.45% allowNegative?: boolean; // 是否允許負(fù)數(shù) inputScaled?: boolean; // 輸入是否已是百分比數(shù)值如 12.6 表示 12.6% trimTrailingZeros?: boolean; // 是否去掉小數(shù)末尾的 0 emptyPlaceholder?: string; } export function formatPercent( value: number | string | null | undefined, options: FormatPercentOptions {} ): string { const { decimalPlaces 2, thousandSeparator true, withSign false, allowNegative true, inputScaled false, trimTrailingZeros false, emptyPlaceholder --, } options; if (value null || value undefined || value ) { return emptyPlaceholder; } const num typeof value string ? parseFloat(value) : value; if (isNaN(num) || !isFinite(num)) { return emptyPlaceholder; } const raw inputScaled ? num : num * 100; const negative raw 0; const absRaw Math.abs(raw); const factor Math.pow(10, decimalPlaces); let rounded Math.round((absRaw Number.EPSILON) * factor) / factor; let [intPart, decimalPart] rounded.toFixed(decimalPlaces).split(.); decimalPart decimalPart || ; if (trimTrailingZeros decimalPlaces 0) { decimalPart decimalPart.replace(/0$/, ); } const formattedInt thousandSeparator ? intPart.replace(/\B(?(\d{3})(?!\d))/g, ,) : intPart; const decimalStr decimalPart ? .${decimalPart} : ; let sign ; if (negative) { if (!allowNegative) { return emptyPlaceholder; } sign -; } else if (withSign) { sign ; } return ${sign}${formattedInt}${decimalStr}%; }使用示例formatPercent(0.126) // 12.6% formatPercent(0.126, { decimalPlaces: 2 }) // 12.60% formatPercent(0.126, { decimalPlaces: 2, trimTrailingZeros: true }) // 12.6% formatPercent(1234.5, { withSign: true }) // 1,234.50%漲跌幅場(chǎng)景常用 formatPercent(-0.005, { decimalPlaces: 2, allowNegative: false }) // -- formatPercent(12.34, { inputScaled: true }) // 12.34%3.3 與貨幣格式化共享底層邏輯的設(shè)計(jì)百分比格式化和貨幣格式化看起來(lái)是兩套函數(shù)但它們的核心邏輯高度重疊千分位格式化、整數(shù)部分拆分、符號(hào)處理、小數(shù)位補(bǔ)齊。如果各寫各的以后調(diào)整千分位規(guī)則或符號(hào)規(guī)則時(shí)就要改兩處。我建議抽一個(gè)內(nèi)部公共函數(shù)formatNumberParts專門處理“絕對(duì)值轉(zhuǎn)千分位整數(shù)部分 小數(shù)部分 符號(hào)前綴”的通用邏輯formatCurrency 和 formatPercent 都調(diào)用它。這樣既減少了重復(fù)代碼也能保證兩套輸出的風(fēng)格一致。function formatAbsNumberParts( absValue: number, decimalPlaces: number, thousandSeparator: boolean, trimTrailingZeros: boolean ): string { const factor Math.pow(10, decimalPlaces); const rounded Math.round((absValue Number.EPSILON) * factor) / factor; const [intPart, decimalPart] rounded.toFixed(decimalPlaces).split(.); const formattedInt thousandSeparator ? intPart.replace(/\B(?(\d{3})(?!\d))/g, ,) : intPart; let decimalStr decimalPart || ; if (trimTrailingZeros decimalPlaces 0) { decimalStr decimalStr.replace(/0$/, ); } return decimalStr ? ${formattedInt}.${decimalStr} : formattedInt; }這里的思路是把“數(shù)字的展示玩法”千分位、小數(shù)位、去零和“語(yǔ)義玩法”貨幣符號(hào)、百分比符號(hào)、正負(fù)號(hào)括號(hào)分離。后續(xù)如果要統(tǒng)一改千分位分隔符為空格或者改成印度數(shù)字分組只需要?jiǎng)右粋€(gè)函數(shù)。4. 鴻蒙、iOS、Android 三端復(fù)用時(shí)的兼容性整治工具函數(shù)寫好了真正讓它成為“跨端核心資產(chǎn)”的關(guān)鍵一步是處理三端運(yùn)行環(huán)境的差異。React Native 項(xiàng)目在鴻蒙端跑起來(lái)后我們遇到了一堆在模擬器上根本暴露不出來(lái)、只有真機(jī)上才出現(xiàn)的兼容性問(wèn)題。4.1 Intl.NumberFormat 在不同 Runtime 上的表現(xiàn)差異剛寫第一版時(shí)很多同事習(xí)慣性用Intl.NumberFormat來(lái)做千分位。在 iOS 的 JavaScriptCore 里表現(xiàn)正常在 Android 的 Hermes 里基礎(chǔ)用法也正常但到了鴻蒙的 JS 運(yùn)行時(shí)某些版本對(duì)Intl.NumberFormat的支持不完整特別是currency風(fēng)格的貨幣符號(hào)映射有的設(shè)備顯示成CN￥有的顯示成￥甚至有的直接返回不帶符號(hào)的數(shù)字。這個(gè)問(wèn)題非常容易在聯(lián)調(diào)階段被漏掉因?yàn)轼櫭赡M器和開(kāi)發(fā)者常用的高端真機(jī)可能表現(xiàn)正常但用戶的大眾機(jī)型上就會(huì)翻車。我們的解決方案很簡(jiǎn)單放棄依賴 Intl.NumberFormat千分位和貨幣符號(hào)全部手動(dòng)處理。這也意味著工具函數(shù)完全不去探測(cè)宿主環(huán)境支持什么只依賴最基礎(chǔ)的 JS 語(yǔ)法穩(wěn)定性大幅提升。4.2 舍入規(guī)則與浮點(diǎn)誤差的跨端一致性另一類問(wèn)題是舍入行為不一致。toFixed在不同 JS 引擎上對(duì)某些邊界值的行為歷史上就存在爭(zhēng)議比如(1.005).toFixed(2)在不同引擎上可能得到1.00或1.01。雖然現(xiàn)代引擎大多修復(fù)了但鴻蒙端的新運(yùn)行時(shí)是否完全對(duì)齊我們沒(méi)有十足的把握。所以最終的 formatCurrencyFromCents 干脆繞開(kāi)了toFixed用整數(shù)運(yùn)算直接算小數(shù)位formatPercent 雖然還用toFixed但統(tǒng)一乘了Number.EPSILON做補(bǔ)償并且在三端真機(jī)上跑了一輪斷言用例。這里給的結(jié)論是能繞開(kāi)就繞開(kāi)繞不開(kāi)就加補(bǔ)償?shù)^不能假設(shè)所有端行為一致。4.3 字體渲染與 UX 細(xì)節(jié)從“能用”到“好看”格式化函數(shù)輸出的字符串最終要渲染到界面上不同端對(duì)貨幣符號(hào)的字體渲染也有差別。鴻蒙默認(rèn)字體對(duì)￥的渲染和蘋方對(duì)￥的渲染在寬度、基線位置上不完全一致。如果金額展示在表格或者卡片里可能因?yàn)榉?hào)寬度差異導(dǎo)致數(shù)字不能對(duì)齊。此外負(fù)數(shù)括號(hào)格式(￥1,000.00)在金融場(chǎng)景常用但在窄屏設(shè)備上括號(hào)容易和相鄰元素重疊。我們后來(lái)加了兩個(gè) UI 層面的約定金額類文本允許文本省略時(shí)不顯示貨幣符號(hào)只顯示1,000.00漲跌幅場(chǎng)景用顏色表示正負(fù)同時(shí)保留/-符號(hào)方便色弱用戶識(shí)別。這些細(xì)節(jié)不是格式化函數(shù)本身的問(wèn)題但如果沒(méi)有統(tǒng)一的格式化層這些 UX 約定根本無(wú)從談起。4.4 用測(cè)試矩陣守住三端一致性跨端一致性的底線不是靠代碼自證而是靠測(cè)試矩陣。我們?cè)?CI 里跑同一套 Jest 用例覆蓋 formatCurrency 和 formatPercent 的幾十種輸入輸出斷言在真機(jī)測(cè)試階段專門做了一張三端對(duì)照表格同一批輸入在三端的截圖輸出必須逐字一致。輸入iOSAndroid鴻蒙期望結(jié)果12345678分￥123,456.78￥123,456.78￥123,456.78￥123,456.78-500分括號(hào)格式(￥5.00)(￥5.00)(￥5.00)(￥5.00)0.126百分比12.60%12.60%12.60%12.60%null--------這張表我會(huì)建議每個(gè)涉及跨端的項(xiàng)目都建一份。格式化的斷言不通過(guò)其他業(yè)務(wù)邏輯都不要測(cè)了因?yàn)檎故緦右呀?jīng)錯(cuò)了。5. 異常輸入與邊界場(chǎng)景格式化函數(shù)也要有“防御裝甲”很多頁(yè)面崩潰和數(shù)據(jù)顯示異常不是業(yè)務(wù)邏輯的問(wèn)題而是格式化函數(shù)收到了意料之外的輸入。既然 formatCurrency 和 formatPercent 要作為公共資產(chǎn)在全項(xiàng)目鋪開(kāi)它們就必須對(duì)異常輸入有明確的防御策略。5.1 常見(jiàn)異常輸入與兜底策略我把項(xiàng)目中實(shí)際遇到的異常輸入歸成幾類每類都明確處理方式異常類型示例兜底行為空值null、undefined、空字符串返回--或配置的 emptyPlaceholder非數(shù)字字符串a(chǎn)bc返回空值占位符NaN / InfinityNaN、Infinity返回空值占位符字符串?dāng)?shù)字12345、12.5按數(shù)字解析后格式化超過(guò)安全整數(shù)范圍9007199254740993項(xiàng)目?jī)?nèi)部約定按最大值截?cái)嗷驋伄惓＿@里最重要的原則是格式化函數(shù)永遠(yuǎn)不拋異常。它處于展示鏈路的末端一旦拋異常輕則頁(yè)面白屏重則整個(gè)列表渲染失敗。兜底返回--至少能讓用戶知道“這里應(yīng)該有一個(gè)值但現(xiàn)在沒(méi)拿到數(shù)據(jù)”這比直接崩潰更友好。5.2 超大金額、超小金額與精度溢出金融應(yīng)用還會(huì)遇到余額寶收益這類超小數(shù)字比如年化收益每日入賬0.000123元。如果走 formatCurrencyFromCents0.000123元轉(zhuǎn)成整數(shù)分是0.0123分四舍五入變成0.01分展示成￥0.00其實(shí)沒(méi)問(wèn)題因?yàn)榇_實(shí)沒(méi)有滿一分錢。但如果產(chǎn)品經(jīng)理要求“顯示到厘”那就得在數(shù)據(jù)層提前把最小單位換成厘而不是在格式化層硬湊。超大數(shù)據(jù)方面如果后端傳的金額超過(guò) JS 安全整數(shù)范圍parseInt的精度就會(huì)丟失。我們的方案是接口層對(duì)超大金額統(tǒng)一用字符串傳遞格式化層通過(guò)BigInt或者字符串拆分的方式處理。不過(guò)目前 99% 的金融場(chǎng)景不會(huì)到萬(wàn)億級(jí)別所以這個(gè)處理做成可選擴(kuò)展不做進(jìn)主路徑避免把核心函數(shù)搞得太重。5.3 推薦的單測(cè)用例清單格式化工具是全項(xiàng)目的基石函數(shù)單元測(cè)試的性價(jià)比極高。我強(qiáng)烈建議至少覆蓋這些用例describe(formatCurrencyFromCents, () { test(常規(guī)金額千分位和小數(shù)位, () { expect(formatCurrencyFromCents(12345678)).toBe(￥123,456.78); }); test(負(fù)數(shù)符號(hào)格式, () { expect(formatCurrencyFromCents(-500)).toBe(-￥5.00); }); test(負(fù)數(shù)括號(hào)格式, () { expect(formatCurrencyFromCents(500, { negativeFormat: parenthesis, symbolPosition: suffix })).toBe(($5.00)); // 注意實(shí)際返回會(huì)帶上符號(hào)按實(shí)現(xiàn)斷言 }); test(空值兜底, () { expect(formatCurrencyFromCents(null)).toBe(--); }); test(非法輸入兜底, () { expect(formatCurrencyFromCents(abc)).toBe(--); }); }); describe(formatPercent, () { test(常規(guī)比例轉(zhuǎn)百分比, () { expect(formatPercent(0.126)).toBe(12.60%); }); test(千分位百分比, () { expect(formatPercent(12345.678)).toBe(1,234,567.80%); }); test(正號(hào)展示, () { expect(formatPercent(0.0345, { withSign: true })).toBe(3.45%); }); test(負(fù)數(shù)被禁止時(shí)兜底, () { expect(formatPercent(-0.01, { allowNegative: false })).toBe(--); }); test(已放大輸入, () { expect(formatPercent(12.34, { inputScaled: true })).toBe(12.34%); }); });我特別想強(qiáng)調(diào)“負(fù)數(shù)被禁止時(shí)兜底為空值”這個(gè)設(shè)計(jì)。在金融場(chǎng)景里利率或收益率出現(xiàn)了負(fù)數(shù)往往意味著異常。與其展示一個(gè)讓人困惑的-3.00%不如用占位符觸發(fā)后續(xù)的異常判斷邏輯。當(dāng)然盈虧類場(chǎng)景負(fù)數(shù)必須展示所以allowNegative默認(rèn)是true具體用哪個(gè)由業(yè)務(wù)層顯式?jīng)Q定。5.4 從“工具函數(shù)”到“資產(chǎn)”的團(tuán)隊(duì)落地經(jīng)驗(yàn)最后分享一點(diǎn)團(tuán)隊(duì)落地的經(jīng)驗(yàn)。工具函數(shù)寫完之后我們做了一件事把它從普通的 utils 目錄提升到了獨(dú)立的基礎(chǔ)庫(kù)里并寫了一份格式化規(guī)范文檔明確了以下幾條團(tuán)隊(duì)紅線所有金額展示必須走 formatCurrency / formatCurrencyFromCents禁止在業(yè)務(wù)代碼里手寫toFixed(2)。所有百分比展示必須走 formatPercent禁止手寫(num * 100).toFixed(2) %。數(shù)據(jù)層拿到的金額如果單位是“元”必須在數(shù)據(jù)轉(zhuǎn)換層統(tǒng)一轉(zhuǎn)成“分”展示層只認(rèn)分。新增格式化需求比如新貨幣、新舍入方式必須改工具庫(kù)并在單測(cè)里補(bǔ)充用例不允許在業(yè)務(wù)組件里臨時(shí)拼字符串。這幾條紅線剛開(kāi)始執(zhí)行時(shí)會(huì)有阻力尤其是一些老手覺(jué)得“就一行代碼沒(méi)必要封裝”。但經(jīng)歷一次跨端金額對(duì)賬事故后團(tuán)隊(duì)就沒(méi)人再質(zhì)疑了。工具函數(shù)本身不復(fù)雜真正有價(jià)值的是把它作為“資產(chǎn)”對(duì)待的制度約束。后續(xù)如果要把這套邏輯復(fù)用到 Flutter 或者其他跨端方案核心的舍入規(guī)則和邊界場(chǎng)景清單也可以平遷過(guò)去這才是它作為“核心資產(chǎn)”的意義所在。