max属性限制date输入框上限需用yyyy-mm-dd格式，受本地时区影响，不阻止手动输入，必须配合js校验和后端验证。
max 属性可以直接限制 <input type="date"> 的可选日期上限，浏览器会自动禁用或灰掉超出范围的日期——但必须注意格式和时区陷阱，否则它可能完全不生效。
日期格式必须是 YYYY-MM-DD
浏览器只认严格 ISO 8601 格式的字符串，比如 "2025-12-31"。传 "2025/12/31"、"31-12-2025" 或带时间的 "2025-12-31T00:00" 都会被忽略，max 形同虚设。
实操建议：
- 后端返回日期时，用
toISOString().split('T')[0]或formatISO(date, { representation: 'date' })（date-fns）确保格式 - 动态设置时别拼字符串：
input.max = new Date().toISOString().split('T')[0]比input.max = `${y}-${m}-${d}`更可靠 - 服务端渲染中，直接写死属性：
max 值受本地时区影响，不是 UTC
max 比较的是用户本地时区下的日期。比如你设 max="2025-01-01"，在东京用户看到的是 2025-01-01 00:00 JST，在旧金山则是 2024-12-31 16:00 PST——但两者都显示“上限为 2025-01-01”，且无法选择当天之后的日期。这没问题；但如果你按 UTC 时间计算上限（比如数据库存的是 UTC），就容易少算一天。
常见错误现象：
- 用户在东八区选了
2025-01-01，提交后后端校验失败，提示“超出允许范围” - API 返回的 UTC 时间
"2025-01-01T00:00:00Z"直接赋给max，结果在纽约被解释成2024-12-31
解决方法：把 UTC 时间转成本地日期再设 max，例如：new Date(Date.UTC(2025, 0, 1)).toISOString().split('T')[0]（注意 Date.UTC 月份从 0 开始）。
max 不会阻止手动输入或 JS 修改值
原生 max 只约束 UI 行为（日历弹窗、上下箭头、滚动选择），不拦截 input.value = "2099-01-01" 或用户手动敲字。如果业务强依赖上限控制，必须配合 JS 校验和后端二次验证。
实操建议：
- 监听
input和change事件，检查input.valueAsDate > new Date(input.max) - 对非法值立即重置或报错：
if (input.value && new Date(input.value) > maxDate) input.value = "" - 永远不要省略后端校验——前端限制只是体验优化
真正容易被忽略的是时区转换那步：很多人以为 max 是个纯字符串比较，其实它背后隐式做了本地时区解析。设错一天，上线后用户在跨时区地区就可能卡在表单里出不来。
