不能真正禁止手动输入，应允许输入但清除非合法值：用min/max约束日历UI，change事件中用new Date()校验并清空非法值，配合setCustomValidity和reportValidity提供可访问反馈，服务端必须重复校验。
不能真正“禁止手动输入”，但可以安全地让键盘输入无效、只保留日历选择——这是浏览器原生行为与可访问性要求共同决定的底线。
Firefox 里 readonly 会禁用日历面板，别用
很多人试过 readonly，发现点击小日历图标没反应。这是因为 Firefox 将 readonly 视为完全不可交互，连日历弹窗都禁掉了。Chrome 和 Safari 虽然允许点击日历，但 readonly 本身不阻止粘贴或开发者工具改值，实际防护力为零。
- 它违反 WCAG 键盘可访问原则：屏幕阅读器用户依赖键盘导航和 Enter 确认，
readonly直接切断这条路径 - 即使加了
onkeydown="return false"，Firefox 仍可能忽略——它的 date 输入框对键盘事件捕获机制特殊 - 真正该做的是：允许输入，但让非法值无法留存
用 min 和 max 配合 change 校验，比拦截更可靠
原生 input[type="date"] 的 min/max 不拦截输入，但它们能约束日历 UI，并在 change 事件中提供校验依据。关键不是“不让输”，而是“输完立刻清”。
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
- 监听
change（不是input）：用户点选日期或失焦确认后才触发，避免边输边校验的干扰 - 用
new Date(input.value)转换再比较，别直接字符串比大小（"2026-08-10" 会错） - 校验失败时设
input.value = ""，比弹alert或留着乱码更干净 - 配合
input.setCustomValidity("提示文字")+input.reportValidity()，触发表单原生反馈且兼容读屏器
移动端和 Safari 的 min/max 基本不可信
iOS Safari 和多数 Android WebView 忽略 min/max 的 UI 禁用逻辑，也不触发 :invalid 伪类。你看到 Chrome 里灰掉的日期，在 iPhone 上可能全都能点、全都能输。
- 别靠
input:invalid { border: 1px solid red; }做视觉提示——它在 Safari 里大概率不生效 - 服务端必须重复校验：收到的
value可能是空、"2026-02-30"、"2026/02/29"或任意字符串 - 若业务强依赖精确控制（如预约系统），直接上
flatpickr或react-datepicker更省心——它们真能禁用指定日期、显示灰色不可点状态
最容易被忽略的是时区和后端解析
用户在北京选 "2026-08-11"，浏览器提交的是 UTC 时间戳对应的 ISO 字符串（如 "2026-08-10T16:00:00Z"）。后端如果用 new Date("2026-08-11") 解析，可能误判为 8 月 10 日。
- 最稳做法：后端直接按字符串截取处理，比如用正则
^\d{4}-\d{2}-\d{2}$校验格式，再交给标准库（如 Python 的datetime.date.fromisoformat()）解析 - 动态生成
min/max时避开setDate()坑：用toISOString().slice(0, 10)获取本地日历日，否则遇到 1 月 31 日加 7 天会跳到 3 月 3 日
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
