HTML原生的step属性仅对键盘输入和上下箭头有效，设为900秒可限制15分钟粒度，但点击时间选择器时失效；强约束需结合JS校验或，且服务端必须二次校验。
HTML <input type="time"> 本身不支持分钟粒度限制
浏览器原生 <input type="time"> 只接受 step 属性，但它的单位是秒，且**仅对键盘输入和上下箭头有效**；点击时间选择器（尤其是 Chrome/Edge 的弹出轮盘）时，step 完全被忽略，用户仍可选任意分钟（如 09:07、09:13）。这不是 bug，是规范行为。
step 参数必须是秒数，且只影响部分交互方式
想限制为 15 分钟一档（即 00、15、30、45），step 必须设为 900（15 × 60 秒）：
<input type="time" step="900">
但这只在以下场景起作用：
- 用户用键盘输入后按 Tab 或回车 —— 浏览器会自动对齐到最近的 15 分钟档位（如输
09:07会跳成09:00） - 用鼠标滚轮或上下箭头调节分钟 —— 每次增减 15 分钟
- 点击时间选择器弹窗（尤其是移动端或 Chrome 桌面端）——
step失效，分钟仍可自由点选
真正可控的方案：用 <select></select> 或 JS 拦截 + 校验
如果业务要求「任何操作路径下都只能选特定分钟」，必须放弃纯 HTML 方案。推荐两种实操路径：
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
立即学习“前端免费学习笔记（深入）”；
-
轻量级：用
<select></select>列出所有合法选项 —— 适合固定时段（如会议预约每 30 分钟一场），代码简洁、100% 可控，无兼容性问题 -
灵活性：监听
input和change事件，手动对齐分钟 —— 示例逻辑：
当用户输入或选择09:07，立即转为09:00；若输入09:22，转为09:15。注意要防死循环（避免重复触发input）
关键代码片段（对齐到最近的 15 分钟）：
const input = document.querySelector('input[type="time"]');
input.addEventListener('input', () => {
const time = input.value;
if (!time) return;
const [h, m] = time.split(':').map(Number);
const roundedM = Math.round(m / 15) * 15 % 60;
const newTime = `${h.toString().padStart(2, '0')}:${roundedM.toString().padStart(2, '0')}`;
if (newTime !== time) {
input.value = newTime;
}
});移动端兼容性差异大，别依赖 step 做强约束
iOS Safari 的时间选择器完全忽略 step；Android Chrome 虽支持但 UI 不提示步长，用户无感知；部分国产浏览器甚至不渲染 step 效果。真实项目中，只要需求明确要求「禁止非指定分钟提交」，服务端校验是最后一道防线，前端拦截只是体验优化。
最易被忽略的一点：用户可能绕过 UI，直接用 DevTools 修改 value 属性 —— 所以无论前端多严密，后端收到时间后，仍需做 minutes % 15 === 0 这类校验。
