min属性必须设为“2026-08-05”且仅接受YYYY-MM-DD格式，动态设置推荐toISOString().slice(0,10)；max非必需但可限制未来日期；需监听change事件校验并清空非法值；后端必须独立验证日期范围。
min 属性必须设为今天，且格式要严格
原生 input[type="date"] 限制未来日期，核心就靠 min 属性。它只接受 YYYY-MM-DD 格式字符串，任何偏差（比如 "2026/08/05"、"05-08-2026" 或带时间的 "2026-08-05T00:00"）都会被浏览器忽略，min 形同虚设。
当前是 2026 年 8 月 5 日，所以合法值只能是 "2026-08-05"。动态设置时别手动拼串，容易漏补零：
-
new Date().toISOString().slice(0, 10)最稳——直接截取 ISO 字符串前 10 位 - 避免用
toLocaleDateString()，不同地区格式不一（如"8/5/2026"） - 也别用
getMonth() + 1手动拼：月份/日期没padStart(2, '0')就会变成"2026-8-5"，无效
max 属性不是必须，但加了更安全
仅设 min 能禁掉过去日期，但用户仍可选未来任意远的日期（比如 2100 年）。如果业务要求“仅限未来 N 天”，就得配 max。比如限制未来 14 天，max 应设为 2026-08-19。
计算时注意跨月问题：
立即学习“前端免费学习笔记（深入）”；
-
setDate(getDate() + 14)在 8 月 5 日没问题，但在 1 月 31 日 + 14 天可能跳到 2 月 14 日（正常），或在非闰年 2 月 28 日后 + 14 天跳到 3 月 14 日（也正常）——setDate本身会自动进位，不是 bug - 真正风险是时区：用
new Date()获取的是本地时间，toISOString()转出的是 UTC 时间。但min/max比较逻辑基于用户本地日历日，所以直接用toISOString().slice(0,10)是安全的 - 不要用 UTC 时间直接赋值，比如
Date.UTC(2026, 7, 19)再转——多此一举且易错（Date.UTC月份从 0 开始）
用户仍可能绕过 min/max，必须监听校验
min 和 max 只控制 UI（日历里置灰、上下键禁用），完全不阻止以下行为：
- 手动输入超范围日期，比如敲
"2020-01-01" - 粘贴非法日期
- JS 脚本直接赋值：
input.value = "1999-01-01"
因此必须监听 change 事件做二次校验：
- 检查
input.valueAsDate是否存在，再和new Date(input.min)比大小 - 若非法，立刻清空：
input.value = ""，并给用户明确提示 - 别只监听
input事件——用户拖动日历未松手时频繁触发，浪费资源
服务端永远要重复校验，前端只是体验层
所有前端限制（min、max、JS 校验）都可在 DevTools 里被轻易绕过。真实数据入库前，后端必须独立解析并验证日期是否落在允许范围内。
最容易被忽略的一点是：前端用的是本地日历日，后端存的可能是 UTC 时间戳或时区无关的日期字符串。如果前后端对“今天”的定义不一致（比如后端按 UTC 判定 2026-08-05，而用户在东京时区本地已是 2026-08-06），就会出现“前端允许提交、后端拒绝”的情况。统一锚点（比如全部按用户所在时区的午夜起算）比强行转 UTC 更可靠。
