input type="time" 的显示格式由系统本地设置决定，无法通过HTML属性强制改为12小时制或显示秒；value必须为"HH:MM"或"HH:MM:SS"格式，且需补零，前端无法覆盖系统AM/PM显示逻辑。
input type="time" 的显示格式无法通过 HTML 属性直接改成 12 小时制（如 2:30 PM）或带秒（HH:MM:SS），它始终按浏览器本地设置渲染为 24 小时制或 12 小时制，且不显示秒——这是规范行为，不是 bug。
为什么 value 必须是 "HH:MM" 格式
HTML5 规范强制要求 input type="time" 的 value 属性只能是 "HH:MM"（如 "14:30"）或 "HH:MM:SS" 字符串。哪怕你传入 "2:30 PM" 或 "14:30:00.123"，浏览器会静默忽略或清空输入框。
- 合法写法：
value="09:00"、value="23:59"、value="14:30:00" - 非法写法：
value="9:00"（缺零）、value="2:30 PM"（含 AM/PM）、value="14:30:00.5"（毫秒） - 服务器端渲染时，务必提前补零：用
String(d.getHours()).padStart(2, '0')拼接，别依赖toLocaleTimeString()直接输出
如何让时间输入框显示为 12 小时制（AM/PM）
不能靠 lang 或 dir 属性切换，浏览器是否显示 AM/PM 完全取决于用户操作系统语言和地区设置（例如 macOS 设置为 English (US) 时显示 2:30 PM，设为 English (UK) 则只显示 14:30）。前端无法强制覆盖。
- 想统一显示 AM/PM？必须放弃原生
type="time"，改用type="text"+ JS 格式化 + 隐藏的input type="hidden"存 ISO 时间 - 若仅需视觉提示，可在 label 里写明：“请选择时间（例如：2:30 PM）”，但不要指望 input 本身渲染成那样
- 移动端尤其不可控：iOS Safari 固定用系统设置，Android 各厂商键盘样式各异，无统一 API 干预
min、max 和 step 的实际限制效果
这三个属性只约束用户可选范围和步长，但不会阻止 JS 赋值或手动输入——它们是 UI 层面的“建议”，不是数据校验。
立即学习“前端免费学习笔记（深入）”；
-
min="09:00"+max="17:00"：用户无法滑动/点击选择 8:59 或 17:01，但 JS 仍可设input.value = "08:00"，且表单提交时该值依然有效 -
step="300"（5 分钟）：Chrome 会将分钟步进改为 5 的倍数（如 00、05、10…），但 Safari 可能忽略step，只支持默认 1 分钟 - 真正需要强校验？必须监听
change或blur事件，用正则/^([01]?[0-9]|2[0-3]):[0-5][0-9]$/检查，并手动重置非法值
JavaScript 动态设置时间时的时区陷阱
用 new Date().toTimeString().slice(0,5) 或 toLocaleTimeString() 获取字符串再赋值给 input.value 极易出错——前者返回的是本地时区带秒的字符串（如 "14:30:22"），后者可能含 AM/PM 或非标准分隔符。
- 安全做法：只用
getHours()和getMinutes()提取数字，手动拼接并补零：`${h.toString().padStart(2,'0')}:${m.toString().padStart(2,'0')}` - 避免
toISOString()：它返回 UTC 时间，东八区用户调new Date().toISOString().slice(11,16)可能拿到前一天的小时 - 注意：用户修改时间后，
input.value始终是字符串，不是Date对象；要参与计算，得先转成new Date(`1970-01-01T${input.value}`)
最常被忽略的一点：即使你用 JS 把 input.value 设成了 "09:00"，用户点击清空按钮（×）后，它的值会变成空字符串 ""，而不是 null 或 undefined——后端接收时必须显式判断空字符串，不能只检查 == null。
