JavaScript日期字符串转换需按场景选择方法：toISOString()用于标准化UTC输出，Intl.DateTimeFormat用于国际化展示，new Date()解析ISO格式最安全，存储传输统一用带时区的ISO字符串。
JavaScript 中日期与字符串的转换看似简单，但容易踩坑——比如时区偏差、格式不一致、浏览器兼容性差异。关键在于明确需求：是展示用、存储用，还是跨系统传输？不同场景该选不同方法。
用 toISOString() 做标准化字符串输出
如果需要可预测、无歧义的 ISO 8601 格式（如 "2024-05-20T08:30:00.000Z"），toISOString() 是最可靠的选择。它强制返回 UTC 时间，避免本地时区干扰，适合 API 通信或数据库存入。
- 注意：它总是带毫秒和
Z后缀，若不需要毫秒，可用slice(0, -5) + 'Z'截断 - 不能直接用于中文界面显示，需额外格式化
- 所有现代浏览器都支持，无兼容性问题
用 Intl.DateTimeFormat 灵活控制显示格式
面向用户展示日期时，应优先用 Intl.DateTimeFormat。它能自动适配语言、时区和格式偏好，比如中文用户看到“2024年5月20日”，英文用户看到“May 20, 2024”。
- 支持自定义选项：
{ year: 'numeric', month: 'long', day: 'numeric' } - 指定时区：
{ timeZone: 'Asia/Shanghai' }，避免用户本地时间导致显示错乱 - 比拼接字符串或正则更健壮，也比 moment.js 等库更轻量
用 new Date() 解析字符串要格外小心
new Date('2024-05-20') 在不同浏览器中可能解析为 UTC 或本地时间，尤其短格式（如 '2024/05/20'）行为不统一。稳妥做法是：
立即学习“Java免费学习笔记（深入）”；
- ISO 格式（含
T和时区）最安全，如'2024-05-20T00:00:00'或'2024-05-20T00:00:00Z' - 避免用
new Date('2024-05-20')—— 它在 Safari 中默认为 UTC，在 Chrome 中可能按本地时区处理 - 若必须解析非标准格式（如
'2024年5月20日'），先用正则提取年月日，再调用new Date(year, month - 1, day)
存储与传输前统一转成 ISO 字符串
前后端交换日期时，字符串应始终是 ISO 格式且带时区信息。服务端通常期望 UTC 时间，前端传值前主动转：
- 用户选择日期后，立即用
date.toISOString()转成字符串再发送 - 收到服务端返回的 ISO 字符串（如
"2024-05-20T12:00:00.000Z"），直接new Date(str)即可生成正确 Date 对象 - 不要依赖
Date.parse()，它对非标准输入容错差，且返回毫秒数易出错
