简介这套会议管理系统页面原型资源针对会议组织、管理与参与场景适合产品经理、界面与交互设计师及开发团队在IT系统开发前确认功能布局与交互逻辑降低需求沟通成本与后期返工风险。原型完整覆盖登录注册、会议创建、会议管理、参会人员管理、日程安排、在线交流、会议记录、反馈评价、通知提醒等核心模块并兼顾手机与平板等移动端适配可直接用于需求评审、界面走查、原型教学也可为同类后台产品提供页面设计参考。压缩包共268个文件总体积约766KB其中153个jpg为页面设计截图45个html为可浏览原型页面33个gif为交互动态演示另有css样式、js脚本及db数据文件共同支撑视觉还原与基础交互展示。已有320人学习适合需要快速掌握会议系统原型结构、梳理页面流转关系或开展功能预研的产品与研发从业者参考。1. 管理系统原型不是画图一套能点能跳的页面骨架解决什么问题某次给客户演示后台管理系统对方产品负责人在我们讲完 PPT 后问了一句“能不能让我点一下看看”当时项目还没进入开发只有一堆页面截图。我们团队临时决定先把管理系统原型做成一套能点击、能跳转、能切换角色的页面骨架——从登录页进去左侧菜单可以展开收起表格可以筛选搜索弹窗能打开能关闭不同登录身份看到的菜单和按钮还不一样。客户当场就可以在浏览器里自己点一遍整个确认过程从两轮评审缩短到一次操作演示。这套原型本质上不是一个生产系统而是“页面结构 交互演示 开发蓝图”三者合一的产物。它适合三类人产品经理拿去做需求评审前端新手用它理解后台项目的标准目录和权限模型外包团队则用它给客户做开发前的界面确认。下面我从架构、交互、运行到二次开发把这套原型怎么搭、怎么跑、怎么改讲清楚。2. 原型整体架构九大功能模块与三栏式布局怎么定下来的2.1 功能模块盘点一套后台该有的界面都在这儿了管理系统原型在模块划分上完全按“标准后台”的思路走。我拆解后整理了下面这张清单每个模块都对应一个独立页面或一组页面不是只做一张静态图模块核心页面关键交互点登录与会话登录页登录校验、跳转回原页面仪表盘统计卡片、趋势图、待办列表卡片点击进入对应列表页用户管理用户列表、新增/编辑弹窗搜索、分页、分配角色、启用禁用角色权限角色列表、菜单树授权勾选菜单、勾选按钮权限点菜单管理菜单列表增删改菜单项实时反映到左侧系统配置参数配置、字典管理双列表联动日志审计操作日志、登录日志按时间筛选个人中心修改密码、个人信息表单校验、退出登录每个模块的页面结构几乎共用同一套模板顶部是搜索区中间是数据表格底部是分页器新增和编辑操作统一走弹窗。这样设计的好处是开发和走查都有惯性用户看多了也能猜到下一个页面的操作方式。原型阶段不需要把每个模块都做到像素级还原但模块覆盖面一定要完整因为它承担着和客户确认需求边界的作用。2.2 整体布局与设计规范为什么三栏式布局是后台默认答案这套原型的整体布局采用后台管理系统最经典的三栏结构左侧菜单栏固定 220px顶部 Header 高度 56px中间内容区自适应撑满。页面尺寸以 1440x900 为基准设计同时兼容 1920 宽屏栅格系统用 24 列布局表格页搜索区统一占一整行。设计规范上我刻意做了一些约束避免视觉评审干扰功能评审状态规范列表页必须有加载中、空数据、请求失败三种状态不能只做有数据时的样子按钮规范区分主按钮、次按钮、危险按钮三种类型危险操作统一用红系颜色表单规范弹窗表单宽度统一 550pxlabel 右对齐表单项错误提示统一出现在组件下方表格规范操作列固定右侧金额、时间列有统一对齐规则长文本省略号展示并带悬停提示颜色和字体在原型阶段直接沿用组件库默认值不做品牌定制。这个决定来自一次踩坑某团队早期原型花了大量时间调品牌色结果客户把评审重点全放在“这个蓝色不正”上真正的功能问题反而被忽略了。默认视觉虽然朴素但能逼着双方讨论页面交互和业务流程这才是原型阶段最该确认的事。2.3 目录结构一份原型包内部是怎么组织的这套原型按真实前端工程的标准组织目录不是工具导出的单文件 HTML。拿到压缩包后解压你会看到下面这样的结构src ├── api # 接口层原型阶段全部指向 mock ├── assets # 静态资源 ├── components # 通用组件 │ ├── BackButton # 返回按钮 │ ├── DetailDrawer # 右侧详情抽屉 │ ├── FormDialog # 弹窗表单新增/编辑/详情共用 │ └── SearchForm # 搜索区表单 ├── directives # v-permission 按钮权限指令 ├── layout # 后台主框架布局 ├── mock # mock 接口与模拟数据 ├── router # 路由配置与菜单配置 ├── stores # 用户状态、权限点状态 └── views # 业务页面 ├── dashboard # 仪表盘 ├── login # 登录页 ├── profile # 个人中心 └── system # 系统管理 ├── menu # 菜单管理 ├── role # 角色权限 └── user # 用户管理分层原则是页面只负责渲染和交互数据全部走 api 层api 层在原型阶段被 mock 拦截。router 和 stores 是这套原型能“跳起来”的关键后面讲核心交互时会专门展开。views 目录按业务模块建子目录每个子目录下至少包含 index.vue 和对应的列表/表单组件这也是后续开发阶段可以直接沿用的目录划分。3. 核心交互拆解菜单、路由、权限、表格筛选从进入到返回的完整链路3.1 登录态与路由守卫没登录的人只能停在登录页原型虽然只是演示但登录态和路由守卫是最先要做的交互因为后续所有页面跳转都要依赖“当前是谁”这个状态。路由守卫放在全局钩子里每次路由跳转前先做三层判断。// src/router/guard.js 路由守卫核心逻辑 router.beforeEach((to, from, next) { const token localStorage.getItem(pro-token) const role localStorage.getItem(pro-role) // 第一层没有 token一律踢回登录页 if (!token to.path ! /login) { next({ path: /login, query: { redirect: to.fullPath } }) return } // 第二层已经登录的人不能再回登录页 if (token to.path /login) { next({ path: /dashboard }) return } // 第三层路由配置了 meta.roles 就做角色校验 if (to.meta to.meta.roles !to.meta.roles.includes(role)) { next(/403) return } next() })这段逻辑里最值得注意的参数是query.redirect它记录了用户原本想访问的完整路径。用户被踢到登录页完成登录后可以恢复到跳转前的页面而不是每次都固定进仪表盘。第三层的meta.roles数组在路由配置里定义比如用户管理页配置roles: [admin, operator]那 guest 角色访问就会被送到 403 页面。把角色信息存在 localStorage 是原型阶段的常见做法真正进入开发后要换成服务端下发的会话状态。3.2 菜单与路由联动一份配置同时驱动左侧菜单和页面跳转菜单和路由在管理系统里最容易出现“两边对不上”的问题——菜单里有入口路由表里却没有对应页面。这套原型采用“路由即菜单”的方式菜单配置数组直接挂在路由 meta 上左侧菜单组件遍历路由表生成菜单就永远不会比路由多。// src/router/menu.js 菜单与路由共用配置 export const menuRoutes [ { path: /dashboard, title: 仪表盘, icon: Odometer, roles: [admin, operator, guest] }, { path: /system/user, title: 用户管理, icon: User, roles: [admin, operator] } ]菜单组件拿到这份menuRoutes后做两件事先按当前角色过滤掉无权访问的条目再渲染成左侧可展开的菜单树。点击菜单时触发路由跳转URL 变化后对应页面组件被路由系统加载。这里有个常见误用单独维护一份菜单配置文件和一个路由表文件两边用手工同步导致新增页面时经常漏改菜单。把菜单和路由合并成一份数据后新增一个页面只需要在menuRoutes里加一项路由和菜单同时生效。3.3 按钮级权限角色能进页面不等于能点按钮路由守卫只能控制“能不能进入某个页面”但管理系统的权限粒度通常要细到按钮比如“运营角色能查看用户列表但删除按钮不渲染”。这套原型用自定义指令v-permission做按钮级控制。// src/directives/permission.js 按钮权限指令 app.directive(permission, { mounted(el, binding) { const userStore useUserStore() const points userStore.permissionPoints || [] // binding.value 是权限点字符串例如 user:delete if (!points.includes(binding.value)) { el.parentNode el.parentNode.removeChild(el) } } })使用时在按钮上写v-permissionuser:delete如果当前角色没有user:delete这个权限点按钮直接从 DOM 中移除。移除比 disabled 更彻底因为 disabled 的按钮还留在页面里用户能看到但点不了在演示时容易引发“这个按钮为什么灰着”的追问。权限点字符串统一用模块:动作格式比如user:delete、role:assign角色管理页里勾选菜单权限时按钮权限点跟着一起配置。3.4 表格页标准交互搜索、重置、分页的参数传递套路用户管理页是这套原型里最完整的表格页它把搜索、重置、分页三个动作串在同一个数据流里。核心逻辑在下面这个组合式函数里。// src/views/system/user/index.vue 表格查询参数管理 const queryParams reactive({ keyword: , status: , page: 1, pageSize: 10 }) function handleSearch() { // 搜索条件变化时强制回到第一页避免停在越界页码 queryParams.page 1 loadTable() } function handleReset() { queryParams.keyword queryParams.status queryParams.page 1 loadTable() } function handlePageChange(page) { queryParams.page page loadTable() }loadTable方法从 mock 接口拉取数据请求参数就是queryParams里的四个字段。搜索时必须重置页码这一点是血泪经验如果当前停在第 5 页搜索出的结果只有 2 页表格会直接落到一个空页面上用户第一反应是“系统坏了”。重置逻辑也不只是清空输入框必须连页码一起归位并重新查询否则界面显示的是清空后的条件表格里却还是旧数据。分页事件和查询条件解耦后后续加防抖搜索、加排序参数都很方便。3.5 弹窗表单三态复用新增、编辑、详情用同一个组件弹窗是后台系统里使用频率最高的交互组件这套原型把新增、编辑、详情三种模式收进同一个FormDialog组件里通过mode属性切换行为。// src/components/FormDialog.vue 组件 props 设计 props: { visible: Boolean, mode: { type: String, default: create // create | edit | detail }, row: { type: Object, default: null } }mode为create时表单所有字段可编辑提交时调用新增接口mode为edit时回显当前行数据并调用更新接口mode为detail时所有字段变成 disabled 状态纯展示。这比复制三个弹窗组件省了大量重复代码也保证三个场景的表单字段不会漂移。演示时的关键细节是详情模式必须从视觉上就和编辑状态区分开——所有输入框置灰按钮区只显示“关闭”不显示“确定”。这套原型的每个业务模块都沿用了这个弹窗三态约定走查时看到任何一个表单弹窗都能按这个逻辑去验证。4. 本地跑通与验证从安装依赖到三种角色全流程走查4.1 本地启动装依赖、起服务、开浏览器这套原型基于 Node 环境运行拿到源码后先在根目录安装依赖然后启动开发服务。# 在项目根目录执行 npm install # 启动开发调试服务 npm run dev如果是 Vite 驱动默认端口是 5173启动后终端会打印本地访问地址直接在浏览器打开即可如果基于 webpack 配置默认端口一般是 8080。端口被占用时终端会提示换端口或让你手动指定。进入登录页后mock 层已经内置了三个演示账号不需要任何后端服务。启动完成建议先做一个最基础的冒烟测试用管理员账号登录确认左侧菜单完整展开逐个点击菜单项看页面是否都正常加载。如果哪个路由点开会白屏优先检查路由配置里 path 和组件路径是否一致这是原型阶段最常见的启动问题。4.2 三种角色全流程走查不同身份看到的世界不一样这套原型的权限设计是三套角色admin管理员、operator运营人员、guest访客。它们在菜单和按钮两个维度上都有差异走查时要分别登录验证角色登录账号左侧菜单按钮权限adminadmin / admin123全部菜单全部按钮operatoroperator / operator123仪表盘、用户管理可查询无删除、无导出guestguest / guest123仅仪表盘无任何操作按钮走查建议用浏览器的无痕窗口开两个角色对比同一页面。比如按 guest 登录URL 直接输入/system/user路由守卫应该把请求拦下来送到 403 页用 operator 登录进入用户管理页删除按钮和导出按钮应该完全不渲染。这个验证流程能同时检验路由守卫、菜单过滤、按钮权限指令三条链路是否串通比只看一个页面有效得多。4.3 交付物核对原型不只是页面还有一份走查清单原型包的 docs 目录下放着三份配套文档页面清单pages.md列明所有页面路由和页面职责交互说明interactions.md描述每个模块的交互点和异常状态账号说明accounts.md记录演示账号和对应权限范围。交付前建议对照这份清单完整走一遍“登录 → 仪表盘 → 用户列表 → 新增用户 → 分配角色 → 退出登录”的主流程。这套原型的演示重点不只是“能点”而是状态设计。比如用户列表搜索无结果时要有空数据插画表格加载时要展示骨架屏接口异常时要出现错误提示条——这些状态在真实开发中经常被漏掉在原型阶段补全的成本却最低。客户演示时点不出数据的场景往往比完整流程更容易暴露需求理解偏差。5. 踩坑与排查清单做管理系统原型时最容易翻车的四件事5.1 刷新页面直接白屏原型能点开输 URL 就 404现象通过菜单点击正常跳转但只要手动刷新浏览器或直接输入某个子路由地址页面就白屏或提示 404。原因开发模式下路由用了 history 模式浏览器刷新时会真实请求服务器路径而本地开发服务器没做 history fallback 配置也可能是因为动态路由只在这套原型的初始化流程里注册了一次刷新后动态路由还没注册就执行了跳转。解决开发环境下先切到 hash 模式路由路径会变成/#/形式刷新不会发起路径请求原型演示最稳。等进入正式开发、后端有统一网关时再切回 history 模式并在服务器侧配置所有非静态路径回退到 index.html。排查时先在控制台看路由实例的getRoutes()输出确认刷新后路由表是否完整。5.2 删除按钮全显示出来了路由权限做了按钮权限漏了现象用 operator 账号登录页面能进数据能看但“删除”“导出”按钮一个不少地摆在操作列里看起来和有权限没区别。原因这是权限设计最常见的断层——路由守卫只约束了页面级别的访问但每个页面上的操作按钮没有逐个加v-permission指令默认全部渲染。解决把权限拆成两级先路由级用meta.roles挡页面再按钮级用v-permission挡操作。走查时列一张按钮权限点清单把所有带操作语义的按钮都登记上去逐个核对角色可见性。建议在原型阶段就把权限点命名规范定下来后面接真实权限系统时直接复用这套字符串。5.3 联调时表格突然全空mock 字段和真实接口对不上现象原型里表格数据正常换到真实接口后表头还在但内容全空控制台也没有报错。原因mock 数据的字段命名和真实接口返回不一致。比如原型数据里是userName后端返回的是user_name前端组件按userName取值自然取不到渲染出的就是空表格。解决在 api 层加一个字段映射函数接口返回后先做统一格式化再交给页面组件页面永远只认自己定义的对象结构。这个教训也说明原型里 mock 数据虽然是假的但字段命名要按真实接口的规范来设计否则二次开发时要反工改一堆页面字段。5.4 表格翻到第 5 页刷新后回到第一页分页状态没进 URL现象列表页翻到第 5 页点浏览器刷新表格跳回第 1 页筛选条件也没了。原因页码和关键词都存在组件内部的内存变量里刷新后组件重新创建状态自然清空。演示时客户如果正在核对第 5 页的数据刷新后再翻回去非常尴尬。解决把 page、keyword 这类关键查询参数同步到路由的 query 上初始化时从route.query读回。刷新后 URL 里带着?page5keywordxxx组件重新创建后能恢复原有查询条件。这也是原型阶段就值得做的交互细节它直接影响演示时的专业感。6. 二次开发落地把原型工程改写成一个真实前端项目6.1 第一件事把静态菜单和权限点换成接口下发原型里菜单和权限点都是写死的静态配置二次开发时第一步就是把它们动态化。登录成功后请求/user/menus拿到当前角色的菜单树再调用router.addRoute动态注册权限点则存入全局 store。// src/api/user.js 二次开发时接口动态化 async function loadUserContext() { const { data } await api.getUserInfo() // 用户信息与权限点 const menus await api.getMenusByRole(data.role) // 菜单树 menus.forEach(route router.addRoute(route)) // 动态注册路由 userStore.setPermissionPoints(data.points) }动态路由接入时有一个隐藏坑退出登录再换账号登录路由表里还残留上一个账号的动态路由二次注册会报 duplicate 警告。正确做法是退出登录时用router.removeRoute按名字逐个移除或者维护一个动态路由名单统一清理。这一改动完成原型就具备了接入真实后端权限系统的能力。6.2 第二件事按页面模块拆组件别让一个文件超过 500 行原型里用户管理页还能控制在一个文件里接真实接口后逻辑会快速膨胀。二次开发时把表格列配置、搜索表单、弹窗表单从页面里抽出来每个模块一个目录页面只负责组装。// src/views/system/user/index.vue 抽离后的组装模式 template SearchForm :fieldssearchFields searchhandleSearch / DataTable :columnscolumns :datalist editopenEdit / FormDialog v-modeldialog.visible :modedialog.mode :rowdialog.row / /template这个阶段还要把 mock 的随机延迟去掉加上统一的请求错误处理。原型阶段假数据随便返、随便报错都行真实接口必须考虑 loading 态、超时重试、401 跳登录这些生产环境才会暴露的场景。6.3 保留原型里的三样东西目录分层、权限点规范、弹窗三态约定以我个人的经验原型的页面代码最终都会被推翻重写但三样东西值得原样保留一是api / views / components / stores的目录分层它让前后端协作的边界从一开始就清晰二是模块:动作的权限点命名规范后面接权限中台只管扩展字符串不用改校验逻辑三是弹窗 create / edit / detail 三态共用的交互约定团队新成员看了三个模块就能照着写第四个。这套管理原型后来被我们用在了另一条业务线的需求预演上产品那边拿着它给客户讲流程开发这边直接沿着骨架铺代码。从那以后我每次接手后台项目无论工期多紧都会先花半天把一套可点击的管理系统原型跑起来——用不同角色各走一遍完整链路确认哪些是真交互、哪些只是示意再开始动代码。这个习惯帮我避开了好几次因为需求理解偏差导致的大改。希望帮到你。本文还有配套的精品资源点击获取