Intl.NumberFormat能格式化货币，但必须传入数字类型而非字符串，否则静默转为NaN；需用parseFloat()或一元加号显式转换并校验isFinite()，且币种不能自动适配用户本地，须由业务明确指定。
Intl.NumberFormat 能否直接格式化货币字符串
能，但必须传入数字类型，不能传字符串。传 "1234.56" 会静默转成 NaN，最终显示为 "$NaN" —— 这是线上常见 bug 来源。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 始终用
parseFloat()或一元加号+显式转换，再校验是否为有效数字 - 避免直接对后端返回的
amount: "1234.5600"字段调用Intl.NumberFormat - 转换后建议用
isFinite()检查，防止Infinity或空字符串导致意外输出
currencyDisplay: "symbol" 和 "narrowSymbol" 有什么区别
区别直接影响显示效果和空间占用："symbol"（如 $、¥）是标准符号；"narrowSymbol" 在部分语言下会用更紧凑形式（如日语中 ¥ 而非全角 円），但 Chrome 117+ 才稳定支持，Safari 16.4+ 仍可能回退到 symbol。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 面向全球用户且重视排版密度（比如表格列宽受限），可尝试
currencyDisplay: "narrowSymbol" - 需要强一致性或兼容旧浏览器时，坚持用
"symbol" - 不要依赖
"code"（如USD）做前端展示，它只适合后台日志或调试
如何让 Intl.NumberFormat 自动适配用户本地货币单位
不能自动适配。浏览器的 navigator.language 只决定数字分组/小数点符号，不决定币种 —— USD 在德国用户浏览器里仍显示 $，不会变成 €。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 币种必须由业务逻辑明确指定，通常来自后端字段（如
currency: "EUR"） - 若需按地区映射默认币种，应维护轻量映射表，例如
{ "de-DE": "EUR", "ja-JP": "JPY" }，而非依赖Intl推断 - 避免在格式化时硬编码
locale，应传入用户实际区域（如"en-GB"）+ 明确币种（如"GBP"），二者缺一不可
小数位数控制：minimumFractionDigits 不等于四舍五入
minimumFractionDigits 只控制「最少显示几位」，不参与舍入计算；真正影响数值精度的是原始输入值本身。比如 123.456 格式化为 USD 且设 minimumFractionDigits: 2，结果是 "$123.46"（因 JS number 默认按 IEEE 754 四舍五入），但这是底层浮点行为，不是 Intl 的逻辑。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 金额运算务必在格式化前完成舍入，推荐用
Math.round(value * 100) / 100处理两位小数场景 - 对账类场景慎用
maximumFractionDigits隐藏尾部零，"$100.00"和"$100"在财务系统中含义不同 - 注意
useGrouping: false在移动端可能影响可读性，尤其长数字如1000000，别为省事关掉千分位
最易被忽略的一点：服务端返回的金额若带精度丢失（比如 0.1 + 0.2 === 0.30000000000000004），Intl.NumberFormat 会如实反映这个误差。格式化不是修复数据的手段，而是展示环节的最后一道工序。
