原生 input[type="date"] 的校验提示无法国际化，因浏览器硬编码且不响应 lang 属性；需禁用原生校验（novalidate）、手动检查并调用 setCustomValidity() 与 reportValidity() 实现本地化提示，同时注意时区问题统一用 UTC 解析日期。
原生 input[type="date"] 的校验提示无法国际化，浏览器硬编码、不可覆盖、不响应 lang 属性 —— 你改不了它，只能绕开它。
为什么 setCustomValidity() 对 date 类型的内置错误无效
当用户未选择日期却提交表单时，required 触发的错误提示（如 Chrome 显示 “Please select a date.”）是浏览器 UI 层硬编码的字符串，不是通过 ValidityState 暴露的可干预字段。调用 setCustomValidity() 只能覆盖你手动触发的校验（比如用 JS 检查格式），但对原生 required / min / max 失败时的提示完全不起作用。
-
element.validity.valueMissing为true时，浏览器直接显示自己的提示，忽略你之前设的setCustomValidity("请选择日期") - 同理，
min或max超限时（如选了早于min="2024-01-01"的日期），Chrome 显示 “The specified value is less than the minimum allowed value.”，Safari 显示类似英文，且均无法拦截或替换 - 这些提示不随页面
lang="zh-CN"变化，也不读取document.documentElement.lang或<html lang>
如何让 date 输入的错误提示真正本地化
必须放弃依赖原生校验提示，改用 JS 主动控制校验流程和提示文案。核心是：禁用原生提示 + 手动触发 + 自定义消息。
- 给
input[type="date"]添加novalidate属性（仅对该 input 生效），或整个<form>加novalidate，阻止浏览器弹默认提示 - 监听
submit事件，在里面调用event.preventDefault()，然后手动检查：!el.value、el.value && new Date(el.value) < minDate等 - 检查后调用
el.setCustomValidity("请选择有效日期")，再调用el.reportValidity()—— 这时显示的就是你传的中文文案 - 注意：
reportValidity()必须在元素聚焦态下才显示气泡；若用户没点过该 input，建议先el.focus()再reportValidity()
兼容性差的场景下，date 降级后提示怎么统一处理
当运行时检测到不支持 showPicker（即 el.type === 'date' && 'showPicker' in el 为 false），你大概率已降级为 type="text" + flatpickr 或其他日历库。此时原生校验彻底失效，所有提示必须由 JS 全权接管。
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
立即学习“前端免费学习笔记（深入）”；
- 不要复用
required属性来触发提示 —— 它对type="text"只检查空值，且提示仍是英文 - 统一用
input和blur事件监听输入变化，结合正则/^\d{4}-(0[1-9]|1[0-2])-(0[1-9]|[12]\d|3[01])$/校验格式 - 校验失败时立即
el.setCustomValidity("日期格式错误，例如：2024-01-01")，并调用el.reportValidity() - 如果用了 flatpickr，它的
onChange回调里也要做 min/max 校验，并同步更新el.value和el.setCustomValidity()
容易被忽略的时区与格式陷阱
用户看到的界面可能是“2024年6月13日”，但 el.value 永远是 "2024-06-13"，且这个字符串在不同地区解析成 Date 实例时可能偏移一天 —— 这会直接影响 min/max 判断结果，导致提示文案逻辑错乱。
- 别直接用
new Date(el.value)比较，它按本地时区解析，"2024-06-13"在东八区是2024-06-13T00:00+08:00，比 UTC 时间早 8 小时 - 正确做法：统一转成 UTC 零点比较，例如
new Date(el.value + 'T00:00:00Z')，或用Date.parse(el.value)（它按 UTC 解析 ISO 日期字符串） - 服务端返回的 min/max 日期也应是纯
"YYYY-MM-DD"字符串，前端提取后同样用Z后缀构造 Date，避免跨时区误判
真正麻烦的不是翻译文案，而是日期值在不同时区下的语义一致性 —— 提示写成中文，但判断逻辑出错，用户只会觉得“提示不准”。
