C#没有内置中文大写转换函数，必须手写逻辑；核心是财务语义规则而非简单映射，需严格处理“零”的连读、金额补“整”、小数两位精度及负数校验。
小写数字转中文大写：用 ConvertToChineseUppercase 还是手写逻辑？
直接说结论：C# 没有内置函数，ToString("C") 或 NumberFormatInfo 都不支持中文大写，必须自己实现。别找 NuGet 包——多数轻量级包要么不处理“零”的连读规则，要么对金额末尾“整”字、角分补零逻辑错乱。
核心难点不在转换字母，而在财务语义：比如 10001.05 必须转成“壹万零壹元零伍分”，不是“壹万零零零壹元零伍分”。中间连续零只读一个，元后无角分要补“整”，小数点后不足两位要补零。
- 优先封装为静态方法，避免每次 new 对象；输入用
decimal（不是double），防止浮点误差 - 不要用字符串
.Replace()处理零——比如 “1001” 中的两个零位置不同，语义不同 - 拆成整数部分 + 小数部分分别处理，小数部分强制截取 2 位（
Math.Round(value, 2, MidpointRounding.AwayFromZero)）
“零”的出现位置决定读法：哪些地方必须读、哪些必须跳过
中文大写不是机械映射。关键判断点在“位权空缺”和“前后非零”：万位是 0 但千位和亿位都不是 0，就要读“零”；但连续多个 0 只读一次；万/亿级内部连续零可省，跨级（如万到千）不能省。
典型错误：100001 错转为“壹拾万零零零零壹”，正确是“壹拾万零壹”；100100 错转为“壹拾万零壹佰”，正确是“壹拾万零壹佰”（这里“零”不能省，因为万位后直接跳到百位，中间千位空缺）。
- 用数组存位权名：
new[] { "", "拾", "佰", "仟", "万", "拾", "佰", "仟", "亿" }，索引对应个、十、百……注意“万”“亿”是分界点 - 每 4 位一组处理（个/十/百/千 → 万组 → 亿组），组内按位判断，组间用“万”“亿”连接，组内全零则整个组跳过（但需记录是否已输出非零字，决定要不要补“零”）
- 遇到当前位为 0，检查：前一位是否已输出非零字 && 后一位是否将输出非零字 → 满足才加“零”
小数部分处理：为什么 0.5 要变成“零伍分”，而 1.0 是“壹元整”
财务场景下，小数部分严格按两位处理：不足补零，超长舍入（非截断）。不存在“壹元伍角”这种口语写法，必须是“壹元零伍分”或“壹元整”。
常见坑：Math.Floor(value * 100) % 100 在负数或精度边界出错；用 ToString("F2") 再 split 容易受线程本地化影响（比如某些文化下小数点是逗号）。
- 用
decimal.Truncate(value * 100) % 100算分值，确保整数运算无误差 - 分值为 0 → 输出“整”；分值为 1–9 → 角位为 0，所以是“零X分”；分值为 10–99 → 拆成角、分两位分别查表
- 务必在整数部分末尾加“元”，再拼小数结果；“元”不能省，“整”不能写成“正”或漏掉
性能与边界：1000 万次调用下，字符串拼接比 StringBuilder 慢 3 倍
如果用 += 拼接中文字符（共约 20–30 字），在高频场景（如导出万行账单）会明显拖慢。不是因为算法复杂，而是 string 不可变导致反复分配内存。
另一个容易被忽略的边界：0 必须输出“零元整”，不是空字符串；-123.45 财务上不允许负数，应抛 ArgumentException 或提前校验，别默默转成“负壹佰贰拾叁元肆伍分”。
- 初始化
StringBuilder时预估长度（如 50），避免扩容；中文字符每个占 3 字节，但StringBuilder计数按字符，不是字节 - 所有中文字符用常量字符串池（
private static readonly string[] Digits = { "零", "壹", ... };），别每次 new - 测试用例至少覆盖：
0、10.05、10000000.00、10001.1、100100.00，重点看“零”和“整”的位置
最麻烦的永远不是怎么转，而是“零”该不该读、在哪儿读、读几个——这得对照《支付结算办法》附录里的示例逐条对齐，代码里藏一堆 if 判断不可怕，可怕的是没按规范来，财务系统拒收就真拒收。
