企业官网建设流程全解析

上个星期产品扔给我一句话：“后台那个预约筛选框，日期时间选择器不要显示分和秒。”我第一反应是这还不简单，改个 type 属性的事。结果真正动手才发现，element-plus 的日期时间选择器在这类需求上远比想象中“有个性”：有的版本是输入框里不带秒了，弹层照样给你列着时、分、秒三列；有的版本是界面全部干净了，一提交，绑定的值又变成"2024-06-01 12:30:00"，后端接口直接给打回来。

今天就把这个需求彻底拆开讲清楚：什么时候只要日期、什么时候要保留小时、什么时候只是改显示格式，每种情况对应什么解法，以及我在实际项目里踩过的坑。这套内容适合 Vue3 + element-plus 的项目同学，尤其是后台管理、数据报表、预约排班这类经常和时间粒度打交道的场景。

先说一个容易混淆的点：这个需求其实是两个层次的问题，一个是怎么让界面不出现“分 / 分秒”，另一个是怎么让提交给后端的数据也不带多余时间。只解决其中一个，联调的时候迟早要炸一次。所以下面我按需求粒度分成几种情况来写，每种都给可以直接抄的代码。

1. 先分清需求：你要去掉的是“界面上的分秒”还是“提交值的分秒”

1.1 三种高频诉求别搞混

我见过很多把需求理解错的案例。产品说“日期时间选择器不要分秒”，实际到他脑子里可能是三种完全不同的事：

这三种处理方式差很远。第一种把type换成date就完事；第二种要动 datetime 面板里的时间列，或者改用组合控件；第三种纯粹是显示模板问题，跟分秒没有本质关系。如果不先跟产品确认是哪一种，就会出现我之前的状况——辛辛苦苦把面板改完，产品来一句“其实我只要日期”。

1.2 先搞懂 format 和 value-format 的分工

很多人在这个需求上翻车，是因为没分清el-date-picker的两个属性：

• format：控制输入框里显示成什么样，也会影响日期面板上出现哪些时间列。
• value-format：控制 v-model 拿到的是什么格式的字符串。如果不写，v-model 拿到的是 Date 对象。

这两个属性是解耦的。显示可以不带秒，但值未必不带。我在项目里见过太多只配了format没配value-format的代码，输入框看着是“2024-06-01”，console.log 打出来却不是字符串，后端 JSON 序列化后变成2024-06-01T00:00:00.000Z，查了半天才发现问题。

所以在后面每个方案里，我都会把这两个属性一起写全，避免“界面对了、数据错了”的情况。

2. 只要日期不选时间：type 换成 date，问题当场消失

2.1 为什么 type="datetime" 会多出 00:00:00

如果你现在的代码用的是type="datetime"，那组件在提交时一定会带上时分秒，哪怕用户只选择了日期。因为 datetime 这个类型的默认值就是把当天零点作为时间部分，element-plus 内部解析的时候也会按HH:mm:ss去取值。

更麻烦的是，很多后台模板项目（比如若依、vue-element-admin 衍生项目）表单里一开始写的就是type="datetime"，后面产品补了一句“不要时间”，开发顺手改成type="date"，但发现绑定的值在接口返回时还是带00:00:00。原因就是后端存储字段、接口入参格式当初都是按 datetime 设计的，前端改完 type，后端还在按老格式解析。

2.2 date 类型的最小写法

如果你的需求就是“只要日期”，直接写：

<el-date-picker v-model="form.date" type="date" placeholder="请选择日期" format="YYYY-MM-DD" value-format="YYYY-MM-DD" />

这里有两个关键点。第一，type="date"之后，组件面板上只渲染日期网格，内部根本不处理时分秒；第二，value-format="YYYY-MM-DD"保证 v-model 拿到的是纯日期字符串，不是 Date 对象，也不是带秒的字符串。

我自己会额外在提交前加一道保险，防止有人从别的地方传了时间进来：

if (!/^\d{4}-\d{2}-\d{2}$/.test(form.date)) { ElMessage.warning('日期格式不正确') return }

2.3 快捷选项和中文显示也别漏

只选日期时，运营同学往往希望有“今天”“昨天”“最近 7 天”这类快捷选项。给el-date-picker加shortcuts即可：

<el-date-picker v-model="form.date" type="date" format="YYYY-MM-DD" value-format="YYYY-MM-DD" :shortcuts="dateShortcuts" />

const dateShortcuts = [ { text: '今天', value: () => new Date() }, { text: '昨天', value: () => { const date = new Date() date.setTime(date.getTime() - 3600 * 1000 * 24) return date } }, { text: '最近 7 天', value: () => { const date = new Date() date.setTime(date.getTime() - 3600 * 1000 * 24 * 7) return date } } ]

注意快捷项的 value 返回 Date 对象即可，组件会自动按value-format转成字符串。如果你还希望输入框显示成中文日期，比如“2024年06月01日”，那就把format改成：

format="YYYY年MM月DD日" value-format="YYYY-MM-DD"

显示和存储分开处理，这是最优雅的玩法。前端只管给人看，后端要什么格式就给什么格式。

2.4 如果是要“起止日期范围”

很多筛选场景其实是“从一个日期到另一个日期”，此时直接用type="daterange"同样可以绕开分秒问题：

<el-date-picker v-model="form.range" type="daterange" range-separator="至" start-placeholder="开始日期" end-placeholder="结束日期" value-format="YYYY-MM-DD" />

绑定值会是一个["2024-06-01", "2024-06-30"]这样的数组，前后端都清爽。这个方案在后台查询条件里非常常用，等于从根本上避开了“时间粒度”这个话题。

3. 要保留“小时”再砍分秒：用 format 控制 datetime 面板的时间列

3.1 format 不只影响显示，还影响面板上的时间列

如果产品说“我要精确到小时”，那type="date"就不够用了，必须用 datetime，但默认的面板会同时给出时、分、秒三列，用户很容易误选一个带分钟的时间，比如“14:35”，然后你又要加一堆校验去拦。

这里有个很多资料不会明说的行为：element-plus 的 datetime 面板会解析format里出现的时间 token，来决定时间选择区渲染哪几列。format里没有mm，分钟列就不渲染；没有ss，秒列就不渲染。

也就是说，你完全可以让面板只保留一列“时”，从根源上让用户选不出分钟。

3.2 只保留小时的写法

完整代码如下：

<el-date-picker v-model="form.startTime" type="datetime" format="YYYY-MM-DD HH" value-format="YYYY-MM-DD HH" placeholder="请选择日期（精确到小时）" :editable="false" />

format="YYYY-MM-DD HH"是关键：输入框显示成“2024-06-01 14”，日期面板下面的时间列也只有小时。value-format="YYYY-MM-DD HH"保证提交给后端的值也是“2024-06-01 14”这种带小时但不带分秒的字符串。

我这边在 element-plus 2.3.x 上实测没问题，但这属于组件内部解析行为，不同小版本可能有差异。你升级依赖之后，最好用最小 demo 跑一遍，确认面板确实只剩小时列。

3.3 手动输入的漏洞：editable 和提交校验

单纯靠format还有一个漏洞：组件默认允许用户在输入框里手动输入内容。就算面板只有小时列，用户还是可以手打一个2024-06-01 08:30回车，绕过你的限制。

所以只保留小时时，我强烈建议加:editable="false"，让输入框变成只读，用户只能通过面板选择。

如果因为交互原因必须允许手动输入，那就在提交前加正则校验：

const hourOnlyPattern = /^\d{4}-\d{2}-\d{2} \d{2}$/ if (!hourOnlyPattern.test(form.startTime)) { ElMessage.warning('时间只需精确到小时，不需要分钟') return }

这套组合拳打下来，分秒基本没有漏网的可能。

3.4 版本行为不一致时的兜底思路

如果你的 element-plus 版本确实不支持通过format收敛时间列，面板还是顽固地显示分秒，你可以写个最小验证页快速确认：

<template> <div> <el-date-picker v-model="v" type="datetime" format="YYYY-MM-DD HH" value-format="YYYY-MM-DD HH" /> <p>{{ v }}</p> </div> </template>

打开页面点开面板看时间列的数量。如果还有分钟列，就别在这个方案上硬刚，毕竟组件内部逻辑不是我们能控制的。直接切到下一节的组合方案，用两个控件拼，任何版本都稳定。

4. 想绝对可控：日期选择器 + 整点时间下拉的组合方案

4.1 为什么不赌组件内部行为

上一节的format方案虽然代码少，但它依赖 element-plus 的面板解析逻辑。我见过不止一个项目因为 element-plus 升级，原本隐藏掉的分钟列突然又出现，测试才发现一堆脏数据。如果你对 UI 稳定性要求高，或者要兼容多个版本，组合方案是最稳的：日期和时间分开选，数据自己拼。

组合方案的另一个好处是交互清晰。日期用日期选择器，时间用一个只包含整点选项的下拉，用户看到的就是“日期 + 整点小时”，不可能选错。

4.2 el-time-select 的整点配置

el-time-select是做这个场景最合适的控件，它生成的是从start到end每隔step的选项列表。让选项只有整点，配置如下：

<el-date-picker v-model="date" type="date" format="YYYY-MM-DD" value-format="YYYY-MM-DD" placeholder="选择日期" /> <el-time-select v-model="time" start="00:00" end="23:00" step="01:00" format="HH:mm" placeholder="选择整点小时" />

step="01:00"表示每 60 分钟一个选项，用户只能选到00:00、01:00、02:00……一直到23:00，分钟永远是00。绑定值time是"HH:mm"这种格式的字符串，比如"14:00"。

这样用户在交互层面就完全接触不到分钟，更别说秒了。

4.3 封装成“日期加小时”组件的思路

两个控件拆开用有点啰嗦，而且 v-model 要维护两个变量。更合理的做法是封装成一个组件，对外只暴露一个值。下面是核心思路。

模板部分：

<template> <div class="date-hour-picker"> <el-date-picker v-model="date" type="date" format="YYYY-MM-DD" value-format="YYYY-MM-DD" placeholder="选择日期" /> <el-time-select v-model="time" start="00:00" end="23:00" step="01:00" format="HH:mm" placeholder="时" /> </div> </template>

脚本部分，把外部modelValue拆成date和time，再把内部选择合成一个"YYYY-MM-DD HH:mm"字符串抛出去：

const props = defineProps({ modelValue: { type: String, default: '' } }) const emit = defineEmits(['update:modelValue']) const date = ref('') const time = ref('') watch( () => props.modelValue, (val) => { if (!val) { date.value = '' time.value = '' return } const parts = val.split(' ') date.value = parts[0] || '' time.value = parts[1] || '' }, { immediate: true } ) watch([date, time], ([newDate, newTime]) => { if (newDate && newTime) { emit('update:modelValue', `${newDate} ${newTime}`) } else { emit('update:modelValue', '') } })

父组件使用：

<date-hour-picker v-model="form.startTime" />

外部拿到的值就是"2024-06-01 14:00"，分钟固定为00，即使后端拿到也不会出现时间精度问题。

4.4 组合方案同样适用于范围选择

范围选择也可以照搬这个思路。日期部分用daterange，时间部分用两个el-time-select，分别对应开始和结束：

<el-date-picker v-model="dateRange" type="daterange" value-format="YYYY-MM-DD" start-placeholder="开始日期" end-placeholder="结束日期" /> <el-time-select v-model="startHour" start="00:00" end="23:00" step="01:00" format="HH:mm" /> <el-time-select v-model="endHour" start="00:00" end="23:00" step="01:00" format="HH:mm" />

然后自己拼装提交。组合方案的代码量确实比单个组件多，但胜在行为完全可控，不受 element-plus 版本影响。这个“可控性”在团队协作项目里是很重要的，毕竟你没法保证别人升级依赖之前会想到去回归测试时间列。

5. 去掉分秒之后容易爆的隐性坑：默认值、范围联动与数据序列化

5.1 绑定值格式不一致导致回显空白

这是最常见的坑。接口返回给前端的日期是"2024-06-01 14:00:00"，但你的value-format="YYYY-MM-DD HH"，组件一解析发现格式对不上，输入框会直接空白，用户以为自己没保存成功，反复提交，最后生成一堆重复数据。

解决思路有两种。一种是在回显前做一次转换：

const raw = '2024-06-01 14:00:00' form.startTime = raw.slice(0, 13)

另一种是统一后端接口格式。我更推荐后者，因为逻辑更健壮。前端value-format定义什么，后端就尽量按什么存，日期时间这类字段也建议用字符串而不是 Date 对象，避免时区序列化问题。

5.2 datetimerange 范围选择的格式一致性

如果你用的是type="datetimerange"又想隐藏秒，需要特别注意format和value-format要同时配置：

<el-date-picker v-model="form.range" type="datetimerange" range-separator="至" start-placeholder="开始时间" end-placeholder="结束时间" format="YYYY-MM-DD HH:mm" value-format="YYYY-MM-DD HH:mm" />

这里HH:mm会隐藏秒列，但保留了分钟。如果你真的要精确到小时，那format就要写成YYYY-MM-DD HH，并同样配合editable={false}使用。

另外，范围选择时“开始时间”和“结束时间”的格式一定要保持一致。我曾经遇到一个项目，开始时间用了YYYY-MM-DD HH:mm，结束时间因为另一个同事手滑多写了一个:ss，结果后端的区间查询直接查出跨度为 0 的数据，排查了很久才发现是格式不统一。

5.3 Date 对象被序列化成带 T 的字符串

如果组件没有配置value-format，v-model 拿到的是 Date 对象，提交给后端时如果直接JSON.stringify，会变成"2024-06-01T14:00:00.000Z"。这种格式后端很多语言解析起来很麻烦，而且带时区偏移，用户选的“14:00”经过序列化后可能变成别的数字。

我的建议是：所有时间字段在表单层就统一转成不带时区的字符串，比如YYYY-MM-DD HH或YYYY-MM-DD HH:mm:ss。转换工具直接用 dayjs 即可：

import dayjs from 'dayjs' const submitData = { ...form, startTime: dayjs(form.startTime).format('YYYY-MM-DD HH') }

前端转一次，后端就不用做各种兼容补丁了。

5.4 业务上“秒被吃掉”是否安全：先确认需求边界

最后提一个需求层面的问题。隐藏分秒看似简单，但某些业务场景里秒是有意义的，比如排班系统、日志查询、活动秒杀。用户选择日期时间时如果只能精确到小时，后端可能同一秒内产生多条记录，后续追责或统计就会出现歧义。

所以我在处理这类需求时，会多做一步：跟产品确认“保留到小时”是否真的满足业务要求，而不是单纯按字面意思把分秒藏掉。曾经有个停车场预约系统，因为前端去掉了分钟，用户选的入场时间全都变成整点，导致预约高峰集中在每个整点，系统负载全卡在那一分钟内。后来加上分钟粒度，流量才平缓下来。

这类问题不是 element-plus 组件的 bug，而是需求裁剪带来的业务副作用。动手改代码之前，先把这个边界问清楚，能省掉后面很多返工。

最后再分享一个小技巧：如果你不确定产品到底要哪种时间粒度，最快的方式是写一个演示页，把“纯日期”“日期加小时”“日期加小时分钟”三种方案放在同一个页面里，让产品自己点一遍。UI 上的东西，看实物远比看文字描述高效。我当时就是把三种方案摆在一起，产品看完直接说“要第二种”，后面再没提过改需求。