简介本资源是一套基于Vue.js开发的智能会议室预约系统前端完整源码面向前端初学者、Vue进阶开发者及企业信息化建设人员旨在解决传统人工预约效率低、易冲突、难追溯等管理痛点适用于中小型企业、高校行政办公等多场景会议室数字化管理需求。压缩包共37个文件含15个功能完备的Vue组件如登录页、会议室列表、详情与预约表单、6个JavaScript交互逻辑脚本涵盖搜索、筛选、表单提交等核心流程、5个CSS样式文件实现响应式布局与Bootstrap风格UI以及JSON配置、HTML入口、ICO图标等必要资源整体体积仅962KB轻量易部署。已有322人学习下载代码结构清晰采用Vite构建、模块化路由与Pinia状态管理雏形附带README说明与LICENSE协议可直接运行调试、二次开发或作为Vue工程化实践教学案例。 会议室预约系统只要公司在十几人以上基本都会遇到“会议室打架”的尴尬行政那边有个Excel登记表但永远有人不按流程来口头占个坑就完事钉钉群或者邮件约了也不一定能同步到所有人到了下午三点的关键会议推门进去发现屋里坐满了另一个团队。这套基于Vue的智能会议室预约系统前端源码就是冲着这个痛点来的。整个项目用Vue全家桶实现包含登录权限、会议室列表、日历预约、我的预约、审批流程五个完整模块前端代码完全可控后端按企业自己的接口对接就行。这篇文章我会把设计思路、源码结构、核心逻辑和踩过的坑全部拆开讲适合正在做企业内部系统、想学习Vue实战项目、或者准备用在简历作品集里的前端开发者参考。1. 项目概述这是一套解决“会议室打架”问题的前端源码1.1 需求从哪来办公场景的隐藏痛点我在开发这套系统之前先花了一周时间观察和访谈公司内部的会议组织情况发现预约场景的混乱程度远超预期。最常见的几个问题首先是使用状态不透明某间会议室明明被约了但系统里查不到记录导致其他人误入其次是有约不来人预约人临时取消出差会议室也没有释放机制后面想用的人只能干等最后是审批流靠口头或者邮件行政根本来不及核对每个预约是否真的必要。这些问题的本质是“会议室资源”没有变成可查询、可流转、可统计的数据。也就是说会议室本身要作为一个资源实体来管理预约行为要变成一个带状态的事件流。前端要做的事情不是简单做一个表单而是把整个使用过程从“查到房”到“约上房”、再到“审批通过”“到点使用”“结束释放”完整地串起来并且让所有状态都能在页面上直观体现出来。1.2 前端要完成的核心闭环预约系统的用户链路并不复杂但每个节点都必须闭环。用户进入系统后第一眼看到的应该是当前可用的会议室列表点进某一间会议室能看到它未来几天的占用情况然后选择日期、时间段、填写事由提交预约。提交之后如果是需要审批的会议室就进入待审批状态如果是不需要审批的公共小会议室就直接通过。管理员在后台可以看到所有待审批申请做通过或者驳回操作申请人在“我的预约”里看到最终结果。这个闭环拆到前端就对应着五个页面登录页、会议室列表页、日历详情页、预约表单页、我的预约与管理页。页面与页面之间不是孤立的预约成功后立即影响列表页的“空闲/占用”状态管理员审批通过后用户端日历上也要立刻呈现。正因为这种联动关系项目里才引入了状态管理和统一接口层而不是把数据写在单个组件的本地变量里。1.3 这份源码适合谁拿去参考从源码适用性来看第一类适合的人是中小公司内部系统开发者这类项目通常没有大团队更不会买昂贵的OA套件需要的就是一套轻量、能快速改前端样式和后端接口的实现。第二类是正在学习Vue实战的前端开发者这套源码里包含路由守卫、权限指令、组件通信、状态管理、接口封装、日期处理这些高频知识点比零散的Demo有体系得多。第三类是准备找工作或者做作品集的朋友预约系统算是最经典的管理系统题材需求清晰、功能完整、演示效果直观在面试里聊起来也很自然。只要你会基本的Vue语法跟着这篇文章把源码跑起来就能很快上手修改。2. 技术选型为什么这套源码选了Vue 3这条路线2.1 Vue 3 Vite内部系统的务实选择这套源码最初也考虑过用React重写但最终选型还是Vue原因其实很务实。团队内部对于Vue的熟练度更高Vue的模板语法和响应式特性在管理后台这种表单密集、列表密集的场景下开发效率非常高。尤其是Vue 3的组合式API配合script setup写法把原有分散在data、methods、computed里的逻辑收拢到一起一个功能相关的代码都集中在一个区域可维护性比Vue 2时代好了太多。项目构建工具选的是Vite而不是Webpack。Vite基于ESModule冷启动基本在几百毫秒级别本地开发保存后热更新也是瞬间完成配合Vue 3的开发体验非常顺。如果还用Vue CLI加Webpack也不是不能跑但在大型项目里每次保存都要等两三秒这种开发损耗没有意义。下面是项目入口组件里最典型的用法可以看到组合式API下的代码组织方式script setup import { ref, onMounted } from vue import { getRoomList } from /api/room const roomList ref([]) const loading ref(false) onMounted(async () { loading.value true try { const res await getRoomList() roomList.value res.data } finally { loading.value false } }) /script2.2 组件库与配套库怎么配整个项目的依赖选择主要围绕“好用、稳定、体积可控”这三个原则。UI组件库用了Element Plus原因很简单Vue 3生态里最成熟、组件最全、后台管理系统需要的表格、表单、日历、日期选择器它都有而且是国人团队维护中文文档和社区案例非常多。状态管理用了Pinia而不是VuexPinia的API设计更贴合组合式API风格去掉了mutations的概念store里可以直接写action和getter样板代码少了很多。路由用Vue Router 4这是Vue 3官方配套版本支持动态路由、懒加载和导航守卫权限控制全靠它。HTTP请求用了Axios它是目前前端请求库的事实标准拦截器机制对于处理token注入和统一错误提示非常方便。日期处理用day.js体积只有几KBAPI和Moment几乎一致但不会像Moment那样带着一整个语言包拖慢打包体积。下面是核心依赖清单依赖版本用途vue3.4.x框架核心vite5.x构建工具element-plus2.xUI组件库pinia2.x状态管理vue-router4.x前端路由axios1.xHTTP请求dayjs1.x日期解析与格式化2.3 目录结构与分层思路这套源码的目录结构不是随手建的而是按照“展示层、复用层、状态层、请求层、工具层”五层来划分。很多前端项目后来变得难以维护根源就在于组件里既写了接口调用、又处理了业务逻辑、还把Loading和错误提示混在一起改一个需求要动三个文件。为了避免这种问题项目里所有接口请求统一放在src/api目录下页面组件里只调用对应的方法不直接使用Axios实例所有可复用的状态统一放在src/stores目录下纯函数逻辑放在src/utils目录下。src/ ├── api/ │ ├── room.js # 会议室相关接口 │ └── booking.js # 预约相关接口 ├── assets/ ├── components/ │ ├── RoomCard.vue │ └── CalendarPanel.vue ├── layouts/ │ └── DefaultLayout.vue ├── router/ │ └── index.js ├── stores/ │ ├── user.js │ └── booking.js ├── utils/ │ ├── request.js │ └── conflict.js └── views/ ├── login/ ├── room/ ├── booking/ └── admin/这样的分层带来一个直接好处就是当后端接口地址发生变更时只需要修改src/api目录下的文件当某个页面的交互样式调整时只需要动views和components当多个页面需要共享同一份预约数据时只需要在stores里统一维护。这套结构放到真实团队里新人上手成本会低很多。3. 功能模块与源码拆解预约系统的五个核心页面3.1 登录与权限不同角色看到的不同世界预约系统里其实有两种角色普通用户和管理员。普通用户只能查看会议室、提交预约、取消自己的预约管理员除了这些操作之外还要能看到所有待审批的申请并执行通过或者驳回操作。前端处理这种差异最核心的手段是路由守卫加按钮级权限指令。用户登录后后端会返回一个token和角色信息token存到localStorage角色信息存到Pinia里。每次路由跳转之前全局前置守卫会先检查有没有token没有就跳去登录页。有token之后再看目标路由的meta里有没有声明roles如果声明了但当前用户角色不在里面就跳转到403页面。router.beforeEach((to, from, next) { const token localStorage.getItem(token) if (to.path ! /login !token) { next(/login) return } const userStore useUserStore() if (to.meta.roles !to.meta.roles.includes(userStore.role)) { next(/403) return } next() })按钮级别的权限我用了一个自定义指令这样管理员才能看到“审批通过”和“驳回”按钮普通用户永远看不到app.directive(permission, { mounted(el, binding) { const userStore useUserStore() const allowedRoles binding.value if (!allowedRoles.includes(userStore.role)) { el.parentNode?.removeChild(el) } } })权限这块最常见的问题是后端只返回了token没有返回角色信息前端就没办法判断当前用户是谁。实际项目里一定要在登录接口返回用户信息和token或者在登录后请求一次/user/info接口拿到角色字段再往下走流程。3.2 会议室列表筛选、状态与信息一览会议室列表是系统的首页也是用户感知最直接的模块。每一间会议室的信息包括名称、所在楼层、容纳人数、配套设备投影、白板、视频会议终端、当前状态空闲、维护中、使用中。列表按会议室卡片排列卡片上清晰展示这些基础信息。筛选功能我做了两个维度一个是最小容纳人数一个是楼层。筛选逻辑用计算属性实现而不是在模板里写一堆方法调用。计算属性会缓存计算结果依赖的响应式数据没有变化时不会重新计算性能上比方法更优。const filteredRooms computed(() { return roomList.value.filter(room { const matchCapacity room.capacity filters.minCapacity.value || !filters.minCapacity.value const matchFloor filters.floor.value ? room.floor filters.floor.value : true return matchCapacity matchFloor }) })状态标签我用了一个映射对象来管理这样做的好处是状态文案和显示类型只维护一份不会在模板里到处写死const statusMap { available: { text: 空闲, type: success }, maintenance: { text: 维护中, type: warning }, occupied: { text: 使用中, type: info } }在真实使用中还要注意一点列表页的状态数据来自接口但只是某一个瞬间的快照。用户进入列表页后如果其他同事已经预约了某间会议室列表不会自动刷新。所以我在onActivated生命周期里重新请求了一次列表因为列表页使用了KeepAlive缓存切换到其他标签再回来时能保证数据是最新的。3.3 日历视图预约系统最复杂的交互点日历视图是这套系统里交互最复杂的模块也是用户最依赖的功能。我选择基于Element Plus的el-calendar做二次封装没有自己从零写日历原因是组件库里的日历已经处理好了周排列、月份切换、日期选择这些底层逻辑自己再写一遍纯粹是浪费时间。封装的关键点在于如何使用日历的插槽。el-calendar支持date-cell插槽允许我们在每个日期格子里渲染自定义内容。我在格子里展示了当天所有预约的标题并且做了截断如果当天预约超过3条就只显示前3条再加一个“N”的提示点击格子之后右侧面板会加载这一天的完整预约列表。el-calendar v-modelselectedDate template #date-cell{ data } div classdate-item clickhandleSelectDay(data.day) div{{ data.day.getDate() }}/div div v-foritem in getBookingsByDate(data.day) :keyitem.id classbooking-tag {{ item.title }} /div div v-ifgetBookingsByDate(data.day).length 3 {{ getBookingsByDate(data.day).length - 3 }} /div /div /template /el-calendar在封装这个组件的时候最需要注意的一个细节是日期格式化。el-calendar传出来的data.day是一个JavaScript的Date对象而后端接口通常只接受“YYYY-MM-DD”这种字符串格式。我统一在工具函数里做了格式化避免在页面组件里到处写date.getFullYear()这类逻辑。格式化函数用day.js一行搞定function formatDate(date) { return dayjs(date).format(YYYY-MM-DD) }日历上的初始日期默认是今天为了让用户少点几次还做了限制过去日期的格子可以看但不能点击预约当天的预约列表默认展示明天及以后的日期才开放预约入口。3.4 预约表单与冲突校验宁可多写一个判断预约表单的设计遵循“最少填写、最多校验”的原则。用户填写的字段包括会议室默认带出但可改、日期、开始时间、结束时间、使用事由、参会人数。会议室和日期这两个字段在流程里已经默认带出减少重复输入。校验规则分了几层首先是必填校验会议室、日期、开始时间、结束时间、事由都不能为空其次是逻辑校验结束时间必须晚于开始时间日期不能是过去日期最后是业务校验同一个会议室在同一时间段不能被同时预约。Element Plus的表单校验用rules声明式配置非常方便const rules { roomId: [{ required: true, message: 请选择会议室, trigger: change }], date: [{ required: true, message: 请选择日期, trigger: change }], start: [{ required: true, message: 请选择开始时间, trigger: change }], end: [{ validator: (rule, value, callback) { if (!value) { callback(new Error(请选择结束时间)) } else if (dayjs(value).isBefore(dayjs(form.start))) { callback(new Error(结束时间必须晚于开始时间)) } else { callback() } }, trigger: change }] }业务校验部分我放在了提交时统一执行。提交前先调用后端的时间冲突检测接口同时前端也用当天已有的预约数据做一遍本地判断双重校验避免在极端情况下产生重复预约。后面第4章会专门讲冲突判断的具体实现。3.5 我的预约与审批流状态机的可视化“我的预约”页面是用户在系统里所有申请记录的集中展示也是状态流转最清晰的页面。预约状态我用了一个统一的状态机待审批、已通过、已拒绝、已取消。用户看到的状态不同可做的操作也不同。处于待审批状态的申请可以取消已通过状态的申请如果还没开始也可以取消但已拒绝和已取消的都不可再操作。状态在UI上用不同颜色的Tag组件来呈现一眼就能看出来当前处于哪个阶段const statusMap { pending: { text: 待审批, type: warning }, approved: { text: 已通过, type: success }, rejected: { text: 已拒绝, type: danger }, cancelled: { text: 已取消, type: info } }管理员端审批页的逻辑更简单直接只展示所有状态为“待审批”的申请列表每条申请后面放“通过”和“驳回”两个按钮。点击后调用审批接口接口返回值更新之后列表马上刷新对应申请状态从待审批变成已通过或已拒绝。审批和取消操作都设计成了二次确认弹窗避免手滑误操作。这种设计看起来很简单但在真实办公场景里踩过坑曾经有同事想查看一条已拒绝记录不小心点到了“取消申请”按钮当时弹窗还没有二次确认他想取消的其实是一条已经生效的预约搞得行政那边反复核对好几天。4. 关键实现的源码细节路由、状态与接口4.1 路由懒加载和全局守卫怎么写路由配置是这个项目里最需要理解清楚的文件之一。所有页面都使用动态import做懒加载Vite会对每个动态引入的模块单独打包首屏只加载必要的文件而不是把整个应用的代码一次性全部拉到浏览器里。配合路由懒加载还能在路由级做代码分割预约系统页面多但单页面逻辑不算重这种方式特别合适。const routes [ { path: /, component: () import(/layouts/DefaultLayout.vue), redirect: /rooms, children: [ { path: rooms, name: RoomList, component: () import(/views/room/RoomList.vue) }, { path: my-booking, name: MyBooking, component: () import(/views/booking/MyBooking.vue) }, { path: admin, name: AdminApprove, component: () import(/views/admin/ApproveList.vue), meta: { roles: [admin] } } ] }, { path: /login, name: Login, component: () import(/views/login/Login.vue) } ]路由元信息meta里可以塞角色配置meta.roles接收一个数组同一个页面允许多个角色访问时就写多个角色。全局守卫在路由跳转前执行统一处理登录态和角色判断这部分代码量不大但它是整个权限体系的基石后面新增页面记住在路由里配置好meta就可以了。4.2 Pinia里怎么放预约数据预约数据被多个页面共享如果用组件局部状态管理会非常痛苦。比如用户从日历页提交一个预约跳回到会议室列表页列表页需要立刻知道这间会议室在对应时间段是不是已经不可用了如果这中间没有共享数据就只能让列表页再次请求接口效率很低。所以我用Pinia设计了bookingstore统一承载所有预约相关数据。import { defineStore } from pinia import { getBookingList, createBooking, cancelBooking } from /api/booking export const useBookingStore defineStore(booking, { state: () ({ bookings: [], selectedDate: , loading: false }), getters: { bookingsByDate: (state) (date) { return state.bookings.filter(item item.date date) } }, actions: { async fetchBookings(params) { this.loading true try { const res await getBookingList(params) this.bookings res.data } finally { this.loading false } }, async submitBooking(payload) { const res await createBooking(payload) await this.fetchBookings({ date: payload.date }) return res }, async cancelBookingById(id) { const res await cancelBooking(id) await this.fetchBookings({ date: this.selectedDate }) return res } } })store里定义了bookings数组用来存当前月份的预约数据定义bookingsByDategetter来按日期筛选定义fetchBookings、submitBooking、cancelBookingById三个action来封装异步操作。action内部会在创建或者取消预约后自动刷新数据页面组件调用action之后不需要关心数据同步的问题。这种设计带来的好处是日历视图、会议室列表、我的预约几个页面引用的都是同一个bookings数据源只要有一个页面做了操作其他页面的展示状态会自动同步不需要互相发事件或者传递回调。4.3 时间冲突判断的边界条件冲突判断是预约系统最容易写错的地方也是最值得抠细节的地方。两个时间段是否有重叠基础判断逻辑可以用四个字概括“一端在别一端区间内”。更严谨的条件是两个区间[start1, end1]和[start2, end2]只要满足start1 end2 end1 start2就说明存在重叠。export function checkConflict(newStart, newEnd, exists) { return exists.some(item { const s new Date(${item.date}T${item.start}:00).getTime() const e new Date(${item.date}T${item.end}:00).getTime() return newStart e newEnd s }) }这段代码有几个边界情况需要注意。第一个是开始时间等于已有预约的结束时间比如已有一条10:00到11:00的预约新预约从11:00开始这两个区间的关系是start1 e中start1等于e条件不成立所以不冲突这符合直觉上一场结束了下一场可以开始。第二个是结束时间等于已有预约的开始时间同理也不冲突。第三个是完全被包含的情况比如已有10:00到12:00新预约10:30到11:30显然start1小于e且end1大于s条件成立会正确判为冲突。时间格式在前端和后端之间一定要统一我这边统一约定为“HH:mm”字符串判断时先拼上日期再转成时间戳。曾经遇到过后端返回的时间格式带上了“HH:mm:ss”前端直接用字符串比较出现了“09:30”和“09:30:00”不一致的坑所以在工具函数里做了格式兜底统一转成时间戳再比较避免这种低级错误。4.4 接口封装与响应拦截所有的接口请求都经过src/utils/request.js这个封装好的Axios实例页面和store里的api模块都从它导出方法。封装的核心目的有两个统一注入token和统一处理业务错误码。import axios from axios import { ElMessage } from element-plus const service axios.create({ baseURL: import.meta.env.VITE_API_BASE, timeout: 10000 }) service.interceptors.request.use(config { const token localStorage.getItem(token) if (token) { config.headers.Authorization Bearer ${token} } return config }) service.interceptors.response.use( res { const { code, data, message } res.data if (code ! 0) { ElMessage.error(message || 请求失败) return Promise.reject(new Error(message)) } return { data, message } }, error { if (error.response?.status 401) { localStorage.removeItem(token) window.location.href /login ElMessage.error(登录已过期请重新登录) } else { ElMessage.error(error.message || 网络异常) } return Promise.reject(error) } ) export default service这里约定后端返回格式为{ code, data, message }code为0表示成功。拦截器里统一解包所以接口方法拿到的直接是data字段不需要每个页面再写一遍response.data.data的无意义代码。401状态码统一处理为跳回登录页这是最常见的会话过期场景。api模块的文件长这样import service from /utils/request export function getRoomList(params) { return service.get(/rooms, { params }) } export function getBookingList(params) { return service.get(/bookings, { params }) } export function createBooking(data) { return service.post(/bookings, data) } export function cancelBooking(id) { return service.put(/bookings/${id}/cancel) }5. 实测踩坑从本地跑通到上线部署的记录5.1 服务器刷新404history路由的必修课这是几乎所有Vue路由项目上线后遇到的第一个坑。本地开发时前端服务器会帮我们把所有请求都交给Vue Router处理所以随便刷新哪个路径都能正常显示。但是部署到Nginx之后访问https://yourdomain.com/my-booking然后点刷新服务器会去找一个叫my-booking的资源文件找不到自然就返回404了。根本原因是Vue Router的history模式是前端路由浏览器地址栏里的路径是给前端框架用的真实的服务器目录里没有这些路径。解决办法是在Nginx里配置一个try_files规则让所有请求都回退到index.htmllocation / { try_files $uri $uri/ /index.html; }配置好之后刷新任意前端路由都能正确加载。如果项目里还有404页面可以在前端路由里加一个path: /:pathMatch(.*)*的通配路由指向自定义的404组件而不是直接显示Nginx默认的404页面。5.2 devServer转发本地联调怎么配本地开发时前端跑在5173端口后端接口跑在8080端口浏览器直接请求8080会碰到跨域问题。解决方式不是在代码里写死http://localhost:8080而是在Vite的devServer里配置接口转发这样前端代码里只写/api/xx这样的相对路径开发时由Vite转发到后端生产环境再把VITE_API_BASE配成网关地址。// vite.config.js export default defineConfig({ plugins: [vue()], server: { port: 5173, proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } })这样配置之后前端请求/api/roomsVite会自动转发到http://localhost:8080/api/rooms不需要后端额外做跨域配置。生产环境部署时Nginx也做了同样的转发把前端的/api路径转发到后端的服务地址前端代码完全不需要改。5.3 el-calendar二次封装的要点el-calendar的默认样式偏简单需要做二次封装才能达到商用效果。首先要处理的是日期禁用逻辑直接在日历组件上通过disabled-date属性控制我禁用了今天之前的日期同时禁用了会议室维护日。其次是格子里内容排序按照预约的开始时间升序排列这样用户一眼就能看到早上的会议排在前面。预约条目多的时候还会遇到性能问题。日历默认会渲染一个整月的日期格子如果某天有几十条预约全部渲染成DOM节点就会很卡。我的处理方式是每个格子最多展示3条超出部分折叠成“N”点击日期后再展示完整列表。这样一来日历上渲染的DOM节点数量被控制住性能问题基本消失。还有一个格式化的坑获取到的data.day是Date对象但有时不同浏览器对日期协处理会有时区差异。我统一用dayjs格式化后再传给后端接口确保提交的日期与日历上点击的日期完全一致避免“提交之后发现日期少了一天”这种灵异问题。5.4 响应式丢失一个让人抓狂的更新问题开发过程中遇到过一个非常隐蔽的Bug列表页修改筛选条件之后页面数据没有更新排查了很久才发现是响应式丢失问题。具体场景是reactive对象被解构后解构出来的变量已经失去了响应式代理const state reactive({ list: [] }) const { list } state // 此时 list 是普通数组对它做 push 不会触发页面更新 list.push(item)在实际代码里我一开始把日期筛选条件挂在reactive对象上然后在另一个函数里解构出来用结果修改解构后的变量页面纹丝不动。解决方式有两种要么不要解构reactive直接使用state.list要么用toRefs把响应式对象转换成一组ref再解构。const state reactive({ list: [], keyword: }) const { keyword } toRefs(state) // 此时 keyword 是响应式 ref修改 keyword.value 会触发更新这一点在使用Pinia store的时候也容易踩雷store里的state本身是响应式的但从store里解构状态时也需要注意最好用storeToRefs来解构否则页面同样不会更新。6. 源码使用指南与后续扩展6.1 三步把源码跑起来下载源码之后本地跑起来非常简单只需要三步。第一步安装依赖建议使用npm或pnpm在项目根目录执行npm install。第二步配置环境变量项目里提供了一个.env.development文件模板把VITE_API_BASE改成你的后端地址如果暂时没有后端可以直接用项目自带的mock方案。第三步执行npm run dev启动成功后浏览器访问http://localhost:5173默认账号和密码在登录页上有提示。npm install npm run dev如果项目后续要部署到生产环境执行npm run build产物会输出到dist目录把这个目录里的内容发布到Nginx的静态站点目录下即可。构建前记得把.env.production文件里的接口地址配成生产环境的网关地址。6.2 没有后端接口怎么联调很多同学拿到源码后发现没有后端接口全都调不通。项目里已经内置了一套mock方案用的是vite-plugin-mock。这个插件会在开发环境下拦截指定的请求返回mock数据这样前端的登录、会议室列表、预约提交、审批流程都可以完整跑通不需要真实后端也能看到全部效果。// mock/room.js export default [ { url: /api/rooms, method: get, response: () { return { code: 0, data: [ { id: 1, name: A101, capacity: 10, floor: 1, status: available }, { id: 2, name: A202, capacity: 20, floor: 2, status: occupied } ] } } } ]mock数据我建议单独放在mock目录和源码目录分开这样接入真实后端时直接删除或禁用整个mock配置就行。要注意的是mock插件只能用在开发环境生产环境构建时要通过环境变量关闭否则会把mock代码打进生产包里这是很多新手容易犯的错误。6.3 后续还能扩展哪些能力这套系统的定位是“智能会议室预约”目前实现的是核心预约管理闭环但扩展空间还很大。最实用的是与企业微信或钉钉对接免密登录员工再也不用记住单独的账号密码直接用企业身份登录就能预约。其次是会议室门口放一块展示屏显示当前会议主题、使用时间、剩余时长这块屏幕可以直接用一套只读的前端页面显示复用预约数据接口。还有一个方向是使用率数据统计在已有的预约数据基础上可以按会议室、按天、按周统计使用率图表展示用ECharts画出来哪些会议室经常闲置、哪些时段是预约高峰都能直观呈现。这个能力对行政和部门管理者来说非常有用能让预约系统从“工具”升级成“管理决策依据”。接入智能门禁和扫码签到也能进一步减少会议迟到和预约未到的情况。整个系统后续可以做的点非常多但核心还是那套预约数据流把它管理好前端上层场景都可以灵活扩展出来。最后再分享一个实际经验这套系统前后经历了两轮重构第一版用的是Vue 2加Vuex后来整体迁移到Vue 3加Pinia。迁移过程本身不复杂但我收获最大的不是技术本身而是体会到一个预约系统表面上是个CRUD应用真正的复杂度都在状态流转和边界条件上。时间重叠判断、不同角色看到的不同操作、预约状态的各种组合这些才是需要反复测试的点。你在改这套代码时建议先通读一下stores/booking.js和utils/conflict.js这两个文件它们是整个项目的核心只要把这两块逻辑吃透其他页面基本就是普通的表单和列表开发。本文还有配套的精品资源点击获取
