JavaScript原生Date无直接格式化方法，toLocaleString()因依赖本地环境不可靠，toISOString()是唯一可靠标准格式（UTC），Intl.DateTimeFormat可控但需预定义选项，手写工具函数或第三方库更实用。
JavaScript 原生 Date 对象不提供直接的格式化方法（比如 format('YYYY-MM-dd')），所有“格式化”都得靠手动拼接、内置方法组合，或引入第三方库。这是初学者最容易卡住的地方。
为什么 Date.prototype.toLocaleString() 看起来像格式化，但实际很不可靠？
它依赖运行环境的本地化设置（navigator.language）、时区、甚至操作系统区域配置，同一段代码在 Chrome macOS 和 Edge Windows 上可能输出完全不同的字符串，比如：
new Date().toLocaleString() // 可能是 "2025/6/12, 14:30:22"，也可能是 "6/12/2025, 2:30:22 PM"
所以它只适合显示给终端用户看的“友好时间”，不能用于日志、接口传参、文件命名等需要确定格式的场景。
- 参数
{ year: 'numeric', month: '2-digit' }可控性略高，但仍受 locale 影响 - 不支持自定义分隔符（如
2025-06-12T14:30:22Z中的T和Z） - 无法补零控制（
getMonth()返回 0–11，getDate()返回 1–31，需手动.toString().padStart(2, '0')）
toISOString() 是唯一可靠的标准格式输出方法
它固定返回 ISO 8601 格式（UTC 时区），格式为 YYYY-MM-DDTHH:mm:ss.sssZ，无歧义、可排序、被 JSON 和大多数后端语言原生识别：
new Date().toISOString() // "2025-06-12T06:30:22.123Z"
注意： toISOString() 总是转成 UTC 时间，如果你要本地时区的 ISO 风格字符串（如 2025-06-12T14:30:22+08:0），得自己拼接：
- 用
date.getFullYear()、date.getMonth() + 1、date.getDate()等获取各部分 - 用
date.getTimezoneOffset()计算时区偏移（单位是分钟，需转成 ±HH:mm） - 手动补零（
String(date.getDate()).padStart(2, '0')）
真正实用的格式化：手写工具函数 or 用 Intl.DateTimeFormat
Intl.DateTimeFormat 是现代浏览器中唯一既标准又可控的方案，支持显式指定时区和格式选项，且不依赖系统 locale：
const formatter = new Intl.DateTimeFormat('en-US', {
year: 'numeric',
month: '2-digit',
day: '2-digit',
hour: '2-digit',
minute: '2-digit',
second: '2-digit',
hour12: false,
timeZone: 'Asia/Shanghai'
});
formatter.format(new Date()) // "06/12/2025, 14:30:22"
但它依然不能写成 yyyy-MM-dd HH:mm 这种模板字符串风格——你必须用预定义的键（year, month, hour 等）来声明需求。
- 想输出
2025-06-12？用{ year: 'numeric', month: '2-digit', day: '2-digit' }+separator: '-'不行，得靠formatToParts()拆解再拼 - Node.js 18+ 支持
formatRange()，但日常单日期格式化仍需组合
别碰 Date.parse() 和 new Date(string) 做解析
它们对输入格式极度敏感，不同浏览器对 "2025/06/12"、"06-12-2025"、"2025-06-12 14:30" 的解析结果可能完全不同，甚至返回 Invalid Date。
- 唯一安全的字符串输入是
toISOString()输出的格式（2025-06-12T14:30:22.123Z） - 其他格式一律建议用正则提取年月日时分秒，再调用
new Date(year, monthIndex, date, hour, minute, second)构造 - 时区处理尤其危险：
new Date('2025-06-12')在 Chrome 中是 UTC，在 Safari 中可能是本地时区
真正写业务时，90% 的日期格式化需求其实只需要两三种固定格式（如列表时间、表单提交值、日志前缀）。与其反复折腾原生 API，不如封装一个极简函数，把 getFullYear()、getMonth()、getDate() 等调用和补零逻辑收拢——比记 Intl 的几十个选项实在得多。复杂格式化留给 dayjs 或 date-fns 更省心，但前提是确认项目允许引入外部依赖。
