做后台系统的同学应该都跟“el-date-picker 限制选择范围”打过照面上架时间不能选过去活动报名截止要锁在某几天内订酒店离店日期必须在入住之后。凡是表单里出现 el-date-picker基本都逃不过把某个日期或者一段范围卡死的宿命。很多人第一反应是给 options 加一个 disabledDate 就完事但真正上了生产环境才发现跟着联动、时区、快捷键、面板刷新一起冒出来的问题远比想象中多。这篇想把限制选择范围从 API 用法、坑点到封装思路完整过一遍。Element UI 的老项目和 Element Plus 的新项目都能对照着用。1. 那些必须限制日期选择的业务场景其实都有一个共性1.1 预约与排期把“过去时间”挡在面板之外最典型的一类业务是预约和排期。门店预约、快递取件时间、内容定时发布全都要求用户只能选择当前时刻之后的日期。这种限制在代码上就是一句判断的事但难点往往集中在两个边界问题上今天算不算可选日期以及精确到小时之后要不要也一起卡死。我见过不少项目最开始直接把今天禁掉了理由是“今天的单我们已经排满了”。上线之后产品跑过来说用户不能预约今天预期和实现直接对不上。所以拿到这种需求第一件事不是写代码而是跟产品把边界对齐是 “只能选明天及以后”还是“今天及以后都能选”。这两个结论对应的时间基准相差 24 小时判断条件写反一个符号用户看到的就是完全相反的选择范围。1.2 双端联动入住离店、出差往返这类“A 不能在 B 之后”的需求第二类场景是双端联动。最典型的就是住酒店入住日期和离店日期各一个选择器离店不能早于入住。出差往返、借还时间也都是同一个套路。这已经不是单个日期的限制而是两个日期之间的相对关系约束。开始日期选完之后结束日期的可用范围要立刻收敛反过来结束日期已经定了开始日期也不能再越过它。很多第一版实现写起来很痛快结束日期的 disabledDate 里判断“当前格子是否早于开始日期”就好。但只做这一层清空某一端、或者两个面板同时打开的时候页面就会出现“禁用范围没有即时刷新”的诡异现象。背后的原因我留到第 4 节专门讲这里先不剧透。1.3 窗口限制活动报名和连住折扣这类“只能落在某个区间内”的需求第三类是固定窗口。比如某活动报名只能选开始前 7 天到开始当天又比如连住优惠要求连续入住不超过 7 天。它一方面要求日期落在某个闭区间里另一方面还要求首尾日期之间的距离有上限。窗口类需求和前两类的差别在于判断条件不是单边而是上下界的“与”。早于下界要禁用晚于上界也要禁用中间才能选。多一个比较符号结果就是冰火两重天。而且窗口上界如果依赖另一个日期比如结束日期不能晚于开始日期加 7 天你还得处理跨月、跨年这些日期计算。这类需求看着简单写出来全是边界分支。2. 限制选择范围的底层机制Element UI 与 Element Plus 的 API 差异2.1 disabledDate 的传入参数是什么返回值到底怎么理解Element UI 的限制是通过 picker-options 的 disabledDate 方法实现的data() { return { pickerOptions: { disabledDate(time) { return time.getTime() Date.now() } } } }Element Plus 把 prop 换成了 disabled-date用法类似el-date-picker v-modelvalue typedate :disabled-datedisabledDate /const disabledDate (time: Date) { return time.getTime() Date.now() }两边的 time 参数都是一个 Date 对象代表日期面板里某一个格子的零点时间。返回值 true 表示这一格禁用false 表示可选。这个函数的调用频率比大多数人以为的要高面板每次打开、每次切换月份、每次点击日期都会触发重新评估。daterange 双面板模式下一次要评估几十个格子。所以函数体内部最好不要做高开销操作这个我放到第 5 节再展开。2.2 为什么 Date.now() 会让今天被禁用以及 8.64e7 的由来新手必踩的坑在这里想禁止选择今天之前的日期第一版判断很容易写成time.getTime() Date.now()。但这样写今天往往也选不了。原因在于 time 是当天零点而 Date.now() 是当前时刻。比如现在是下午 15:30今天零点的毫秒时间戳必然小于当前时刻的毫秒时间戳。于是“今天”也会被判成过去日期直接进入禁用名单。正确的做法是给“今天”留出一整天常见写法是把判断基准往前推一天也就是减 86400000 毫秒即 8.64e7const disabledDate (time: Date) { return time.getTime() Date.now() - 8.64e7 }假设现在是 6 月 16 日 15:30Date.now() - 8.64e7等于 6 月 15 日 15:30。6 月 16 日零点大于这个数所以今天可选6 月 15 日零点小于这个数昨天及以前全部禁用边界正好卡在昨天结束的位置。另一种更直观的等价写法是先把“今天零点”算出来再比较const disablePastDate (time: Date) { const today new Date() today.setHours(0, 0, 0, 0) return time.getTime() today.getTime() }可读性更好也基本不受午夜零点毫秒级临界情况影响。如果你敲过DATE_NOW - 8.64e7这种魔法数建议换成 setHours 版本存进公共函数里免得后人看代码一头雾水。2.3 两代组件库的 API 对照对比项Element UIVue 2Element PlusVue 3挂载位置:picker-options{ disabledDate }:disabled-datedisabledDate参数类型Date 对象格子零点Date 对象格子零点返回 true禁用该格禁用该格常见响应式写法data computed 返回对象setup 返回函数或 computed 返回函数daterange 支持通过 picker-options.disabledDate通过 disabled-date绑定值默认格式Date 对象可配 value-formatDayjs 对象可配 value-formatElement UI 必须把 picker-options 放在 data 里或者 computed 里返回Element Plus 则直接在模板上绑定函数。两边最大的差异不在 API 名字而在响应式处理方式。Element UI 的常见坑是直接给 data 里的 pickerOptions 塞对象联动时值不变Element Plus 的常见坑是 setup 里定义具名函数函数引用不变导致子组件不刷新。这两个坑本质上是一回事我下面专门说。2.4 不同面板类型下 time 参数的含义time 参数在不同 type 下的含义要特别注意否则限制会失效或者错位。typedate每个日期格子的零点typedaterange左右两个面板里每个日期格子的零点同一个 disabledDate 同时作用于两个面板typedatetimetime 参数仍然按日期格子的零点给不会精确到小时typemonthtime 是每个月 1 号的零点判断时需要操作月份字段typeyeartime 是每年 1 月 1 号的零点这里最容易被误解的是 datetime。很多人以为 datetime 模式下 disabledDate 能精确控制到某个小时实际上它只管日期层。想要实现“必须比当前时间晚 2 小时”disabledDate 根本不够我第 5 节会讲怎么补救。3. 五种高频限制场景可以直接抄的写法与参数说明3.1 禁选今天之前的日期date 和 datetime 两种Element Plus 写法el-date-picker v-modelpublishTime typedate value-formatYYYY-MM-DD :disabled-datedisablePastDate /const disablePastDate (time: Date) { const today new Date() today.setHours(0, 0, 0, 0) return time.getTime() today.getTime() }如果类型换成 datetimetime 参数仍然是日期格子的零点不会把小时也一并禁掉。如果业务要求“只能选当前时刻之后”比如定时发布要求发布时间必须晚于现在那还要在 change 回调里做一次二次校验发现值非法就清空。否则用户选了一个今天但早于当前时刻的时间表单也会通过。3.2 固定窗口只能选未来 3 天到未来 30 天之间的日期这种需求常见于预约周期或活动预热给一个最小提前量和最大提前量const disableWindowDate (time: Date) { const now Date.now() const minTime now 3 * 24 * 3600 * 1000 const maxTime now 30 * 24 * 3600 * 1000 return time.getTime() minTime || time.getTime() maxTime }注意这里 minTime 和 maxTime 是在函数内实时算的。如果业务参数来自某个响应式变量比如后台配置了“提前 N 天开放预约”那最好把边界放到 computed 里依赖变化时重新生成一次。不要把这个计算放到模块顶层一劳永逸用户开页面很久之后再来选边界早就过期了。3.3 开始与结束日期互斥computed 包裹函数才保险先看最常见的简单版const startDate ref() const endDate ref() const disableStartDate (time: Date) { if (!endDate.value) return false return time.getTime() new Date(endDate.value.replace(/-/g, /)).getTime() } const disableEndDate (time: Date) { if (!startDate.value) return false return time.getTime() new Date(startDate.value.replace(/-/g, /)).getTime() }这个版本在多数场景下能跑但存在一个隐蔽的刷新问题。当 endDate 改变时disableStartDate 的函数引用没有变化日期面板不会主动重新渲染已经打开的面板里禁用状态可能不更新。稳妥的做法是用 computed 包一层让每次依赖变化都返回一个新函数const startDate ref() const endDate ref() const disableStartDate computed(() { return (time: Date) { if (!endDate.value) return false return time.getTime() new Date(endDate.value.replace(/-/g, /)).getTime() } }) const disableEndDate computed(() { return (time: Date) { if (!startDate.value) return false return time.getTime() new Date(startDate.value.replace(/-/g, /)).getTime() } })Vue 2 的 Element UI 项目对应写法是 computed 返回整个 pickerOptionscomputed: { pickerOptions() { return { disabledDate: (time) { if (this.endDate) { return time.getTime() new Date(this.endDate.replace(/-/g, /)).getTime() } return false } } } }这里replace(/-/g, /)是为了绕开原生 Date 对YYYY-MM-DD的 UTC 解析问题。东八区下new Date(2024-06-15)会被解析成 15 号上午 8 点拿去和零点时间戳比较会差 8 个小时边界就歪了。用2024/06/15这种格式构造的 Date 才会按本地时区零点生成这是不少线上 bug 的根源。3.4 禁用指定日期列表节假日、已约满日期预约类系统经常要把某些日期从面板里直接剔除。与其每次在 disabledDate 里遍历数组不如预先把禁用日期转成时间戳 Set查找复杂度是 O(1)const closedList [2024-06-01, 2024-06-02] const closeTimeSet new Set( closedList.map((d) new Date(d.replace(/-/g, /)).getTime()) ) const disableClosedDate (time: Date) { return closeTimeSet.has(time.getTime()) }注意 closeTimeSet 应该在组件外或 setup 中构建一次不要放进 disabledDate 函数内部每次 new Set。否则面板切一次月就重建一遍集合纯属浪费。如果禁用列表来自接口入住日期等数据是动态的那就用 computed 在列表变化时重新生成 Set让禁用函数依赖新集合。3.5 按星期几禁用周末不可选想把周末全部禁掉判断 getDay 就行const disableWeekend (time: Date) { const day time.getDay() return day 0 || day 6 }这里周日是 0周六是 6。中国特有的“调休”比较麻烦周末可能上班工作日也可能放假。如果要把法定节假日和调休一起算进去就得引入一份节假日数据表判断逻辑从“周末”扩展成“节假日”或“周末但不调休”。这时候第 3.4 节的 Set 方案就又派上用场了周末里属于调休工作日的日期要从禁用集合中剔除。4. 联动与边界条件两个日期选择器互相约束时真正容易翻车的是这些4.1 函数依赖的响应式陷阱结束日期变了开始日期的禁用范围却没刷新我在开发里看到最多的问题就是这个。很多人把联动函数直接写成 setup 里的具名函数绑到模板上然后发现另一端日期变了当前面板的禁用状态纹丝不动。原因在于传给子组件的函数引用没有变化Vue 就不会认为这个 prop 变了子组件不会重新渲染已经打开的面板自然停留在旧状态。函数内部虽然能读取到最新的响应式值但组件没有理由主动去调用它。打个比方你把一扇门的钥匙给了保安这扇门的状态依赖天气但保安手里拿的还是同一把钥匙天气变了保安不会主动去开门看一眼。用 computed 每次生成一个新函数引用就等于给保安换了一把新钥匙他才会重新对比一次。所以第 3.3 节才建议用 computed 或模板内联箭头函数。只要保证每次依赖变化时 disabled-date 接收的是不同函数引用子组件就会强制刷新禁用判断。这个点值得写在代码注释里不然过一个月连你自己都忘了当初为什么这么写。4.2 清空一端另一端的禁用状态没恢复正常联动还有一个衍生问题开始日期被清空后结束日期的禁用范围按理应该恢复成全部可选。但同样因为函数引用不变旧日期范围可能还残留在已打开的结束日期面板里。解决思路和 4.1 一样依赖 computed 重新生成函数。同时建议在 watch 里做一层兜底当开始日期为空时把结束日期也一起清空。因为用户都清掉开始日期了留着一个被旧开始日期约束过的结束日期语义上已经没有意义而且会给后面的表单校验埋雷。4.3 已经落定的结束日期要不要在开始日期变化时自动重置还有一种需求更隐蔽用户先选了结束日期再回头把开始日期改到结束日期之后。disabledDate 只能阻止“未来点击”的日期抹不掉“之前已经选择”的值。如果两个日期的语义是“开始必须在结束之前”那这组数据就已经非法了。联动场景一定要手动清理watch(startDate, (val) { if (val endDate.value isBefore(endDate.value, val)) { endDate.value } })具体比较函数可以用 dayjsElement Plus 项目里 node_modules 本来就带着 dayjs直接引入使用就行不必额外引入 moment 这种更重的库。4.4 daterange 面板的联动与手动模式如果用的是 typedaterange 而不是两个独立选择器联动逻辑要从“两个框互相约束”变成“一个框内部两个端点互相约束”。daterange 内部面板只会判断当前格子的可用性不会替你维护“开始不能晚于结束”。你仍然要在 disabledDate 里根据当前选中的端点来判断或者更彻底一点直接监听 change 校验。更复杂的场景比如“开始日期只能选周一结束日期只能选周日”建议干脆把 daterange 拆成两个独立的 date-picker 并排分别配置自己的 disabledDate逻辑会清晰得多。真要用一个 daterange 去实现这种非对称规则disabledDate 需要感知当前是选左端点还是右端点复杂度高还容易出边界 bug。5. 性能、时区与快捷键限制日期范围还有这些隐性雷区5.1 disabledDate 的性能红线别在函数里做格式化和大循环时间面板动辄渲染几十个格子切换月份、点击日期都会重新调用 disabledDate。如果在函数里做 dayjs().format()或者遍历一个上百条的数组轻则掉帧重则点击卡顿。更稳的做法是把边界时间戳预先算好把禁用日期转成 Set 存起来让 disabledDate 函数体只做 O(1) 的比较。比如结束日期的禁用判断const minTime computed(() startDate.value ? new Date(startDate.value.replace(/-/g, /)).getTime() : -Infinity ) const disableEndDate (time: Date) { return time.getTime() minTime.value }dependent 关系用 computed 维护函数体只做一次比较性能和正确性两头都占了。这是我在多个项目里验证过比较舒服的写法。5.2 字符串日期与 UTC 解析差 8 小时的边界错位这应该是日期限制类 bug 里出现频率最高的一个。Element Plus 的 date-picker 默认 value-format 是 timestampDayjs 对象很多项目会设置成YYYY-MM-DD于是 v-model 拿到的是纯字符串。把2024-06-15直接塞给原生new Date()会被当成 UTC 时间解析。在东八区这个值会变成 15 号早上 8 点。当你拿它和面板格子的零点时间戳比较15 号当天就会被误禁或者误放。我之前排查过一个“为什么今天明明可选却被禁掉”的线上问题最后就是这种 8 小时偏移导致的。规避方式有三种使用new Date(2024/06/15)斜杠格式按本地时区解析使用new Date(2024, 5, 15)数字构造更可靠直接用 dayjsdayjs(2024-06-15)解析的是本地时区零点没有这个问题我建议项目里统一封装一个 toDate 工具函数内部做字符串规范化避免每个页面各写各的。5.3 shortcut 快捷键会绕过 disabledDate快捷选项是日期组件里最容易让人忽视的一道后门。Element UI 和 Element Plus 都支持 shortcuts“最近一周”“本月”这类快捷键直接给组件赋值不会先走 disabledDate 判断。一旦快捷项计算出来的日期落在禁用区间内用户点一下v-model 照样被塞进非法值。处理方式有两种要么让快捷项生成的目标值始终满足业务约束比如“最近一周”改成“从今天起的一周”要么在 change 回调里统一校验发现非法值就清空并提示。我倾向于后者。因为快捷项在需求变更时经常改守住 change 这道防线比每次改快捷项时记得同步约束条件要省心得多。5.4 天数和小时粒度的校验不能只靠 disabledDate前面提过 datetime 类型下 disabledDate 只能管到日期层。如果你的业务要求“必须比当前时间晚 2 小时”光靠禁用日期是不完整的。严格的做法是配合日期选择器内嵌的时间选择部分做限制Element Plus 的 datetime 面板支持对时分进行禁用。实在不行提交时再做兜底校验。不要试图让 disabledDate 承担所有事它只是第一道闸门。6. 工程化收尾把限制逻辑封装成可复用的限制器6.1 用组合式函数封装联动限制Vue 3 示例项目里往往不只有一个页面要做“禁过去日期”“起止联动”这些限制。我习惯把逻辑抽成一个组合式函数避免每个页面重复写 computed 和 watch// useDateRangeLimit.ts import { computed, ref, watch } from vue import dayjs from dayjs export function useDateRangeLimit() { const startDate ref() const endDate ref() const startTime computed(() startDate.value ? dayjs(startDate.value).startOf(day) : null ) const endTime computed(() endDate.value ? dayjs(endDate.value).startOf(day) : null ) const disableStartDate computed(() { return (time: Date) { if (!endTime.value) return false return dayjs(time).isAfter(endTime.value, day) } }) const disableEndDate computed(() { return (time: Date) { if (!startTime.value) return false return dayjs(time).isBefore(startTime.value, day) } }) watch(startDate, (val) { if (val endTime.value endTime.value.isBefore(dayjs(val), day)) { endDate.value } }) watch(endDate, (val) { if (val startTime.value startTime.value.isAfter(dayjs(val), day)) { startDate.value } }) return { startDate, endDate, disableStartDate, disableEndDate } }页面里用起来很干净script setup import { useDateRangeLimit } from ./useDateRangeLimit const { startDate, endDate, disableStartDate, disableEndDate } useDateRangeLimit() /script template el-date-picker v-modelstartDate typedate :disabled-datedisableStartDate / el-date-picker v-modelendDate typedate :disabled-datedisableEndDate / /template如果还有更复杂的组合规则可以先把各种限制条件写成 validator 数组再用一个包装函数合并const composedDisabledDate (validators: Array(time: Date) boolean) { return (time: Date) validators.some((fn) fn(time)) }每个 validator 返回 true 表示“这个格子应该被禁用”存在任意一个 validator 返回 true最终结果就是禁用。如果你的业务要求所有条件同时成立才禁用把 some 换成 every 就行。6.2 边界测试至少覆盖哪些日期封装完不是结束要测。日期限制的 bug 大多出在边界上建议至少覆盖下表这些用例边界日期期望行为今天按规则应可选或禁用昨天禁过去时应禁用明天禁未来时应禁用窗口下界第 3 天恰好为下界应可选窗口上界外 1 天超出上界应禁用跨月的第 1 天正确落入判断区间跨年的第 1 天正确落入判断区间闰年 2 月 29 日闰年可正常识别清空值后再次打开禁用规则恢复默认实测中跨月和跨年最容易翻车因为很多人在判断窗口时顺手写了固定天数比如 30 天没有考虑 7 月这种 31 天的月份会把窗口悄悄多推一天。6.3 表单校验与交互限制要双保险最后提醒一点disabledDate 只是交互层的“软限制”不代表 v-model 里永远不会有非法值。用户快速操作、代码直接赋值、或者快捷项绕过都可能导致表单携带越界日期。所以在表单校验器里也要实现同一套约束双保险。最好的做法是让交互层和校验层共用同一个限制函数不要交互层写一套、validator 里又复制粘贴另一套。两边规则不一致比两边都缺失更危险因为你会以为已经拦住实际上还有一道口子。写到这里我其实最想强调的还是那句限制逻辑本身不难难的是把边界条件当成一等公民对待。我每次改完日期限制都会像强迫症一样把昨天、今天、明天、跨月第一天、跨年除夕都点一遍再清空一次重选确认面板没有残留的禁用状态。这套动作虽然机械但确实帮我抓出过不少差 8 小时的时区 bug。如果你能在自己的项目里把限制函数从页面里抽出来再配上一份边界测试清单后面再改需求心里就有底了。
帮你读懂)
