Intl.DateTimeFormat 的 day 选项仅输出数字（如“5”或“05”），不生成日历卡片结构；需配合 formatToParts() 提取结构化日期字段，再结合样式与布局手动构建卡片，并注意显式指定 timeZone 避免跨时区偏差。
Intl.DateTimeFormat 的 day 选项只控制“几号”，不决定卡片布局
直接用 Intl.DateTimeFormat 的 day 属性（比如 { day: 'numeric' }）只能输出数字，比如 "5" 或 "05"，它本身不生成日历卡片结构。所谓“日历卡片”，本质是把日期数据 + 样式 + 布局逻辑组合起来的结果。你需要先用 Intl.DateTimeFormat 提取干净的日期字段，再手动拼进 HTML 或 JSX。
常见错误是以为设置 { day: '2-digit', weekday: 'short' } 就能自动渲染成带星期和圆角背景的卡片——它只会返回字符串 "Fri, 05"，样式和容器得你来写。
用 formatToParts() 拆出 day 和 weekday，避免字符串解析
如果需要分别获取“星期几”和“日期数字”用于卡片不同区域（比如顶部显示 "Wed"，中间大号显示 "12"），别用 toLocaleDateString() 再 split 或正则匹配。优先用 formatToParts()，它返回结构化数组，稳定且不受 locale 格式变化影响：
const fmt = new Intl.DateTimeFormat('en-US', {
weekday: 'short',
day: 'numeric'
});
const parts = fmt.formatToParts(new Date(2024, 5, 12));
// → [{ type: 'weekday', value: 'Wed' }, { type: 'literal', value: ', ' }, { type: 'day', value: '12' }]
你可以遍历 parts，按 type 提取对应值，再注入到模板中。比字符串切割可靠得多，尤其在中文、阿拉伯语等 locale 下不会因标点位置变动而崩。
day 的 '2-digit' 和 'numeric' 在卡片中视觉差异明显
对日历卡片来说，day 的格式选择直接影响对齐和视觉节奏：
-
{ day: 'numeric' }→ 输出"1"、"12"：适合居中大字显示，但单数日（1–9）宽度不一致，CSStext-align: center下容易晃动 -
{ day: '2-digit' }→ 输出"01"、"12"：宽度固定，卡片网格对齐更稳，但前导零在部分设计语言里显得冗余
如果你用 CSS Grid 做 7×6 日历网格，推荐 '2-digit'；如果走极简风格、靠字体大小和间距营造节奏，'numeric' 更自然。没有绝对好坏，但混用会导致列宽跳变——这点上线前务必用 1 号到 31 号全量测一遍。
别忘了时区和本地化陷阱：卡片日期可能“错一天”
用户看到的“今天”是设备本地时间，但后端或日历 API 返回的时间戳可能是 UTC。如果直接拿 new Date(utcTimestamp) 丢给 Intl.DateTimeFormat，在跨时区场景下（比如服务器在 UTC+0，用户在 UTC+8），卡片上显示的 day 可能比预期早或晚一天。
稳妥做法是明确指定时区：
const fmt = new Intl.DateTimeFormat('zh-CN', {
day: 'numeric',
timeZone: 'Asia/Shanghai' // 或使用 'UTC' 统一基准
});
尤其做跨地区团队日历、航班时间表这类卡片时，漏掉 timeZone 选项是线上最隐蔽也最难复现的 bug 来源之一。
卡片不是格式化函数的终点，而是你控制数据流、时区、样式和 DOM 结构的起点。越早把 day 当作一个可组合的原子值来用，越少掉坑里。
