HTML原生date输入框的min/max限制需同时满足格式（YYYY-MM-DD）、赋值方式（直接属性赋值或setAttribute）和校验补位（如value超限需手动清空）三重条件，否则浏览器静默忽略。
HTML 原生 input[type="date"] 的可选范围限制，靠 min 和 max 属性就能生效，但必须严格满足格式、赋值方式和校验补位三重条件；否则浏览器直接忽略，用户照样能选到非法日期。
为什么 min/max 设置了却没用
常见现象是日历控件里日期没变灰、手动输入超范围值也不报错、甚至提交成功。根本原因不是属性写错了，而是：
-
min或max值不是标准YYYY-MM-DD格式：比如"2026-5-10"（缺零）、"2026/05/10"（斜杠）、"2026-05-10T00:00"（带时间）都会被浏览器静默丢弃 - 用 JS 赋值时用了错误方式：
el.min = new Date().toISOString()返回带时间的字符串，要截取前 10 位：el.min = new Date().toISOString().slice(0, 10) - 初始
value已超出min/max范围：Chrome 会清空输入框，Firefox 可能保留但checkValidity()返回false，容易误判为“限制失效” - Safari（尤其是 iOS ≤ 15.5）对动态更新
min支持弱，设完不刷新 UI，需额外触发el.dispatchEvent(new Event('input'))或el.blur()
如何动态设置未来 14 天可选范围
业务常需“只能选今天起 14 天内”的日期，不能写死，得用 JS 计算并注入。关键不是“怎么算”，而是“怎么塞进去不翻车”：
- 计算今天：
new Date().toISOString().slice(0, 10)—— 简洁可靠，无需手拼年月日 - 计算 14 天后：
new Date(Date.now() + 14 * 864e5).toISOString().slice(0, 10)（864e5= 86400000，即一天毫秒数） - 赋值必须用
setAttribute或直接属性赋值：input.min = todayStr；input.max = laterStr，不要用setAttribute('value', ...)混淆 - 如果
input.value已存在且超出新max，浏览器不会自动清空，需手动判断：if (input.value && input.value > input.max) input.value = ''
两个日期联动时 min 怎么同步才有效
比如“结束日期不能早于开始日期”，只给 end 设 min 是不够的，必须实时响应变化：
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
立即学习“前端免费学习笔记（深入）”；
- 监听
start的change事件，更新end.min = start.value；若start.value为空，应设end.min = ''（清空限制），否则end将无法选择任何日期 - 监听
end的change事件，做反向校验：if (end.value && start.value && end.value ，此时仅清空 <code>end.value不够，还得调用end.setCustomValidity('结束日期不能早于开始日期')并触发end.reportValidity()强制提示 - 移动端 Safari 对
min动态更新后日历不刷新，建议在设完end.min后加end.focus(); setTimeout(() => end.blur(), 0)强制重绘
禁用周末或特定星期几为什么不能只靠 min/max
因为 min/max 是连续时间区间约束，而“周日不可选”是非连续、离散的逻辑——原生 HTML 没有对应属性。你只能：
- 用
change事件拦截：选完立刻new Date(input.value).getDay()判断，0 或 6 就清空 + 提示 - 注意
getDay()返回的是本地时区星期，无需转换；但若input.value为空，new Date('')在旧浏览器可能返回Invalid Date，要先加if (!input.value) return - 真正禁用日历面板里的周日/周一，必须换自定义组件（如 Flatpickr 的
disable函数），原生控件做不到 - 所有前端校验都只是体验层，服务端收到日期后必须重新解析并检查
date.getDay()或等效逻辑，否则绕过 JS 就能提交周末
最容易被忽略的一点：无论 min、max 还是 change 校验，都拦不住用户键盘输入或粘贴非法值。真正可靠的边界永远在服务端，前端限制只是降低误操作概率的辅助手段。
