<input type="time"> 无法直接生成时间戳，因其仅提供时分而无日期，需显式结合日期（如当天）构造；推荐用 new Date().setHours(h, m) 或 input.valueAsDate，避免字符串解析歧义。
HTML <input type="time"> 无法直接生成时间戳
因为 <input type="time"> 只提供时分（如 "14:30"），不含日期信息，而时间戳是毫秒级的绝对时间点，必须依赖具体日期才能计算。浏览器不会自动补全日期（比如默认用今天），所以不能靠 new Date(input.value).getTime() 直接用——它会按当前年月日解析，但行为不可靠（不同浏览器对无日期时间字符串的解析规则不一致，ECMAScript 规范未强制要求）。
常见错误现象：new Date("15:45").getTime() 在 Chrome 可能返回今天 15:45 的时间戳，在 Safari 可能返回 NaN 或错误值。
- 必须显式指定日期（通常是当天，但也可能是用户选的其他日期）
- 推荐用
new Date(year, month, day, hour, minute)构造，避免字符串解析歧义 - 注意
month是 0 起始（0 = 一月），hour和minute需从value中解析
获取当前日期 + time 输入值 → 安全转时间戳
这是最常见场景：用户只选时间，你希望得到「今天该时刻」的时间戳。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 用
input.valueAsDate—— 它会返回一个Date对象，但注意：**它只在 input 有value且浏览器支持时才有效；若 input 为空或不兼容，返回null** - 更稳妥的做法是手动拼装：
new Date().setHours(hour, minute, 0, 0)，再调用.getTime() - 别用
new Date().setTime(...)，容易误改原对象；setHours返回的是时间戳，不是 Date 实例
示例：
const timeInput = document.querySelector('input[type="time"]');
timeInput.addEventListener('change', () => {
const [h, m] = timeInput.value.split(':').map(Number);
if (isNaN(h) || isNaN(m)) return;
const ts = new Date().setHours(h, m, 0, 0); // 返回时间戳（毫秒）
console.log(ts); // 如 1728133800000
});
配合日期输入框（<input type="date">）生成完整时间戳
当页面同时有 date 和 time 输入框时，需合并二者值构造精确时间戳。
关键点：
-
dateInput.value是"YYYY-MM-DD"格式字符串，可直接传给new Date()构造（规范支持） -
timeInput.value是"HH:MM"或"HH:MM:SS"，需拆解为数字 - 组合方式：先用日期字符串创建 Date 实例，再用
setHours覆盖时分秒（避免字符串拼接引发的时区/格式风险） - 务必检查两个 input 是否都有值，否则
setHours会修改一个无效 Date 对象
示例：
const dateInput = document.querySelector('input[type="date"]');
const timeInput = document.querySelector('input[type="time"]');
function getTimestamp() {
if (!dateInput.value || !timeInput.value) return null;
const date = new Date(dateInput.value); // 安全，格式受控
const [h, m] = timeInput.value.split(':').map(Number);
return date.setHours(h, m, 0, 0);
}
注意时区问题：getTime() 总是返回 UTC 时间戳
new Date(...).getTime() 返回的是自 1970-01-01T00:00:00Z 起的毫秒数，与本地时区无关——这是正确行为，也是时间戳的标准定义。
但容易被忽略的是：当你用 new Date().setHours(...)，setHours 操作的是本地时区的小时（即你看到的系统时钟），所以结果时间戳对应的是「本地时间的那一刻」的 UTC 值。这通常正是你想要的。
如果你需要基于 UTC 时间（比如服务端统一用 UTC 存储），那就不能用 setHours，而要用 setUTCHours，并确保输入的时分是 UTC 值——但这种情况极少，绝大多数前端场景应使用本地时间构造。
真正容易踩的坑是：把 timeInput.value 当作 UTC 时间去解析，却不做时区转换。只要没明确要求 UTC 输入，就别这么干。
