HTML <input type="time"> 的 value 必须为严格 HH:mm 格式（如"09:45"），非标准格式赋值失败；修改后需手动派发 input 和 change 事件；始终按用户本地时区解析，跨时区需显式转换；旧版 Safari 存在赋值失效兼容性问题。
HTML <input type="time"> 的 value 属性必须是 24 小时制字符串
直接赋值非标准格式（如 "5:30"、"05:30 AM"、"17:30:00"）会导致赋值失败或清空——浏览器只接受严格匹配 HH:mm 格式的字符串（秒部分可省略，但不能多出空格或 AM/PM）。动态修改前必须先格式化。
常见错误现象：input.value = "5:30" 看似合理，实际在大多数浏览器中会变成空值；input.value = new Date().toTimeString() 返回带秒和时区的长字符串，也无效。
- 正确做法：用
String.prototype.padStart()补零，确保两位小时+两位分钟，例如`${hours.toString().padStart(2, '0')}:${minutes.toString().padStart(2, '0')}` - 如果从
Date对象取时间，别用getHours()/getMinutes()后拼接再手动补零——容易漏掉0，推荐用toISOString().slice(11,16)（注意：仅适用于本地时区为 UTC+0 的场景，否则有偏移） - 更稳妥的方式是用
Intl.DateTimeFormat或专门的时间格式化函数，但简单场景下手动 padStart 最轻量
通过 JavaScript 修改 <input type="time"> 值时需触发 input 和 change 事件
单纯设置 input.value = "09:45" 不会触发表单验证、监听器或框架（如 Vue/React）的响应式更新。用户看不到变化，或后续逻辑不执行。
使用场景：比如点击按钮跳转到当前时间、或根据另一个输入框联动更新时间。
立即学习“前端免费学习笔记（深入）”；
- 必须手动派发事件：
input.dispatchEvent(new Event('input', { bubbles: true }));（触发实时响应） - 如需模拟用户“完成编辑”，再加
input.dispatchEvent(new Event('change', { bubbles: true })); - Vue 3 的
v-model绑定默认监听input，所以只派发input即可；React 受控组件则依赖onChange，此时change事件更关键
动态修改时注意时区与本地时间语义
<input type="time"> 永远以**用户本地时区**解释和显示，它不包含日期、也不含时区信息。如果你后端传的是 UTC 时间字符串（如 "14:30:00Z"），直接赋值会错位。
性能 / 兼容性影响：所有现代浏览器对 value 的解析行为一致，但时区处理完全交由宿主环境，没有跨浏览器差异，问题只出在开发者是否意识到这个隐含前提。
- 后端返回 ISO 时间（如
"2024-05-20T14:30:00Z"）？先用new Date(str)解析，再调用.getHours()和.getMinutes()获取本地时间点 - 后端返回纯时间字符串（如
"14:30"）且明确指“服务器所在时区”？需手动转换——不能靠new Date()自动处理，得用moment-timezone或Intl.DateTimeFormat显式指定时区 - 最简规避方式：前后端约定所有
time字段都按用户本地时区传输，避免转换逻辑
兼容旧版 Safari 或需要 fallback 时不要依赖 type="time" 的原生行为
Safari 在 iOS 15.4 之前不支持 input.value = "xx:xx" 的 JS 赋值（设置后仍为空），这是已知 bug。不是写法错，是浏览器没实现。
容易踩的坑：在兼容性检测里只查 input.type === "time"，却没测试赋值是否生效。
- 检测是否真正可用：
const input = document.createElement('input'); input.type = 'time'; input.value = '12:00'; const isWorking = input.value === '12:00'; - 不支持时，降级方案只能是自定义时间选择器（如两个
<select>或第三方库），无法用 CSS 或属性 hack 修复 - 若项目必须支持旧 Safari，建议统一用
type="text"+ 正则 + 键盘限制模拟，比处理原生 time 的兼容性更可控
