的值必须用 value 获取，返回如 "14:30" 的字符串；valueasnumber 恒为 nan；未选时值为空字符串 ""，非 null；值无时区信息，需手动处理；ios safari 中 change 仅在确认后触发。
获取 <input type="time"> 的值必须用 value，不是 valueAsNumber
HTML 时间输入框返回的是字符串格式（如 "14:30"），不是时间戳或毫秒数。valueAsNumber 在 type="time" 上始终返回 NaN，这是浏览器规范行为，不是 bug。想拿到小时和分钟，得自己解析字符串。
- 直接读取：
document.getElementById("timeInput").value→ 返回"09:45"（注意：可能带前导零） - 别用：
element.valueAsNumber→ 一定为NaN，对time类型无效 - 若需转成 Date 对象，得拼接一个日期基准（如
"1970-01-01T" + value），否则new Date("09:45")会出错或返回 invalid date
用户未选择时 value 是空字符串，不是 null 或 undefined
即使用户点开时间控件但没确认，或清空了输入框，value 仍为 ""（空字符串），不会变成 null。这和 type="number" 或受控组件逻辑不同，容易在表单校验时漏判。
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 安全判断是否填写：
if (input.value === "")，不要写if (!input.value)（会把"00:00"误判为 false） - 提交前检查：
if (!input.value.trim())足够，因为value不含空格 - 后端接收时也应容错：空字符串需明确视为“未提供”，而非默认时间
时区问题：value 始终是本地时区的 HH:MM，不带时区信息
<input type="time"> 完全不处理时区，它只采集用户本地系统设置下的时间显示值。比如用户在北京选 "15:00"，和用户在纽约选 "15:00"，得到的 value 都是字符串 "15:00"，没有隐含 UTC 偏移。
- 如果业务需要统一转 UTC，必须额外获取用户时区：
Intl.DateTimeFormat().resolvedOptions().timeZone，再结合value手动计算 - 服务端不能假设
"15:00"是 UTC 或服务器本地时间 —— 它只是“用户看到的那个钟面” - 避免用
new Date().setHours(...)直接设时间，因为Date对象内部存的是毫秒数，会受本地时区影响，造成歧义
兼容性与移动端行为差异：iOS Safari 不触发 change 事件直到用户确认
在 iOS Safari 中，用户打开时间选择器后滑动调整时间，但点击“完成”前，input 元素的 value 不会实时更新，change 事件也只在点击确认按钮后才触发。这和 Chrome/Android 行为不一致。
- 依赖实时响应？别只监听
change，加一层input事件监听（但注意 iOS 上input事件在确认前仍不会更新value） - 更稳妥的做法：监听
blur+change，并在表单提交前做最终读取 - 测试时务必在真机 iOS 上验证，模拟器有时表现不同
valueAsNumber 可用，或者拿 value 直接塞进 Date 构造函数。时间输入框看着简单，但字符串、时区、事件时机这三块不细看很容易出错。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
