凡是碰过合同、发票、对账批处理、支付单据的后端基本都写过或抄过一个“阿拉伯数字 → 中文大写金额”的函数。这活儿看着像字符串查表真正落到财务规范里挂掉的几乎都在零的合并、整字边界、圆与元混用这三条线上。1. “零”不是有多少个 0 就写多少个《会计基础工作规范》和央行票据填写规范里对“零”的约定是带语言感的不是机械替换中间单个 0 → 写“零”1409.50→ 壹仟肆佰零玖元伍角连续多个 0 → 只写一个“零”6007.14→ 陆仟零柒元壹角肆分元位是 0、角位非 0可写可不写“零”1680.32→ 壹仟陆佰捌拾元零叁角贰分 / 也可省“零”角位是 0、分位非 0 → 元后必须补“零”325.04→ 叁佰贰拾伍元零肆分很多自写实现用正则零 → 零收尾结果把“零角零分”误并成“零分”或者把“壹仟零拾元整”里的结构性零吞掉。正确做法是用按权位扫描 状态机记录“上一位是否零、当前组是否全零、跨万/亿组时是否补零”而不是先拼完再正则擦屁股。2. “整”字只在到元或到角时出场规则很硬到元为止无角分或角分 00→ 元后加“整”或“正”532.00→ 伍佰叁拾贰元整到角为止分位 0→ 角后可写可不写“整”100.50→ 壹佰元伍角或壹佰元伍角整有分 → 分后绝不写整6007.14→ 陆仟零柒元壹角肆分没有“整”线上出过真实故障某合同系统对0.00输出“零元”财务拒收规范上零元一般写“零元整”或结合上下文又有系统对12.34尾缀硬加“整”被审计打回。这处边界必须用“小数两位是否全 0”单独分支不能跟整数拼接共用后缀。3. “圆”和“元”都能用但别在一个系统里跳着用人民币法定单位是“元”但票据规范明确用“圆”也算受理繁体“圓”也行前提是整套单据统一。新系统、对外 API、电子合同 → 默认用“元”对接老银行直连、支票、承兑汇票 → 看对方模板用“圆”就全程“圆”最忌讳同一条记录 JSON 里返“元”PDF 模板里写“圆”人工核对时以为两版不一致顺带一条大写前是否带“人民币”三字、小写前是否带“¥”都属于单据格式层的事不该在“数字转大写”纯函数里硬编码应该由调用方单据渲染层决定前缀。4. 为什么别用 float64 直接乘 10019.99 * 100 1998.9999999999998这种事在金额转换里是事故级。正确路径入参用string或decimal.Big不用float64按小数点切整数段 / 角分段 / 分分段整数段从右往左每 4 位一组个十百千 / 万 / 亿组间插“万”“亿”组内按千百十处理小数段单独走角、分映射角分全 0 才走“整”分支Go 里用strings.SplitN(input, ., 2)big.Int收整数小数补零到两位再int取角分比任何float64 * 100都稳。5. 联调时怎么快速核对自写函数写完拿一组边界用例对照就够0 → 零元整 0.04 → 零元零肆分 1409.50 → 壹仟肆佰零玖元伍角 6007.14 → 陆仟零柒元壹角肆分 1680.32 → 壹仟陆佰捌拾元零叁角贰分或省零 107000.53 → 壹拾万零柒仟元零伍角叁分或省零 325.04 → 叁佰贰拾伍元零肆分 532.00 → 伍佰叁拾贰元整 1234567.89 → 壹佰贰拾叁万肆仟伍佰陆拾柒元捌角玖分我习惯把这些用例在纯前端页里再跑一遍对照——不传数据到服务端、切“元/圆”开关看渲染差异用https://zz365.top/daxie这种本地页做回归目检就行同站 Base64/JWT/Crontab 是一套“浏览器跑完即清”的本地工具箱思路不是独立产品财务联调时开一个标签页对照用。注意它只帮你看“财务写法对不对”生产代码仍必须以服务端string/decimal实现 单测为准前端页不替代单测。小结数字转大写不是“查表题”是财务语言规则题。零的合并、整字边界、圆元统一这三条线在 code review 里盯住比换更炫的 UI 重要自写实现用 string 入参 权位状态机别碰 float64。