基于Vue 3的会议室预定系统源码：从冲突检测到部署实践

简介：一套基于Vue框架开发的会议室预定系统设计源码，面向需要快速搭建或学习企业级会议室管理场景的前端开发者，也可作为毕业设计或课程项目参考，帮助解决会议资源冲突、预定流程繁琐等常见问题。源码包共33个文件，约871KB，包含17个JavaScript逻辑文件与6个Vue组件文件，分别承担认证、预定逻辑和列表、表单等视图模块；另有PNG图片、JSON配置、HTML骨架及Babel、EditorConfig等工程化配置，覆盖前端界面到构建部署的完整链路。目前已有124人学习下载，整体目录结构清晰，适合初中级开发者按模块拆解学习。通过阅读源码，可以掌握Vue组件化开发思路、前后端分离交互方式及项目工程化配置方法；readme中附有安装运行说明，便于快速启动和二次开发，是理解实际业务系统落地的良好范例。

1. 会议室预定系统源码：从 Vue 框架到可交付的预定流程

会议室预定系统看起来简单，核心难题却集中在两个地方：时间段冲突的判定，以及多人同时操作时的状态一致性。标题里“基于Vue框架”限定了前端技术栈，“设计源码”则意味着这套系统需要有完整的工程结构、接口约定和可跑的代码，不是demo级别的静态页面。围绕这个标题展开的完整方案，包括从技术选型到组件拆分、从冲突检测算法到路由守卫、再到打包部署的细节。适合正在学习Vue项目组织方式的开发者，也适合需要快速搭建内部预定工具的团队参考。Vue框架在这个场景里的真正价值，在于响应式状态管理和组件复用让“某个时段被占”这类状态能在多个页面上保持同步。本文全部代码基于Vue 3组合式API，命令和依赖在主流Node环境下可直接执行。

2. 会议室预定系统技术选型：Vue 3、Pinia 与工程目录设计

会议室预定系统在前端领域属于典型的中后台业务，页面数量不多但状态逻辑密集。技术选型直接影响后续开发和维护成本，这一部分从框架版本、状态管理、依赖安装和目录结构四个层面建立起一套可复现的工程基础。

2.1 为什么选 Vue 3 组合式 API 而不是 Vue 2 选项式

先说明一个常见分歧：很多基于Vue框架的会议室预定系统源码仍是Vue 2 + Element UI + Vuex的组合，参考价值有，但新项目不建议照搬。Vue 2 已停止维护，且选项式API在预定这种“多个业务逻辑互相穿插”的场景里维护成本高。以预定表单为例，会议室选择、时间段选择、冲突提示三块逻辑在选项式里会分散在data、methods、watch三个区块中，而组合式API可以用useBookingForm这类组合式函数把逻辑聚合在一起。

另一个选型理由是生态匹配。Vue 3搭配Vite后开发环境启动速度快，Element Plus全面支持TypeScript，预定系统里“预定记录”这类数据模型用类型约束后，字段拼写错误在编译期就能暴露。团队如果已经熟悉若依这类基于Vue的管理模板，也能发现新版本的若依框架已经提供Vue 3分支，但直接从脚手架搭建会议室预定系统会更轻量，结构也更清晰。

2.2 用 create-vite 初始化项目并安装 Vue 依赖清单

初始化会议室预定系统项目，常见做法是用Vite官方脚手架。以下命令在同一目录下执行，Node版本建议保持在18及以上：

npm create vite@latest meeting-room -- --template vue cd meeting-room npm install npm install vue-router@4 pinia element-plus @element-plus/icons-vue axios dayjs

这里逐项说明安装的依赖。vue-router@4是Vue 3对应的路由版本，预定列表、预定详情、预定创建三个页面之间的跳转依赖它；pinia是Vue 3官方推荐的状态管理库，用于维护“当前用户”“预定记录”这类跨页面状态；element-plus提供表格、日期选择器、表单组件；图标包配套使用；axios负责请求后端接口；dayjs因为会议室预定涉及大量日期边界计算，比原生Date对象更安全。

安装完成后在main.js中完成基础注册：

import { createApp } from 'vue' import { createPinia } from 'pinia' import ElementPlus from 'element-plus' import 'element-plus/dist/index.css' import App from './App.vue' import router from './router' const app = createApp(App) app.use(createPinia()) app.use(router) app.use(ElementPlus) app.mount('#app')

注册顺序有讲究。pinia必须先于router注册，因为路由守卫里会读取用户状态；ElementPlus全量引入适合内部系统，不必为加载体积做按需引入优化，这部分代码直接决定后续组件里是否能直接使用el-form、el-date-picker等标签。

2.3 按业务域划分的源码目录结构与数据流方向

会议室预定系统的源码目录不能照搬Vue官方脚手架的默认结构，默认结构下所有页面堆在views里，组件堆在components里，当预定相关的组件超过十个时维护变得困难。我建议按业务域组织：

src/ api/ # 与后端约定的接口请求层 components/ # 通用组件，如空状态、分页 core/ # 预定领域核心代码，冲突检测算法 layouts/ # 后台布局，侧边栏+顶栏 router/ # 路由表与路由守卫 stores/ # Pinia 状态模块 utils/ # 日期格式化、类型判断 views/ # 页面级组件 booking/ # 预定创建、预定列表、预定详情 room/ # 会议室管理 user/ # 登录、个人中心

目录职责对应关系如下表：

目录结构直接决定了“设计源码”这四个字的含金量。核心判断逻辑抽到core目录后不依赖Vue实例，可以单独写单元测试；接口层只负责请求和响应格式化，页面里不直接出现axios。数据流动方向固定为：页面组件调用stores里的action，action调用api层，api层返回数据后写入state，再通过响应式机制驱动页面更新。预定提交时页面不直接修改预定列表数组，而是经过store里的createBooking动作，这样冲突检测才有统一入口。

3. 预定页核心组件拆分与 vue 路由参数联动

会议室预定页面是系统中交互最密集的地方，一个页面里同时存在会议室选择、日期选择、时间段选择、参与人输入四类操作。全部写在一个.vue文件里会让单文件超过600行，所以组件拆分是源码设计的关键一步。

3.1 预定表单的四个子组件及它们的职责边界

预定页可以拆成RoomSelect、DateRangePicker、TimeSlotPicker、AttendeeInput四个子组件。拆分的边界规则很简单：子组件只负责“展示和收集某一块数据”，不负责提交逻辑。以TimeSlotPicker为例，它接收一个disabledSlots数组作为prop，内部渲染时间段按钮，选中的值通过emits抛给父组件。

<!-- TimeSlotPicker.vue --> <template> <div class="time-slot-picker"> <button v-for="slot in slots" :key="slot.value" type="button" class="slot-btn" :class="[selected === slot.value ? 'is-active' : '', slot.disabled ? 'is-disabled' : '']" :disabled="slot.disabled" @click="handleSelect(slot)" > {{ slot.label }} </button> </div> </template> <script setup> import { computed } from 'vue' const props = defineProps({ slots: { type: Array, required: true }, disabledSlots: { type: Array, default: () => [] }, modelValue: { type: String, default: '' } }) const emit = defineEmits(['update:modelValue']) const slots = computed(() => { return props.slots.map(slot => ({ ...slot, disabled: props.disabledSlots.includes(slot.value) })) }) function handleSelect(slot) { if (slot.disabled) return emit('update:modelValue', slot.value) } </script>

v-model在这里通过modelValue和update:modelValue实现，这是Vue 3组件的标准双向绑定写法。disabledSlots由父组件根据已有预定记录计算后传入，子组件内部不感知冲突检测逻辑，只做按钮的禁用渲染。这样设计后，如果后续要切换成时间线形式的选择控件，只需要替换这一个组件。

3.2 从会议室列表跳转到预定页的 vue 路由参数传递

一个常见的会议预定操作路径是：用户在会议室列表页看到某个空闲会议室，点击“预定”按钮跳转到预定页，此时预定页需要自动带上这个会议室的编号和名称。vue路由参数在这里起到数据串联作用。列表页跳转时使用router.push并附带query参数：

// views/room/RoomList.vue import { useRouter } from 'vue-router' const router = useRouter() function goBook(room) { router.push({ name: 'booking-create', query: { roomId: room.id, roomName: room.name, date: new Date().toISOString().slice(0, 10) } }) }

预定创建页读取参数时，需要注意query参数的初始化和变化两种情况。组件挂载时读取一次就够了，因为从列表页进入预定页后通常不会再动态修改roomId：

import { useRoute } from 'vue-router' const route = useRoute() const formModel = reactive({ roomId: route.query.roomId || '', roomName: route.query.roomName || '', date: route.query.date || '', beginTime: '', endTime: '' })

路由参数的字段约定要稳定。roomId用于提交数据，roomName用于页面标题展示，date作为预定的默认日期。不推荐把整个room对象序列化成query参数，原因是URL长度有限，而且刷新页面后对象结构可能因为版本升级而不兼容。这里使用query而不是params，因为会议室预定场景里刷新页面后参数必须保留，query参数天然满足这个需求。

3.3 预定表单的自定义校验规则与 vue 样式隔离

预定表单的校验规则比普通表单复杂。除了必填校验，还有三条业务规则必须在前端拦截：结束时间必须晚于开始时间；预定时间不能跨天（会议室以天为单位对外开放）；预定的开始时间必须晚于当前时间至少15分钟。Element Plus的表单校验支持自定义validator，三条规则可以合并写成一个函数：

// views/booking/components/useBookingRules.js import dayjs from 'dayjs' export function validateTimeRange(rule, value, callback) { const form = rule.form if (!form.beginTime || !form.endTime) { callback() return } const begin = dayjs(`${form.date} ${form.beginTime}`) const end = dayjs(`${form.date} ${form.endTime}`) if (end.isBefore(begin)) { callback(new Error('结束时间必须晚于开始时间')) return } if (begin.isBefore(dayjs().add(15, 'minute'))) { callback(new Error('预定时间需早于当前时间15分钟')) return } if (form.date && end.day() !== begin.day()) { callback(new Error('预定不能跨天')) return } callback() }

rule.form可以拿到整个表单数据，这让跨字段校验变得容易。dayjs的isBefore比较的是毫秒时间戳，所以字符串拼接成日期时间格式后可以直接比较。边界条件是15分钟这个提前量，内部会议室预定通常不需要太长时间提前，这个参数应该提取到配置项中而不是写死在函数里。

样式方面，预定页常见的一个问题是子组件内部的Element Plus组件样式难以覆盖。Vue的scoped样式默认只作用于当前组件的DOM元素，对子组件内部元素的样式不生效。这时需要用:deep()选择器：

<style scoped> .time-slot-picker :deep(.el-button) { margin-right: 8px; min-width: 88px; } </style>

:deep()编译后会生成[data-v-xxx] .el-button的选择器，让样式穿透到子组件的指定元素上。vue样式处理在会议室预定系统里主要集中在时间选择按钮的尺寸、表格行高和表单间距上，统一在预定页的style里维护一套尺寸变量，避免每个组件各自为政。

4. 时间段冲突检测：预定系统的核心算法与 Pinia 状态管理

会议室预定系统的技术难点不在页面渲染，而在“如何可靠地判断某个时间段是否可用”。先明确冲突检测的判定范围，再给出可实现的核心代码，最后用Pinia把检测逻辑嵌入到数据流中。

4.1 三类冲突场景及对应处理策略

实际业务中冲突不止一种，会议室预定需要同时处理三类：

第一类冲突由后端最终判定，但前端必须做到“提交前预判”。原因是用户体验问题：用户选完时间段点击提交再被告知冲突，感知非常差。正确做法是前端根据已加载的预定记录预先禁用所有不可选时间片，让冲突在交互层面就不可能出现。第二类冲突可以通过配置表维护，维护时间窗口在系统里本质上是一组不可预定的时间段。第三类冲突需要查询参会人的其他会议记录，通常由后端在预定接口里返回USER_BUSY错误码，前端负责展示具体冲突的时间段。

4.2 区间重叠判断的数学原理与 hasConflict 函数实现

时间段冲突检测的本质是判断两个左闭右开区间[startA, endA)和[startB, endB)是否有交集。数学上有一个简洁的判定条件：startA < endB且startB < endA时两个区间重叠。注意边界情况：endA === startB时不算冲突，前一个会议结束时刻正好是后一个会议开始时刻是被允许的。基于这个原理在core/conflict.js里实现：

// src/core/conflict.js /** * 判断两个时间段是否存在重叠 * @param {string} startA - 时间段A开始，格式 'YYYY-MM-DD HH:mm' * @param {string} endA - 时间段A结束 * @param {string} startB - 时间段B开始 * @param {string} endB - 时间段B结束 * @returns {boolean} 重叠返回 true */ export function isTimeRangeOverlap(startA, endA, startB, endB) { const startATs = new Date(startA).getTime() const endATs = new Date(endA).getTime() const startBTs = new Date(startB).getTime() const endBTs = new Date(endB).getTime() if (startATs >= endATs || startBTs >= endBTs) { return false } return startATs < endBTs && startBTs < endATs } /** * 检查一个待创建预定是否与会话中的预定列表冲突 * @param {Object} booking - 待预定 { beginTime, endTime, roomId } * @param {Array} existingBookings - 已存在的预定记录列表 * @returns {Object|null} 返回冲突的记录，无冲突返回 null */ export function findConflictingBooking(booking, existingBookings) { return existingBookings.find( item => item.roomId === booking.roomId && isTimeRangeOverlap( booking.beginTime, booking.endTime, item.beginTime, item.endTime ) ) }

函数体中先做了一次时间范围的合法性检查，start >= end直接视为不重叠，避免脏数据导致异常判断。提交预定时调用findConflictingBooking，返回值存在即冲突。这里的时间字符串格式统一为YYYY-MM-DD HH:mm，与Element Plus的日期时间选择器输出格式保持一致。

4.3 用 Pinia store 统一管理预定提交动作

预定记录的加载和创建必须收敛到Pinia store中，不能散落在各个页面。store里预定列表是核心状态，创建动作里先执行前端冲突检测，再调用接口，这保证了“所有预定入口都走同一套校验逻辑”：

// src/stores/booking.js import { defineStore } from 'pinia' import dayjs from 'dayjs' import { findConflictingBooking } from '../core/conflict' import { getBookings, createBooking as apiCreateBooking } from '../api/booking' export const useBookingStore = defineStore('booking', { state: () => ({ bookings: [], loading: false, lastFetchedAt: null }), getters: { /** * 根据日期过滤当天的预定记录 */ bookingsByDate: state => date => { return state.bookings.filter(item => dayjs(item.beginTime).isSame(date, 'day') ) }, /** * 获取某个会议室在指定日期的已预定时间列表 */ occupiedTimeRanges: state => (roomId, date) => { return state.bookings .filter( item => item.roomId === roomId && dayjs(item.beginTime).isSame(date, 'day') ) .map(item => ({ start: dayjs(item.beginTime).format('HH:mm'), end: dayjs(item.endTime).format('HH:mm') })) } }, actions: { async fetchBookings(params) { this.loading = true try { const { data } = await getBookings(params) this.bookings = data this.lastFetchedAt = Date.now() } finally { this.loading = false } }, async createBooking(payload) { const conflict = findConflictingBooking(payload, this.bookings) if (conflict) { throw new Error(`与 ${conflict.title} 的预定时间冲突`) } const { data } = await apiCreateBooking(payload) this.bookings.push(data) return data } } })

findConflictingBooking的执行时机在接口调用之前，只依赖store中已加载的数据，所以是纯前端优化，不能替代后端校验。occupiedTimeRangesgetter返回的是HH:mm格式的时间点列表，正好配合时间选择器的禁用逻辑。预定时段默认按30分钟粒度切分，例如9:00至18:00会产生18个可选时间片，其中与已占用时间段重叠的全部禁用。

5. 接口层封装与 vue 路由权限守卫的落地写法

会议室预定系统不可能只有前端，接口层的设计决定了源码能否直接对接后端。常见做法是封装统一的axios实例、约定RESTful接口格式、在路由层面控制页面访问权限。这一章给出可直接使用的接口层代码和路由守卫配置。

5.1 基于 axios 的请求实例与拦截器封装

接口层的第一件事是为所有后端请求设置统一的baseURL、超时时间和鉴权头。用环境变量区分开发和生产接口地址是Vue项目的标准做法，在项目根目录的.env.development中写入VITE_API_BASE_URL=/api，构建时通过import.meta.env读取：

// src/api/http.js import axios from 'axios' import { ElMessage } from 'element-plus' import router from '../router' const http = axios.create({ baseURL: import.meta.env.VITE_API_BASE_URL || '/api', timeout: 10000 }) // 请求拦截：在每次请求的 header 中携带登录 token http.interceptors.request.use(config => { const token = localStorage.getItem('access_token') if (token) { config.headers.Authorization = `Bearer ${token}` } return config }) // 响应拦截：统一拆包与错误提示 http.interceptors.response.use( response => response.data, error => { const status = error.response?.status if (status === 401) { localStorage.removeItem('access_token') router.push({ name: 'login', query: { redirect: router.currentRoute.value.fullPath } }) } else if (status === 409) { ElMessage.warning(error.response.data.message || '该时间段已被预定') } else { ElMessage.error(error.response?.data?.message || '请求失败，请稍后重试') } return Promise.reject(error) } ) export default http

这个封装有两个关键参数。timeout设置10秒，会议室预定系统的接口通常不需要长轮询，10秒足够判断失败；response.data直接返回接口包装体，约定所有接口数据格式为{ code, message, data }，这样业务代码里不需要每次都写response.data.data。409状态码单独处理是因为冲突是预定系统的常态返回，需要给出人性化提示而非通用错误。

5.2 会议室预定系统的 RESTful 接口约定

后端还没有就绪时，接口层先按约定编写，后续对接时只需要修改baseURL。预定系统最小的接口集合如下：

具体请求函数围绕http实例封装在api/booking.js中：

// src/api/booking.js import http from './http' export function getBookings(params = {}) { return http.get('/bookings', { params }) } export function createBooking(data) { return http.post('/bookings', data) } export function cancelBooking(id) { return http.patch(`/bookings/${id}/cancel`) }

每个函数只做一件事，不包含任何业务判断。业务判断被放在store层，这一点与前面章节的设计一致。接口路径语义化：cancel用PATCH而不是DELETE，原因是取消预定是一个状态变更操作，预定的历史记录需要保留，不能物理删除。

5.3 vue 路由守卫实现登录态检查和角色权限管理

会议室预定系统通常有普通员工和管理员两类角色。普通员工能查看和预定会议室，管理员还拥有会议室管理、预定审核权限。路由权限通过meta字段声明，在路由表里配置：

// src/router/index.js const routes = [ { path: '/login', name: 'login', component: () => import('../views/user/Login.vue') }, { path: '/', component: () => import('../layouts/AdminLayout.vue'), meta: { requiresAuth: true }, children: [ { path: 'rooms', name: 'room-list', component: () => import('../views/room/RoomList.vue'), meta: { title: '会议室列表' } }, { path: 'bookings/create', name: 'booking-create', component: () => import('../views/booking/BookingCreate.vue'), meta: { title: '预定会议室' } }, { path: 'admin/rooms', name: 'admin-room', component: () => import('../views/admin/RoomManage.vue'), meta: { title: '会议室管理', requiresAuth: true, role: 'admin' } } ] } ]

路由守卫通过beforeEach钩子统一处理未登录跳转和角色越权：

// src/router/guard.js import { useUserStore } from '../stores/user' export function setupRouterGuard(router) { router.beforeEach((to, from, next) => { const storedToken = localStorage.getItem('access_token') if (to.meta.requiresAuth && !storedToken) { next({ name: 'login', query: { redirect: to.fullPath } }) return } if (to.meta.role) { const userStore = useUserStore() if (userStore.role !== to.meta.role) { next({ name: 'room-list' }) return } } next() }) }

这个实现对Vue依赖的关键点在于：useUserStore()必须放在守卫函数内部调用，因为beforeEach执行时Vue应用已经完成初始化，Pinia实例可用。加载用户角色信息可以放在App.vue的onMounted中请求/user/profile，接口返回角色后写入userStore，后续的路由判断都读store中的角色值，避免每个页面单独检查token。

6. 会议室预定系统打包优化、Nginx 部署与多人预定的实时刷新技巧

会议室预定系统从前端开发到上线部署，有一个高频问题：本地开发一切正常，npm run build && npm run deploy之后页面白屏或样式错乱。这类问题很多源于构建时的资源路径和路由模式。最后这一章给出Vue 3项目部署的常见修正方案，以及多人同时预定场景下的实时刷新技巧。

先看资源路径问题。项目默认构建后index.html中引用的JS和CSS地址以根路径/开头，部署到服务器子目录时所有资源404。vite.config.js中通过base参数修正为相对路径：

// vite.config.js import { defineConfig } from 'vite' import vue from '@vitejs/plugin-vue' export default defineConfig({ base: './', plugins: [vue()] })

base: './'会让构建产物中的资源引用变为相对路径，dist目录直接放在Nginx任意子路径下都能访问。这一个参数能解决多数“vue打包后布局异常”的排查场景，注意修改后必须删除旧的dist目录重新构建。

会议室预定系统如果使用createWebHistory路由模式，部署到Nginx后刷新页面会出现404。原因是前端路由路径在后端没有对应文件，需要配置try_files将所有请求回退到index.html：

server { listen 80; server_name meeting.example.com; root /usr/share/nginx/html; index index.html; location / { try_files $uri $uri/ /index.html; } }

重载Nginx配置后，/bookings/create这类路径在刷新时能正确回退到前端路由。$uri尝试匹配真实文件，/index.html是最终回退，顺序不能颠倒。

多人同时预定导致的“看到空闲但提交时被占用”问题，仅靠前端的冲突检测不够。前端所有预定界面在切回页面时会触发store的更新，刷新依赖的时间点可以用页面可见性。visibilitychange事件在用户从其他标签页切回系统时触发，比定时轮询更省资源：

// views/booking/BookingList.vue import { onMounted, onUnmounted } from 'vue' import { useBookingStore } from '../stores/booking' const bookingStore = useBookingStore() let visibilityHandler = null onMounted(() => { visibilityHandler = () => { if (document.visibilityState === 'visible') { const today = new Date().toISOString().slice(0, 10) bookingStore.fetchBookings({ date: today }) } } document.addEventListener('visibilitychange', visibilityHandler) }) onUnmounted(() => { document.removeEventListener('visibilitychange', visibilityHandler) })

组件卸载时必须移除事件监听，否则从预定列表页跳转到详情页后再返回，会绑定多个handler，导致同一时刻发起多次重复请求。这种“回到页面即刷新”的策略适合预定频率不高的内部系统；如果会议室超过50间且并发高，建议在后端预定接口的事务里加行锁，或者用Redis的setnx做分布式锁，前端依然靠轮询或WebSocket同步状态。

本文还有配套的精品资源，点击获取