简介一份基于Vue框架的会议室预定系统设计源码面向Vue学习者、前端工程师及需要快速搭建内部管理系统的团队解决会议室预订、查询与排期冲突等日常管理痛点。源码整体采用组件化与前后端分离架构通过数据驱动和单页面应用模式实现流畅交互。压缩包共33个文件、约871KB以17个JavaScript文件承担核心逻辑6个Vue组件文件划分会议列表、预定表单等视图另含PNG图标、JSON配置、HTML骨架及Babel/Git等工程化配置结构清晰、便于二次开发。已有124人学习浏览适合用于理解Vue工程目录组织、组件通信和接口层与工具模块的典型写法。通过阅读源码可以掌握多页面视图与路由的协作方式并可直接复用预定表单校验、数据请求等模块节省同类项目开发时间。1. 会议室预定系统的手写 Vue 2 工程为什么值得拆下载这个源码包之前我以为它只是一个普通的课程设计几个 Vue 组件拼一个页面能预览就算完成。真正解压 upload.zip 之后发现里面躺着一整套 Vue 2 工程结构——build 目录里有 webpack.base/dev/prod 三份配置config 目录里管着 dev 和 prod 两套环境变量src 下分了 api、utils、components、pages、router外加 .babelrc、.editorconfig、.postcssrc.js。这不是脚手架生成完就扔着不管的项目而是一个可以被完整跑起来的工程雏形。对准备做企业级中后台的开发者来说它的价值不在于会议室预定这个业务本身而在于它把 Vue 2 时代“从源码到构建产物”的全链路摊开在了你面前。适合两类人一类是刚学完 Vue 基础、想知道真实项目长什么样的新手另一类是长期在 Vue CLI 里写业务、没看过底层 webpack 配置的熟手。2. 构建配置是骨架webpack 三件套与 Babel 兼容链2.1 先分清 build 与 config 目录的职责解压源码包后第一眼应该看的是根目录结构而不是急着点开 App.vue。这个项目保留了 Vue 2 时代最经典的 webpack 手工配置方式build 目录存放构建脚本config 目录存放可被环境变量读取的配置。两者各自承担的职责完全不同我把它们拆成一张表来看文件角色关键作用build/webpack.base.conf.js基础配置定义入口、出口、路径别名、loader 规则build/webpack.dev.conf.js开发配置启用 devServer、热更新、代理转发proxyTablebuild/webpack.prod.conf.js生产配置代码压缩、静态资源指纹hash、CSS 抽取build/build.js构建启动脚本执行 webpack 编译并输出构建统计build/utils.js工具函数生成 CSS 处理器的 loader 链build/vue-loader.conf.js单文件组件编译配置 scoped CSS 和 CSS Modules 方案config/index.js统一配置出口合并 dev 和 prod 的路径、端口、代理规则config/prod.env.js / dev.env.js环境变量文件注入 process.env.XXX 到业务代码提示整个构建链路的数据流向是 build.js 拉取 webpack 配置文件webpack.base.conf.js 定义基础规则dev/prod 配置通过 webpack-merge 覆盖差异项config/index.js 里的 proxyTable 和 assetsPublicPath 再被三个配置引用。实际操作中npm run dev首先执行的是 build/dev-server.js 或 build.js 里的webpack-dev-server逻辑。这个项目没有 src/main.js 之外的挂载遗漏说明入口链路是完整的。阅读顺序建议从 build/webpack.base.conf.js 开始因为它决定了项目能不能编译、模块怎么被解析。2.2 entry 与 resolve读懂入口和路径别名是第一步一个 Vue 2 工程的入口配置通常长这样在 base.conf.js 的 module.exports 里const path require(path) function resolve(dir) { return path.join(__dirname, .., dir) } module.exports { context: path.resolve(__dirname, ../), entry: { app: ./src/main.js }, output: { path: config.build.assetsRoot, filename: [name].js, publicPath: process.env.NODE_ENV production ? config.build.assetsPublicPath : config.dev.assetsPublicPath }, resolve: { extensions: [.js, .vue, .json], alias: { vue$: vue/dist/vue.esm.js, : resolve(src) } } }这里有几个非常实际的信息点output.path指向的config.build.assetsRoot在 config/index.js 里通常被定义为path.resolve(__dirname, ../dist)也就是说生产构建产物会落在项目根目录的 dist 文件夹。assetsPublicPath决定打包后 index.html 里引用的 JS/CSS 路径是以/开头还是以相对路径开头部署到子目录时这里必须改成./否则页面白屏。resolve.alias里的别名很关键。这个源码包中router/index.js、pages 下的组件、api 目录都用/来引用模块。extensions数组里默认补全扩展名的顺序是 js → vue → json如果业务代码里写了import Hello from ./HelloWorld而没有后缀会先去找 HelloWorld.js再找 HelloWorld.vue。曾经有同事新建了一个跟某组件同名的空 js 文件结果 Vue 组件一直没渲染排查了半天才发现是扩展名优先级的坑。2.3 Babel 配置决定代码能跑在什么浏览器上这个工程里能看到 .babelrc、.postcssrc.js 和 package.json 里的 browserslist 字段三者共同决定代码的“向下兼容”边界。browserslist 控制的是最终编译产物需要兼容哪些浏览器版本而 .babelrc 控制的是 ES6 语法如何被转译。{ presets: [ [env, { modules: false, useBuiltIns: usage, targets: { browsers: [ 1%, last 2 versions, not ie 8] } }], stage-2 ], plugins: [transform-vue-jsx, transform-runtime] }这套配置是 Vue 2 webpack 3/4 时代最常见的写法。useBuiltIns: usage会让 Babel 按代码中实际用到的 ES6 API 去按需引入 polyfill而不是把整个 core-js 打包进来这直接关系到最终 bundle 体积。transform-runtime用于提取辅助函数避免每个模块都重复生成一份_asyncToGenerator之类的代码。要注意的是presets 的顺序是逆序执行stage-2 会先处理提案阶段的语法env 再处理标准语法。提示如果你把这个项目搬到自己的电脑上运行Node 版本超过 14 后老版本 babel-loader 可能会报内存溢出或编译缓存校验失败。常见做法是把 babel-loader 升级到 8.x同时把 babel-preset-env 替换为 babel/preset-env。2.4 package.json 与 package-lock.json 的依赖分工源码包里同时出现了 package.json 和 package-lock.json。前者声明的是项目“允许的版本范围”后者锁死的是“当前安装的具体版本”。很多新手会忽略 lock 文件的作用其实团队协作时的绝大多数“我本地能跑你那边跑不起来”问题都源于 lock 文件没有提交或手动删除了。npm install # 按 lock 文件精确安装依赖 npm install vue2.6.14 --save # 运行时依赖 npm install webpack^3.12.0 --save-dev # 构建期依赖注意区分dependencies和devDependencies的边界像 vue、vue-router、axios 这类运行时需要的库放 dependencieswebpack、babel-loader、vue-loader 这些只在构建时用到的工具放 devDependencies。如果分错生产环境执行npm install --production时会缺少构建期工具部署流水线会直接崩。这个项目的 package.json 里排序逻辑是清晰的业务代码和构建工具分开列照着这个习惯维护即可。3. 业务装配路由、页面组件与请求层怎么协同3.1 src 目录下的模块各管一摊别在 pages 里写请求src 目录的文件分配是这个项目最值得借鉴的部分constant/data.js 放静态数据和枚举常量api 目录统一放接口请求utils/request.js 做 axios 实例封装pages 目录只关心组件渲染和用户交互。这样的分层让“数据从哪来”和“界面长什么样”彻底解耦。实际开发里常见的坏味道是页面组件里直接写死一份axios.get(/api/•••)换接口地址时满项目 grep。合理的协作方式是页面组件只调用 API 层暴露的函数函数内部再去拼 URL 和处理返回数据。以会议室预定最常见的两个动作来演示这个链路。先看 utils/request.js 的常见封装模式import axios from axios import { Message } from element-ui // 创建独立实例而不是直接用全局 axios const service axios.create({ baseURL: process.env.VUE_APP_BASE_API || /api, timeout: 8000 }) // 请求拦截器统一携带 token service.interceptors.request.use(config { const token localStorage.getItem(token) if (token) { config.headers[Authorization] Bearer token } return config }, error Promise.reject(error)) // 响应拦截器统一剥离 data 层 service.interceptors.response.use(response { const res response.data if (res.code ! 200) { Message.error(res.message || 请求失败) return Promise.reject(new Error(res.message)) } return res.data }, error { Message.error(error.message || 网络异常) return Promise.reject(error) }) export default service这段封装的核心价值在于两个拦截器请求拦截器把 token 注入统一收口响应拦截器把后端返回的{ code, message, data }结构剥离成业务数据。各模块 API 文件里就不需要重复处理这些逻辑。需要注意baseURL如果配置成/api配合 config/index.js 里的 proxyTable 才能完成开发环境的跨域转发。api/user.js 对外暴露预定相关的具体方法照常规套路大概长这样import request from /utils/request export function bookRoom(data) { return request({ url: /meeting/book, method: post, data }) } export function cancelBook(id) { return request({ url: /meeting/book/${id}, method: delete }) } export function fetchMeetingList(params) { return request({ url: /meeting/list, method: get, params }) }请求函数的参数设计遵循“业务名 接口描述”的命名习惯调用方读到函数名就知道是什么操作。fetchMeetingList里的params用 get 方式传参bookRoom 用data字段对应 post body这是 axios 里最容易混淆的一对配置。用 REST 风格组织资源路径预定、取消、查询三种语义用不同 HTTP 方法区分后端接口也方便统一规范。3.2 router 配置文件驱动的页面结构与懒加载pages 目录下有组件、HelloWorld.vue 作为占位页说明这个工程并没有塞满业务页面更多是留给使用者扩展。router/index.js 里通常用路由懒加载控制代码分割。预定系统的页面规模不大但仍建议用懒加载原因是 webpack 会把每个异步路由块单独打包成一个 chunk首屏只加载当前路由对应代码会议室列表页和预定表单页分离之后进入表单页不需要重新下载列表页的组件代码。import Vue from vue import Router from vue-router Vue.use(Router) // 懒加载模式每个路由独立打包成 chunk const MeetingRoomList () import(/pages/MeetingRoomList) const BookingForm () import(/pages/BookingForm) export default new Router({ mode: hash, routes: [ { path: /, redirect: /rooms }, { path: /rooms, name: MeetingRoomList, component: MeetingRoomList }, { path: /book/:id, name: BookingForm, component: BookingForm } ] })路由的mode选择 hash 还是 history 直接影响部署策略。这个工程默认用 hash 模式URL 会出现#好处是刷新页面不会 404任何静态服务器都能直接托管。如果改成 history 模式Nginx 需要额外配置 try_files 回退到 index.html。会议室预定系统常常内嵌在企业 OA 里hash 模式防刷新丢失更省心。redirect字段把根路径指到会议室列表页避免用户访问/时白屏。3.3 预定与取消的两个核心函数套路从源码包的 JS 数量看业务逻辑集中在少数几个文件里。参考这类系统的通用设计预定和取消通常各对应一个页面方法且在操作前需要二次确认。预订表单提交的核心逻辑大致如下methods: { async handleSubmit() { // 校验时间段是否合法 if (!this.selectedRoom || !this.timeRange) { this.$message.warning(请选择会议室和时间段) return } const [start, end] this.timeRange if (new Date(start).getTime() new Date(end).getTime()) { this.$message.error(结束时间必须晚于开始时间) return } this.submitting true try { await bookRoom({ roomId: this.selectedRoom.id, startTime: Date.parse(start), endTime: Date.parse(end), attendee: this.currentUser, subject: this.subject }) this.$message.success(预定成功) this.$router.push(/rooms) } catch (err) { this.$message.error(err.message || 预定失败) } finally { this.submitting false } } }这个方法完成了“前端校验 → 提交 → 成功跳转/失败反馈”的完整闭环。把时间比较的布尔运算直接放在if条件里逻辑清晰且不依赖任何第三方库。finally块里重置 submitting 状态避免请求期间用户连续点击产生重复预订单。如果你的项目有多个表单、多个提交入口把这个“提交锁 反馈 跳转”抽成一个 composable 或者 mixin代码维护成本会低很多。取消预定的核心逻辑是把资源释放还给会议室实战中还涉及权限边界——只能取消自己创建的预定async handleCancel(booking) { if (booking.bookedBy ! this.currentUser) { this.$message.warning(只能取消本人名下的预定) return } const confirmed await this.$confirm( 确定取消 ${booking.roomName} 的预定吗, 取消确认 ).catch(() false) if (!confirmed) return const res await cancelBook(booking.id) if (res) { this.$message.success(已取消预定) this.refreshList() } }把.catch(() false)直接挂在this.$confirm后面是一种处理“弹窗取消”的简洁方式用户点“取消”按钮时 Promise 会 reject此时把返回值归一化为 false后续判断只有确认时才会执行取消逻辑。这里刻意没有给 cancelBook 加 try/catch因为响应拦截器已经统一处理了错误提示业务层只需关注成功分支。4. 数据联调从静态 data.js 到代理转发与生产部署4.1 constant/data.js 承担的角色本地兜底与枚举字典会议室预定系统在没有后端联调时最直接的做法是把会议室列表、时间段选项写在 constant/data.js 里。它在这个源码包里的定位是一个“静态数据字典”既承担初始化数据的兜底也承载业务上的枚举本。// 会议室基础数据 export const ROOM_LIST [ { id: 1, name: A201 · 大会议室, capacity: 20, equipment: [投影, 白板] }, { id: 2, name: A305 · 洽谈室, capacity: 8, equipment: [电视] }, { id: 3, name: B612 · 电话亭, capacity: 2, equipment: [电话] } ] // 时间段选项用于表单的 el-select export const SLOT_OPTIONS [ { label: 09:00 - 10:00, value: 0 }, { label: 10:00 - 11:00, value: 1 }, { label: 14:00 - 15:00, value: 2 } ]页面里读取这份数据时要注意一个问题直接import会得到同一个数组引用。如果业务代码里去 push 或 splice 这个数组所有引用该模块的组件都会受影响。常见做法是读取时做一层浅拷贝const rooms [...ROOM_LIST]或者加一个工厂函数返回新数组。对于这个工程来说data.js 更适合作为“接口联调前的默认值”而不是运行时的数据源——把静态数据写进业务组件前先问自己一句将来接口返回的数据结构和这份本地数据一致吗4.2 开发环境跨域config/index.js 里的 proxyTable本地开发时前端跑在 8080 端口后端接口跑在 8088 端口直接 axios 请求必然遇跨域。这个工程如果预留了 proxyTable 配置开发体验会顺畅很多。在 config/index.js 的 dev 节点中常见配置如下dev: { env: require(./dev.env), port: 8080, autoOpenBrowser: true, proxyTable: { /api: { target: http://localhost:8088, changeOrigin: true, pathRewrite: { ^/api: } } } }proxyTable 的匹配规则是所有以/api开头的请求都被转发到 target 指定的后端地址。changeOrigin: true会把请求头里的 Host 字段伪装成 target 的域名避免后端做域名白名单校验时拦截。pathRewrite里的^/api把前缀剥掉所以前端请求/api/meeting/list后端实际收到的是/meeting/list。如果你要做多环境联调可以把这个表改成根据环境变量动态选择 target而不是硬编码 localhost。4.3 生产构建与 Nginx 部署的边界处理npm run build执行完后产出的是 dist 目录的静态文件。这里的核心配置点是 publicPath。config/index.js 的 build 节点里有assetsPublicPath: /部署在服务器根路径没问题如果部署在子路径/oa/必须改成./或/oa/否则 js/css 资源加载路径直接 404。server { listen 80; server_name meeting.example.com; root /var/www/dist; index index.html; location / { try_files $uri $uri/ /index.html; } }这个配置的精髓在try_files当用户直接刷新/book/3这个路由时服务器没有对应的物理文件就把请求回退到 index.html再由 Vue Router 接管渲染。如果不用 hash 模式而用 history 模式这段配置就是必选项。上线前还应该检查后端接口是否允许跨域如果是同域部署让 Nginx 同时代理后端接口就能彻底避免跨域问题location /api/ { proxy_pass http://127.0.0.1:8088/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; }提示部署后如果发现样式加载了但 JS 没加载优先检查浏览器 Network 面板里 js 文件的 Response Headers 和实际请求路径99% 是 assetsPublicPath 配置不当。5. 从源码包到可交付系统状态管理与冲突校验升级5.1 把分散的请求收口到 Pinia/Vuex 之前的中间方案这个源码包没有引入 Vuex路由和页面组件直接承载全部逻辑。项目规模一旦超过五六个页面跨页面共享“当前预定用户”“已选会议室”这类状态会变得痛苦。在不引入 Vuex 的前提下可以先做一个轻量的共享 store 文件// src/store.js import Vue from vue export const store Vue.observable({ currentUser: null, pendingBooking: {} }) export const mutations { setCurrentUser(user) { store.currentUser user }, setPendingBooking(booking) { store.pendingBooking booking } }用 Vue.observable 创建一个响应式对象任何组件 import 后修改 mutations 里的方法其他组件都会响应式更新。这个方案适合从静态原型过渡到真实后端联调的中间阶段比直接上 Vuex 轻得多。等出现“预定记录列表页需要同时响应多个组件修改”的需求时再迁移到 Vuex 也不迟。5.2 把时间冲突判断抽成纯函数并配套单测会议室预定系统最容易出严重 bug 的地方是时间段冲突判断。很多人的第一版代码是在组件里写成嵌套循环配合 filter直接操作 DOM 数据。更好的做法是把冲突判断抽成纯函数脱离 Vue 实例独立测试。下面这个函数可以挂在 common/utils 下/** * 判断新预定的时间段是否与已有预定冲突 * param {number} newStart 新预定开始时间戳 * param {number} newEnd 新预定结束时间戳 * param {Array} existList 已有预定列表元素含 startTime/endTime * returns {boolean} true 表示冲突 */ export function hasTimeConflict(newStart, newEnd, existList) { return existList.some(item { const itemStart new Date(item.startTime).getTime() const itemEnd new Date(item.endTime).getTime() // 新时间段开始落在已有区间内 if (newStart itemStart newStart itemEnd) return true // 新时间段结束落在已有区间内 if (newEnd itemStart newEnd itemEnd) return true // 新时间段完全包裹已有区间 if (newStart itemStart newEnd itemEnd) return true return false }) }把这个函数放在组件外意味着可以用 Node 直接跑测试。配合 file 末尾加一段快速验证即可// 快速冒烟测试node src/common/utils.js const list [ { startTime: 2025-01-10 09:00, endTime: 2025-01-10 10:00 } ] console.log(hasTimeConflict( Date.parse(2025-01-10 09:30), Date.parse(2025-01-10 10:30), list )) // true这个纯函数设计的边界条件覆盖了三种典型冲突形态开始时间撞进已有区间、结束时间撞进已有区间、整个时间段把已有预定包住。还有两个边界要额外确认相等结束时间和相等开始时间不冲突因为前一个预定到 10:00 结束新预定从 10:00 开始中间没有重叠但如后端对时间段做闭区间存储这个判断逻辑就反过来需要在联调时明确双方口径。5.3 给构建产物做一次体积观察与依赖审计最后提供一个落地技巧在 package.json 里加一个 build:report 脚本通过 webpack 的 BundleAnalyzer 插件可视化每个模块的体积。老版本 webpack 环境中直接在 webpack.prod.conf.js 里条件加载插件const BundleAnalyzerPlugin require(webpack-bundle-analyzer).BundleAnalyzerPlugin const webpackConfig merge(baseWebpackConfig, { plugins: [ // 生产构建后的体积报告 new BundleAnalyzerPlugin({ analyzerMode: process.env.npm_config_report ? server : disabled }) ] })运行npm run build --report就能在浏览器里打开依赖占比图。这个步骤的价值在于你能一眼看到 element-ui 全量引入占了多大体积、moment.js 这种大库是否应该换 day.js。会议室预定系统的功能虽然简单但把构建体积管住了后续往里面加日历组件、Excel 导出这类功能时才不会动不动把包撑到几兆。对于从这套源码起步的项目先做一次体积审计再继续堆功能比事后再优化要省力得多。本文还有配套的精品资源点击获取