HTML5 input[type="date"] 的值永远是 "YYYY-MM-DD" 格式，浏览器强制标准化为 ISO 8601；需用 new Date(input.value) 转换后再调用 toLocaleDateString() 安全格式化，避免时区、兼容性及显示错误。
HTML5 input[type="date"] 的值永远是 "YYYY-MM-DD"
浏览器强制将 input[type="date"] 的 value 属性标准化为 ISO 8601 格式（如 "2024-03-15"），不管用户看到的界面是“2024年3月15日”还是“15/03/2024”。这是规范行为，不是 bug。
常见错误现象：
– 想直接用 new Date(input.value) 渲染成中文格式，结果时区偏移导致日期错一天
– 把 input.value 当作“用户看到的格式”去展示，页面显示却是 2024-03-15
– 尝试用 toLocaleDateString() 直接格式化 input.value 字符串，没转成 Date 对象就报错
- 必须先用
new Date(input.value)转成日期对象，再格式化；否则所有toLocale*方法都无效 - 注意：
new Date("2024-03-15")在某些旧版 Safari 中可能返回Invalid Date，稳妥写法是new Date(...input.value.split("-"))或补全时间部分：new Date(input.value + "T00:00") - 如果后端要接收非标准格式（如
"20240315"或"15-03-2024"），不能改input.value，得在提交前手动转换
用 toLocaleDateString() 安全格式化显示值
这是最轻量、无需引入库的方案，但参数和兼容性容易踩坑。
使用场景：表单下方实时显示“您选的是：3月15日，星期五”，或提交前预览。
立即学习“前端免费学习笔记（深入）”；
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
- 推荐写法：
new Date(input.value).toLocaleDateString("zh-CN", { year: "numeric", month: "long", day: "numeric" })→ 输出"2024年3月15日" - 避免只传语言字符串（如
"zh-CN"）：不同浏览器默认格式不同（Chrome 可能出"2024/3/15"，Firefox 可能是"2024年3月15日"） - 不要依赖
weekday选项在所有环境都生效——iOS Safari 15.4 之前不支持"short"以外的weekday值 - 若需固定格式如
"15/03/2024"，别硬凑toLocaleDateString()，改用字符串拼接：`${d.getDate()}/${d.getMonth()+1}/${d.getFullYear()}`（注意月份从 0 开始）
绑定框架（Vue/React）里怎么处理双向格式化
原生 input[type="date"] 不接受自定义格式的 value，所以框架层的“双向绑定”本质仍是同步 ISO 格式字符串。所谓“格式化显示”，只能发生在视图层渲染时，而非输入框内部。
常见错误现象：
– Vue 中写 v-model="formattedDate" 并试图让输入框显示“2024年3月15日”，结果输入框变空或报错
– React 用 value={chineseDate} 导致控件不可编辑
- Vue：保持
v-model="isoDate"（String类型，如"2024-03-15"），显示用计算属性：computed: { displayDate() { return this.isoDate ? new Date(this.isoDate).toLocaleDateString("zh-CN") : "" } } - React：用
value={isoDate}+onChange={e => setIsoDate(e.target.value)}，展示区域单独写{isoDate && new Date(isoDate).toLocaleDateString("zh-CN")} - 切勿用
ref手动 setAttribute 修改input.value—— 浏览器会拒绝非 ISO 格式值，且破坏表单校验逻辑
移动端日期选择器样式与兼容性底线
Android Chrome 和 iOS Safari 的原生日期选择器 UI 差异大，且无法用 CSS 完全定制。关键不是“怎么美化”，而是“怎么确保它能弹出来并正确回填”。
- iOS Safari 低版本（min/
max属性支持弱，设了可能直接禁用整个控件；测试时务必用真机 - 部分国产安卓 WebView（如微信内置）会降级为文本输入框，此时需要监听
input事件 + 正则校验（/^\d{4}-\d{2}-\d{2}$/），并 fallback 提示 - 不要给
input[type="date"]设placeholder—— 所有浏览器都会忽略，还可能干扰可访问性 - 如果项目必须支持 IE 或老旧 Android，别挣扎，直接上
flatpickr或dayjs+ 自定义输入框，原生方案此时已不是“省事”，而是埋雷
真正麻烦的从来不是格式化函数怎么写，而是你得同时应付 Safari 的时区 bug、微信 WebView 的降级逻辑、还有设计师坚持要“和 iOS 系统一模一样”的那个日期弹窗动效——而原生控件根本不给你动效控制权。
