date对象无内置格式化方法，需手动拼接或用tojson()、tolocalestring()等；注意时区差异、getmonth()+1、补零及现代库优先原则。
JavaScript 的 Date 对象本身不提供直接格式化字符串的方法，所有“好看的时间显示”都得手动拼接或借助方法转换——这是初学者最容易卡住的地方。
为什么 new Date().toString() 和 new Date().toJSON() 输出不一样
不同方法返回的字符串用途和时区处理逻辑完全不同：toString() 用本地时区、带星期和缩写，适合调试；toJSON() 强制转为 UTC 的 ISO 格式（"2024-05-20T08:30:00.000Z"），常用于 API 通信。别拿 toJSON() 的结果直接展示给用户，它末尾的 Z 容易被误读为“本地时间”。
常见错误：把 new Date().toJSON().slice(0, 10) 当作“今天日期”，结果在东八区用户看到的是 UTC 时间减去 8 小时后的日期（比如 UTC 是 5 月 20 日 00:00，本地其实是 5 月 20 日 08:00，但 slice(0, 10) 会截出 "2024-05-19"）。
toLocaleDateString() 和 toLocaleTimeString() 怎么选参数才不翻车
这两个方法靠 locales 和 options 控制输出，但选项名容易混淆：
立即学习“Java免费学习笔记（深入）”；
-
year: 'numeric'→"2024"；year: '2-digit'→"24" -
month: 'short'→"May"；month: '2-digit'→"05"；month: 'long'→"May"（英文下short和long一样，中文才区分“五月”和“5月”） -
hour12: true开启 12 小时制，但必须同时设hour和minute，否则可能不显示小时
推荐写法：date.toLocaleDateString('zh-CN', { year: 'numeric', month: '2-digit', day: '2-digit' }) —— 明确指定语言环境，避免用户系统设置影响输出（比如美国用户系统设成 en-US，month: 'short' 就会出 "May" 而非 "5月"）。
手写格式化函数时，为什么 getMonth() 要 +1，而 getDay() 不用
getMonth() 返回 0–11（0 是 1 月），这是历史遗留设计；getDay() 返回 0–6（0 是周日），它从来就不是“第几天”，而是“星期几”，所以不需要加 1。
容易漏掉的细节：
-
getDate()是“几号”（1–31），不是getDay() - 两位数补零不能只靠
String(n).padStart(2, '0')，因为getHours()等返回值始终是数字，但getMonth()和getDate()在跨月时可能返回 1 位数，必须统一补零 - 时区偏移要用
date.getTimezoneOffset()手动算，它返回的是分钟数（如东八区是 -480），别直接塞进字符串
简单示例（ISO 日期部分，不含时分秒）：
const d = new Date();<br>`${d.getFullYear()}-${String(d.getMonth() + 1).padStart(2, '0')}-${String(d.getDate()).padStart(2, '0')}`
现代项目里，真没必要从零写格式化逻辑
如果项目已用 dayjs 或 date-fns，直接用 format() 最省心：dayjs().format('YYYY-MM-DD HH:mm')；format(new Date(), 'yyyy-MM-dd HH:mm')。它们内部已处理好时区、locale、补零、月份偏移等所有坑。
但要注意：不要只为格式化引入完整 moment.js（体积大、已进入维护模式）；也不要在浏览器环境里用 Intl.DateTimeFormat 时忽略兼容性——Safari 13 以下不支持 timeZoneName: 'short' 这类选项。
真正麻烦的不是“怎么显示”，而是“按哪个时区显示”：用户看的是本地时间？服务器时间？还是某个固定时区（如北京时间）？这个判断一旦错，所有格式化都白搭。
