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