input[type="date"]的value永远是ISO格式"YYYY-MM-DD"，需用Intl.DateTimeFormat等API本地化显示；数字格式化同理，必须显式指定locale和options，避免浏览器默认行为差异。
input[type="date"] 的 value 永远是 "YYYY-MM-DD"
别指望它返回“2026年7月6日”或“07/06/2026”——这是 HTML 规范强制要求的。无论用户看到的 UI 是中文、英文还是阿拉伯语，input.value 只会是 ISO 格式字符串，且不含时区信息。
常见错误：直接把 input.value 插入页面显示，结果全是“2026-07-06”。必须先转成 Date 对象再格式化：
-
new Date(input.value)在 Safari 旧版本（iOS 15.4 之前）可能解析失败，稳妥写法是new Date(input.value + "T00:00") - 若后端返回带时区的时间戳（如
"2026-07-06T08:00:00+08:00"），直接传给new Date()会按本地时区解释，可能偏差一天 - 不要用
input.getAttribute("value")替代input.value—— 前者返回原始属性值，后者才是用户实际选中的日期
Intl.DateTimeFormat 是目前最可控的日期本地化方案
它不依赖用户系统语言，能显式指定 locale 和格式细节，兼容 Chrome 24+/Firefox 29+/Safari 10+。关键点不是只传 'zh-CN'，而是必须配 options：
- 省略
options时，Chrome 可能输出"2026/7/6"，Firefox 输出"2026年7月6日"，行为不一致 -
dateStyle: 'full'和手动指定year/month等字段互斥，混用会静默失效 - 需要“7月6日”就写
{ month: 'long', day: 'numeric' }；要“07/06/2026”这种固定格式，放弃Intl，改用字符串拼接：${d.getMonth()+1}/${d.getDate()}/${d.getFullYear()} -
timeZone参数决定语义：不设则用用户本地时区；设为'UTC'则所有用户看到同一时刻的 UTC 表达
toLocaleDateString() 能用，但参数缺一不可
它是 Intl.DateTimeFormat 的快捷封装，轻量但更易踩坑：
立即学习“前端免费学习笔记（深入）”；
- 只传
"zh-CN"字符串，iOS Safari 15.4 之前会忽略weekday: "long"，输出空字符串 - 安全写法：
new Date("2026-07-06").toLocaleDateString("zh-CN", { year: "numeric", month: "long", day: "numeric" }) -
<time datetime="2026-07-06">今天</time>中的文本不会被自动替换——浏览器只认datetime属性的 ISO 值，标签内文字需 JS 手动更新 - 若内容静态且语言确定，直接写
<time datetime="2026-07-06">2026年7月6日</time>最省事，也利于 SEO 和无障碍
数字和货币格式同样依赖 Intl.NumberFormat
和日期一样，HTML 自身不处理数字本地化。比如 1234567.89 在中文环境应显示为“1,234,567.89”，在德语环境是“1.234.567,89”，在阿拉伯语则是从右往左书写：
- 用
new Intl.NumberFormat("zh-CN").format(1234567.89)→ “1,234,567.89” - 货币需明确
style: "currency"和currency，如new Intl.NumberFormat("ja-JP", { style: "currency", currency: "JPY" }).format(1000)→ “¥1,000” - 百分比用
style: "percent"，注意输入值是小数（0.123→ “12.3%”） - 不要用
Number.prototype.toLocaleString()省略参数——不同浏览器默认分组符、小数位数差异大，尤其在金融场景下极易出错
"2026-07-06" 字符串本身没有语言属性，它何时变成“七月六日”，取决于你调用 Intl 的那一刻是否明确指定了 locale、时区和格式粒度——漏掉任何一项，都可能让日本用户看到“7/6/2026”，或让沙特用户收到未经 RTL 处理的阿拉伯数字顺序。 
