jQuery UI的Datepicker是老牌的日期选择控件，几乎所有维护传统jQuery项目的前端同学都用过。它的disable方法和readonly配置看似已经把控件锁死了，但测试时如果用Tab键聚焦到输入框，再按方向键和回车，会发现日历依然弹出、日期依然能被选中并写入输入框。这就是一个典型的禁用状态失效Bug，本文就来分析原因并给出修复方案。
为什么disabled状态下日期仍能被键盘选中
先说结论：这个问题的根源在于Datepicker对disabled和readonly的处理只停留在视觉层面，没有真正拦截键盘事件链。查看jQuery UI的源码可以发现，$.datepicker的键盘处理逻辑集中在_doKeyDown方法中，它注册在输入框的keydown事件上，只要这个事件没有被阻止，方向键移动高亮日期、回车确认选中的行为就会照常执行。
另一个原因是disabled的应用时机。很多开发者习惯这样写：
// 只设置了原生属性，没有通知Datepicker
$("#dateInput").prop("disabled", true);
// 或者只改了readonly
$("#dateInput").prop("readonly", true);
这种写法只改变了原生input的行为，Datepicker内部的配置项disabled并没有被更新。原生input设为disabled后理论上无法聚焦，但在某些浏览器和某些框架封装下，焦点仍然可以通过脚本或Tab顺序落到元素上；而readonly属性则完全不阻止聚焦，聚焦后keydown事件照常触发，日历就“活”了过来。
还有一种情况是使用了不规范的禁用方式，比如只加了一个禁用样式类名，或者用了attr("disabled", "disabled")这种老式写法后又被其他代码覆盖。这些做法都没有触及Datepicker的事件处理内核，键盘导航自然畅通无阻。
正确的禁用方式与它的局限
jQuery UI官方推荐的禁用方式是通过实例方法操作：
// 方式一：初始化时配置
$("#dateInput").datepicker({
dateFormat: "yy-mm-dd",
disabled: true
});
// 方式二：初始化后调用方法
$("#dateInput").datepicker("disable");
datepicker("disable")会把日历面板隐藏、给输入框加上禁用样式，同时插件内部会记录禁用状态。在大多数情况下这已经够用，但它有一个已知局限：对readonly输入框的支持不完整。如果你只是设置readonly而期望日历不可用，Datepicker并不把readonly视为禁用，聚焦后按回车仍会写入日期。所以readonly和disabled在Datepicker的世界里是两码事，这一点务必区分清楚。
此外，部分旧版本（1.11.x之前）中，即使调用了disable方法，输入框的keydown监听器依然绑定着，某些边缘场景下（比如日历面板已经打开后才调用disable）键盘仍能操作残留的面面。这就是为什么实际项目中还需要一层兜底防护。
通过拦截键盘事件彻底堵住漏洞
最稳妥的方案是在事件层面做一道防线。思路很简单：在keydown的捕获阶段判断控件是否处于禁用状态，如果是就直接终止事件传播，不让Datepicker的内部处理器收到任何键盘信号。代码如下：
(function($) {
// 在捕获阶段拦截，比插件自身的绑定更早执行
$(document).on("keydown", ".hasDatepicker", function(e) {
var $input = $(this);
var disabled = $input.prop("disabled") ||
$input.attr("readonly") === "readonly" ||
($input.datepicker("option", "disabled") === true);
if (disabled) {
e.stopImmediatePropagation();
e.preventDefault();
return false;
}
}, true); // 注意：jQuery 1.7+ 建议用原生捕获写法
// 原生捕获写法（推荐，兼容性最好）
document.addEventListener("keydown", function(e) {
var target = e.target;
if (target && $(target).hasClass("hasDatepicker")) {
var $input = $(target);
if ($input.prop("disabled") || $input.prop("readonly")) {
e.preventDefault();
e.stopPropagation();
}
}
}, true);
})(jQuery);
关键点有两个。第一是使用捕获阶段（addEventListener的第三个参数传true），因为jQuery的on方法默认在冒泡阶段绑定，而事件捕获先于目标阶段的处理器执行，这样能在Datepicker的_doKeyDown被调用之前就把事件掐断。第二是判断条件同时覆盖了原生disabled、readonly和插件自身的禁用配置，三种状态统一拦截，避免遗漏。
除了键盘拦截，建议再加一层保险：禁用时直接解绑或阻止日历弹出。可以在聚焦事件上做判断：
// 禁用状态下阻止日历面板弹出
$(document).on("focus", ".hasDatepicker", function() {
var $input = $(this);
if ($input.prop("disabled") || $input.prop("readonly")) {
$input.datepicker("hide");
}
});
这两段代码组合起来，即使插件内部状态判断有疏漏，事件层面也守住了底线。
封装成可复用的工具方法与注意事项
实际项目中建议把禁用逻辑封装成统一的方法，避免各处散落不一致的写法：
function setDatepickerState($input, enabled) {
if (!$input.hasClass("hasDatepicker")) {
return; // 未初始化的控件直接跳过
}
if (enabled) {
$input.prop("disabled", false)
.prop("readonly", false)
.datepicker("enable");
} else {
// 先禁用插件，再设置原生属性，最后隐藏面板
$input.datepicker("disable")
.datepicker("hide")
.prop("disabled", true);
}
}
// 使用示例
setDatepickerState($("#startDate"), false);
封装时注意顺序：先调用datepicker("disable")再设置原生属性，并在中间调用hide确保已打开的面板立即消失。如果顺序颠倒，在日历打开的瞬间执行禁用，可能出现面板残留的视觉问题。
还有几个容易踩的坑需要留意。一是动态创建的输入框，拦截器依赖hasDatepicker类名，只要控件初始化过就会带上这个类，所以事件委托方式对后加入的DOM同样生效。二是如果页面上有其他控件也依赖回车键提交表单，拦截逻辑要限定在hasDatepicker类名范围内，不要扩大到整个document的keydown。三是升级jQuery UI版本时建议重新测试，官方在新版本中逐步修复了部分readonly场景的问题，但事件拦截这层防护保留着没有坏处。
最后补充一点测试建议：修复完成后，用Tab键遍历页面所有可聚焦元素，在禁用的日期输入框上依次按上下左右键、回车、PageUp、PageDown，确认输入框值不变且无日历弹出；再验证启用状态下所有操作正常。这样双向验证，才能确保修复没有引入新的问题。
jQuery UI DatepickerjQuery UI日期控件disabled状态键盘导航修改时间：2026-09-15 07:14:31