HTML5 的 value 原生返回 ISO 8601 格式字符串（如"2024-03-15"），可直传后端或用于 Date.parse()；非 date 类型输入或手动拼接易破坏格式，安全标准化应使用 new Date(dateStr).toISOString().slice(0,10)。
HTML5
直接读取 input.value 得到的就是符合 ISO 8601 的字符串（如 "2024-03-15"），不需要额外转换。浏览器原生支持，且该格式可直接用于后端 API、Date.parse() 或 new Date() 构造。
常见误解是以为要手动拼接或格式化——其实只要没做多余处理，它已经是 ISO 格式了。
为什么有时拿到的日期不是 ISO 格式？
问题通常出在人为干预：比如用 toLocaleDateString()、getYear()/getMonth() 拼接，或从非 type="date" 输入框（如 text）里取值。
-
中用户输入"15/03/2024"或"2024.3.15"→ 不是 ISO，需解析再转 - 用了
new Date().toLocaleDateString('zh-CN')→ 返回"2024/3/15"，斜杠和无补零，不符合 ISO - 手动拼
year + '-' + (month + 1) + '-' + date→ 缺少补零，变成"2024-3-5"（非法 ISO）
安全转成 ISO 的兜底写法（兼容非 date 类型输入）
当不能确保输入源是 type="date"，或需要校验/标准化时，用 new Date() 解析后再格式化：
立即学习“前端免费学习笔记（深入）”；
function toISODate(dateStr) {
const d = new Date(dateStr);
if (isNaN(d.getTime())) return null;
return d.toISOString().slice(0, 10); // "2024-03-15"
}
注意点：
-
new Date("2024-03-15")和new Date("15/03/2024")行为不一致：前者可靠，后者依赖浏览器 locale，可能失败 -
toISOString()返回带时区的完整时间（如"2024-03-15T00:00:00.000Z"），切前 10 位最稳 - 不要用
toJSON()替代 —— 它等价于toISOString()，但语义不明确
后端接收时要注意时区陷阱
提交的 "2024-03-15" 是本地时区的“日期”，但解析成 Date 对象时会被当作 UTC 零点（如 new Date("2024-03-15") 在东八区实际是 2024-03-14T16:00:00.000Z）。
如果后端需要严格对应用户选择的“日历上的那天”，建议：
-
前端保持字符串直传（不转
Date），后端按字符串解析为本地日期 - 或统一约定：所有日期字符串视为“无时区日期”，忽略时间部分
- 避免用
new Date(input.value).toISOString()直接发——这会把本地日期错误转成 UTC 时间点
Date 构造函数，就自动绑定时区逻辑；而 HTML5 date 输入框的 value，恰恰是唯一无需担心时区歧义的原始 ISO 日期来源。 
