HTML <input type="time"> 仅支持 "HH:MM" 或 "HH:MM:SS" 字符串格式，默认值需严格两位数（如 "09:30"），不接受时间戳或 ISO 字符串；时区信息不随值提交，需额外处理。
time控件不支持设置默认时间戳，只能用字符串格式
HTML <input type="time"> 不接受 new Date().getTime() 或毫秒数，只认 "HH:MM" 或 "HH:MM:SS" 格式的字符串。传入 1717027200000 或 "2024-05-30T12:00" 都会变为空值或被浏览器忽略。
常见错误现象：表单初始化后显示空白，但控制台无报错；用户提交时拿到空字符串。
- 必须用
.toTimeString().slice(0, 5)或手动拼接，例如："14:30" - 如果后端返回的是 ISO 时间（如
"2024-05-30T14:30:00"），需先解析再截取：new Date(isoStr).toTimeString().slice(0, 5) - 注意时区：
toTimeString()返回本地时区，若需 UTC 时间，请用getUTCHours()和getUTCMinutes()手动格式化
value属性必须严格两位数，否则部分浏览器（如 Safari）会清空输入框
写成 value="9:30" 或 value="14:5" 是无效的。Chrome 可能容忍，但 Safari、旧版 Edge 会直接忽略该值，渲染为空。
使用场景：动态设置默认值时，容易因忘记补零出问题。
立即学习“前端免费学习笔记（深入）”；
- 小时和分钟都必须是两位数，例如：
"09:30"、"23:05" - 推荐用函数标准化：
String(date.getHours()).padStart(2, '0') + ':' + String(date.getMinutes()).padStart(2, '0') - 不要依赖
date.toLocaleTimeString(navigator.language, {hour12: false})，它在中文环境可能返回"下午 02:30"，完全不兼容
移动端 time 输入框行为差异大，无法靠 CSS 完全定制外观
Android Chrome 会唤起原生滚轮时间选择器，iOS Safari 则是带“取消/完成”按钮的底部弹窗。你写的 appearance: none 或 background 样式基本无效，且强行覆盖可能触发 Safari 的样式重置逻辑。
性能与兼容性影响：试图用 ::-webkit-inner-spin-button 隐藏上下箭头，在 iOS 上根本不起作用；加 pointer-events: none 会导致整个控件不可交互。
- 别花时间写伪元素隐藏原生控件——它本来就没有可隐藏的可见按钮
- 若需统一体验，建议用第三方库（如 flatpickr）接管，但要注意其
time_24hr: true配置必须显式开启 - 测试重点放在真机：模拟器常无法复现 iOS 底部弹窗的 focus/blur 顺序问题
form 表单提交时，time 控件的 value 始终是本地时区字符串，后端需自行处理时区
用户在北京选了 "15:00"，法国用户也选了 "15:00"，两者提交的 value 都是字面量 "15:00"，不含任何时区信息。浏览器不会自动转成 UTC 或附带 timezoneOffset。
这意味着：仅靠 input[type=time] 无法表达“UTC 15:00”或“东八区 15:00”，它只是一个脱离上下文的时间片段。
- 如果业务需要时区语义，必须额外提供
<select>让用户选时区，或用<input type="datetime-local">（但后者包含日期，且仍不带时区） - 后端收到
"15:00"时，不能假设它是 UTC —— 它就是用户本地界面显示的那个时间 - 前端若需换算，可用
new Date().toLocaleTimeString('en-GB', { timeZone: 'Asia/Shanghai', hour12: false })获取当前时区下的标准格式，但不能反向推导原始时区
最易被忽略的一点：time 控件天生不具备“有效性上下文”。它不关心这个时间属于今天、明天还是某年某月，也不校验是否早于当前时间——所有逻辑都得自己补。
