货币数字本地代码对照，搞清不同国家货币格式差异，跨国项目不再踩坑
摘要：
货币数字本地代码对照，搞清不同国家货币格式差异，跨国项目不再踩坑做国际化项目久了，货币数字本地代码这块坑真的不少。货币数字本地代码由语言-地区-变体三层组成，比如zh-CN、en-... 货币数字本地代码对照，搞清不同国家货币格式差异，跨国项目不再踩坑
做国际化项目久了，货币数字本地代码这块坑真的不少。同一个金额，在美国是$1,234.56，在德国是1.234,56 €，在印度又是1,23,456.00 ₹。背后对应的正是不同的货币数字本地代码货币数字本地代码对照，搞清不同国家货币格式差异，跨国项目不再踩坑，搞不清对应关系，界面一上线就是灾难。
货币数字本地代码由"语言-地区-变体"三层组成，比如zh-CN、en-US、de-DE。地区码直接决定了千分位分隔符是逗号还是点号、小数位用哪个符号。写代码时如果只填了语言没填地区货币数字本地代码，很多框架会回退到默认行为，数字格式全乱。
去年做东南亚多币种结算系统，泰国的本地代码是th-TH，印度卢比对应in-IN，两处分组规则完全不同。当时需求方把"泰铢"和"印度卢比"塞进同一个下拉框，分组符号直接对不上，财务差点报警。后来把每个币种的本地代码写成映射表才稳住。
现代前端项目里，浏览器自带的Intl.NumberFormat已内置主流货币数字本地代码的解析逻辑。传入locale和currency两个参数，自动处理分组、小数位、符号位置。但ICU数据包对部分小语种支持滞后，比如缅甸缅元（MMK）对应的mm-MM，旧版Chrome根本取不到。
团队协作时，别在代码里硬编码"1,000.00"这种字符串。把货币数字本地代码抽到配置中心，让后端统一返回格式化文本，前端只做渲染。各地区版本上线时改配置就行，不用动代码重新发版，维护成本能降一大截。
