简介一份基于Vue的差旅服务OTA系统前端源码包面向需要搭建在线差旅预订与管理平台的前端工程师、毕业设计学生及对完整业务系统感兴趣的学习者适合具备Vue基础并希望深入理解模块化开发思路的中高级人员。资源共包含121个文件压缩包整体仅3.66MB体量适中便于下载与本地运行调试。从文件构成看包含43个Vue单文件组件、38个JavaScript脚本、31个PNG图标以及JSON、HTML、EditorConfig、Development与Production等配置类文件其中Vue组件负责页面结构与交互更新JavaScript脚本承担接口调用、数据流转与权限控制图片图标提供界面视觉支撑配置文件则用于区分开发和生产环境的工程参数。项目内部覆盖后台管理、用户管理、角色权限、航班信息等典型OTA业务模块目录划分清晰利于快速定位关键代码并进行二次改造。目前已有307人学习下载既可用于课程设计与项目实训也可作为学习Vue工程化组织、组件通信和复杂业务实现的参考案例帮助读者高效掌握差旅服务系统的前端落地方法。1. 差旅OTA系统的前端难在状态和边界做过企业差旅后台的人都知道这类系统表面上是机票酒店搜索下单实际是把差旅政策、审批流、多供应商比价、费用归属全部压在前端交互里。一个Vue页面要让员工快速完成行程预订同时不违反企业成本标准还得让审批人一眼看清超标原因。很多团队把精力花在组件样式上最后发现订单状态错乱、重复请求和大列表卡顿才是真正耗时的部分。我这次围绕“基于Vue的差旅服务OTA系统设计源码”按实际工程落地顺序讲清楚Vue在OTA系统里怎么搭架构、管状态、封装请求、处理业务边界。适合正在写企业级Vue应用的前端开发也适合需要理解前端如何支撑差旅审批流程的后端和产品同学。不讲花哨的UI只讲能复制过去改的业务代码。2. 差旅OTA系统的领域模型与前端模块划分2.1 差旅业务的对象关系行程、订单、政策、费用在做前端之前先把业务对象理清。差旅系统里最常见的关系是员工发起一次出差申请申请里包含多段行程行程下面挂具体的航班或酒店订单。企业差旅政策约束着行程的选择而费用归属决定这笔订单计入哪个成本中心。前端的模块划分如果不跟着这些对象走后面加需求就会到处打补丁。领域对象关键字段前端责任出差申请出差人、起止日期、目的地、审批状态表单校验、行程列表、状态展示行程出发地、到达地、日期、舱位等级搜索条件构建、多段行程联动政策职级、可订舱位、酒店价格上限、是否允许自选规则校验、超标提示订单产品类型、供应商、金额、支付状态下单提交、退款/改签入口费用归属成本中心、预算项目、备注表单联动、提交前校验前端真正要管住的是这些对象之间的组合关系。比如一线员工选了头等舱政策引擎会返回超标信息页面需要立刻展示“超出标准320元”并允许他填写超标原因。这个交互不是简单的表单校验它要求前端持有当前职级和目的地再把政策规则拉下来做本地计算。所以Vue目录不能按“页面”划分要按“业务能力”划分。2.2 按feature划分的Vue工程目录我见过太多OTA前端项目把所有组件塞进components目录结果组件文件名全是OrderList.vue这种看不出业务归属的命名。差旅系统应该按功能域建模块常见做法是src/modules下面放trip、approval、policy、finance每个模块自带组件、store和路由配置。src/ modules/ auth/ store/ # 登录态与角色 views/LoginView.vue trip/ store/ # 查询条件、行程状态 components/ # 航班筛选、酒店日历 services/ # 请求API views/TripSearchView.vue approval/ store/ # 审批流状态 views/ApprovalDetailView.vue policy/ store/ # 政策缓存 components/PolicyChecker.vue finance/ views/CostCenterView.vue shared/ components/ # 通用UI组件 utils/date.js router/ index.js每个模块的store只管理自己的领域对象模块之间通过路由参数和service层传数据。比如trip模块的行程准备提交时把行程数据写到订单模块的store里而不是让TripSearchView直接拿approval的数据。这样做的好处是当差旅政策调整时只需要动policy模块不会牵扯到页面组件。2.3 状态驱动的订单流转差旅订单的状态不是单纯的下单成功或失败而是经过“待提交、政策合规、待审批、审批通过、出票中、完成”等阶段。前端不能只在按钮上做判断而要用状态机驱动。Vue里我一般用Pinia的action作为推进状态变化的唯一入口视图层不直接修改订单字段。例如审批拒绝时store会把订单状态改成“已驳回”同时把驳回原因写进审计列表前端各个页面因为这个状态变化自动更新徽标和按钮权限。这种设计最大的收益是排错容易。用户反馈“明明审批通过了名单里还显示待审批”我先看store里的状态流转日志而不是逐个点页面。下一章就按这个思路从工程搭建到路由和store把差旅预约主流程跑通。3. 用Vue Router和Pinia落地差旅预约主流程3.1 Vite Vue3 工程搭建与依赖安装差旅OTA这类后台系统追求的是开发效率和按需构建所以我选择Vite Vue3的script setup写法。新工程可以直接用create命令生成注意要选vue模板而不是vue-ts除非团队已经统一TypeScript。Vite在依赖预构建阶段会自动处理vue核心依赖但我们还要额外安装vue-router和pinia。npm create vitelatest travel-ota -- --template vue cd travel-ota npm install npm install vue-router4 pinia安装完成后检查package.json里vue-router版本是否大于4.0这是Vue3对应的路由库。pinia要新的2.x版本1.x只能配Vue2。跑npm run dev之前先确认node_modules里没有残留旧包遇到vite版本和插件冲突时我一般会删掉node_modules和package-lock.json重新安装这能解决绝大多数vue安装依赖的玄学问题。3.2 路由守卫与差旅审批角色控制差旅系统至少有三种角色普通员工、部门审批人、差旅管理员。页面访问权限不只是登录态拦截还要看当前用户有没有对应模块的权限。路由守卫里不应该写死角色名而是从用户store里取“能力列表”。// router/index.js import { createRouter, createWebHistory } from vue-router const router createRouter({ history: createWebHistory(import.meta.env.BASE_URL), routes: [ { path: /trip/search, name: trip-search, component: () import(../modules/trip/views/TripSearchView.vue) }, { path: /approval/:taskId, name: approval-detail, component: () import(../modules/approval/views/ApprovalDetailView.vue), meta: { requiresApproval: true } } ] }) router.beforeEach((to) { const authStore useAuthStore() if (to.meta.requiresApproval !authStore.canApprove) { return { name: forbidden } } })上面的路由配置里审批详情页通过meta.requiresApproval标记权限。beforeEach中调用useAuthStore()时不要在组件外直接使用要确保store实例已经被Pinia初始化。实际项目中我还遇到过vue路由参数在刷新后丢失的问题解决方法是把审批任务ID留在query上而不是只存在组件state里。3.3 Pinia中的查询与购物车状态差旅搜索页的筛选条件非常多出发城市、到达城市、日期、舱位、航空公司。这些条件如果每个组件维护一份切换Tab时会丢。我统一放进tripStore并且对航班查询做“按条件缓存”和“请求去重”。3.3.1 航班搜索的请求去重与缓存用户拖动日期滑块时会疯狂触发搜索接口后端如果扛不住前端要做防抖和缓存。用一个简单的对象作为缓存keykey由departure arrival date cabin拼成请求在途时返回同一个Promise避免重复发送。// modules/trip/store/tripStore.js import { defineStore } from pinia const cacheMap new Map() const pendingMap new Map() function searchKey(query) { return [flight, query.departure, query.arrival, query.date, query.cabin].join(-) } export const useTripStore defineStore(trip, { state: () ({ query: { departure: BJS, arrival: SHA, date: 2025-06-18, cabin: Y }, flightList: [] }), actions: { async searchFlights(query) { const key searchKey(query) if (cacheMap.has(key)) { this.flightList cacheMap.get(key) return this.flightList } if (pendingMap.has(key)) { return pendingMap.get(key) } const request fetchFlightList(query).then(data { cacheMap.set(key, data) this.flightList data return data }).finally(() { pendingMap.delete(key) }) pendingMap.set(key, request) return request } } })搜索参数里cabin字段是舱位代码Y代表经济舱。缓存Map只保存最后一次结果避免内存无限增长pendingMap用于防止连续点击产生重复请求。在组件里调用时不需要关心请求是否已经返回直接await store.searchFlights(store.query)界面所有关心flightList的地方都会自动更新。3.3.2 订单状态机订单状态我用一个只读的状态表定义没有用复杂的状态机库。原因是在差旅场景里状态迁移是直线型但每个状态会附带不同操作。状态表能同时驱动按钮显示和操作日志。状态可执行操作对应后端动作DRAFT提交审批submitApprovalPENDING_APPROVAL撤回cancelApprovalAPPROVED去下单createOrderTICKETING无轮询出票COMPLETED下载行程单getInvoiceREJECTED重新编辑editDraftPinia的action里写状态迁移时我总是先校验当前状态是否允许跳转比如APPROVED状态下点击“撤回”必须被禁用。前端要做双保险按钮v-if控制显示action里也要判断防止用户用浏览器控制台调方法。4. 封装OTA系统的API层与政策组件4.1 请求层设计统一响应、取消重复请求差旅OTA对接多家供应商后端返回的响应格式可能不一致但前端必须统一。我在shared/services/request.js里用axios做封装core逻辑包括统一时间格式化、错误码映射和取消重复请求。错误码不只是HTTP状态码业务错误码如POLICY_ERROR需要走单独提示。// shared/services/request.js import axios from axios const http axios.create({ baseURL: import.meta.env.VITE_API_BASE, timeout: 15000 }) http.interceptors.request.use(config { const authStore useAuthStore() config.headers.Authorization Bearer ${authStore.token} return config }) http.interceptors.response.use( response { const { code, data } response.data if (code 0) return data if (code 1001) { // token过期跳转登录 window.location.href /login return Promise.reject(new Error(登录过期)) } return Promise.reject(new Error(data?.message || 业务错误)) }, error { return Promise.reject(error) } )拦截器里把response.data的code字段作为业务状态判断0代表成功。注意不要在拦截器里直接跳转路由因为这里没有router实例直接window.location虽然粗暴但在token失效时最可靠。请求层还需要支持取消重复操作尤其是机票提交这种用户喜欢连点按钮的场景后面可结合组件统一处理。4.2 差旅政策校验组件政策校验组件是OTA系统里最值得抽出来的业务组件。例如航班预订时需要根据当前员工职级算出可预订最高舱位并展示超标金额。我把校验逻辑放在一个纯函数模块组件只负责显示结果这样页面和store都能复用。// modules/policy/components/PolicyChecker.vue script setup import { computed } from vue const props defineProps({ policy: { type: Object, required: true }, selected: { type: Object, required: true } }) const exceedAmount computed(() { if (!props.policy.priceLimit) return 0 const diff props.selected.price - props.policy.priceLimit return diff 0 ? diff : 0 }) /script template div classpolicy-checker span v-ifexceedAmount 0 classexceed-msg 超出标准 {{ exceedAmount }} 元 /span span v-else classok-msg符合差旅标准/span /div /templatepolicy对象由后端在登录时下发或按目的地动态加载。组件内只做展示不负责请求因为政策是一个全局性数据多个组件共享。实际中超标时还需要弹出文本输入框让用户填写原因我把这个逻辑拆成了PolicyExceedDialog由父组件控制弹窗避免PolicyChecker越来越臃肿。4.3 高频交互组件虚拟滚动日历差旅搜索页的日历要展示低价提醒一次性渲染两三个月的日期会造成卡顿。用虚拟滚动是在Vue列表性能优化里最直接有效的方案。常见做法是用vueuse/core的useVirtualList或者自己按可视高度计算渲染数量。我倾向于用插件因为它已经把滚动位置和缓存处理好了。import { useVirtualList } from vueuse/core const { list, containerProps, wrapperProps } useVirtualList( dateItems, { itemHeight: 44, overscan: 6 } )这里的overscan是额外渲染的行数设为6可以防止快速滚动时出现白屏。虚拟滚动的关键是itemHeight必须固定如果日期格子高度不固定需要先测量第一个元素的实际高度再赋值。差旅日历通常有一个“价格”和一个“星期几”高度可以固定为44px这属于可以优化的前提。5. 差旅业务中的特殊场景处理5.1 多平台比价结果的排序与聚合差旅OTA的典型场景是同一航班在多个供应商出价不同后端可能返回长列表也可能要求前端合并。我习惯在后端做聚合但前端也要处理展示逻辑。如果后端返回的列表里出现同一航班号、不同价格的多条记录前端要按“起飞时间 最低价”规则去重。排序时不要直接用字符串比较价格而要把机票价格扣除税费后的净价做数值比较。function dedupeFlightList(list) { const map new Map() list.forEach(item { const key item.flightNo item.departureDate const prev map.get(key) if (!prev || Number(item.netPrice) Number(prev.netPrice)) { map.set(key, item) } }) return Array.from(map.values()) }netPrice是机票净价不含机建燃油费用于内部比较展示时用totalPrice。这个函数要放在纯工具模块里因为搜索结果列表和收藏夹都可能用。如果后端已经返回了排序前端再做一次去重需要把去重后的顺序保持后端的“推荐”语义所以去重时要保留第一个出现的顺序而不是重排。5.2 审批流与Vue动态表单审批详情页显示的字段会根据当前审批节点变化比如部门审批人需要看到成本中心财务审批人需要看到超标原因。Vue里做动态表单关键在于把表单配置数据和字段组件解耦。我用一个schema数组描述每个字段的类型、校验规则和可见条件然后遍历渲染。const schema [ { field: reason, label: 超标原因, type: textarea, required: true }, { field: costCenter, label: 成本中心, type: select, required: false }, { field: budgetCode, label: 预算代码, type: input, required: true } ]渲染时用component :is切换字段组件required属性映射到VeeValidate的校验规则。如果某些字段只在某个审批节点显示就在schema里加visibleWhen回调函数。这个方案的缺点是schema会变得复杂因此我规定每个schema对象只能引用shared/validators里的规则不允许内联正则方便测试。5.3 金额精度与费率换算差旅订单涉及多币种和退改费率前端计算金额时必须用整数做单位和差值。比如机票总价是1500.50元后端返回单位是分前端展示时再做换算运算过程中永远不出现小数。退改费率更复杂常见的是“起飞前24小时免费起飞前4小时收取10%”。前端只做展示和简易试算真正的费率计算必须以后端为准。字段单位示例totalPrice分150050refundFee分15005currencyISO码CNY前端在做试算时把费率百分比转成小数再用整数价格乘以百分比。注意Math.round的行为对于0.5这样的小数会向上取整但银行家舍入法可能更符合财务规则差旅系统建议让后端返回已经舍入好的费用前端不要重复计算。6. 构建配置、布局异常排查与性能验证6.1 Vite按需加载与组件库引入OTA系统往往引用了完整UI组件库但很多页面只用其中几个组件。直接用全量引入会让打包后chunk-vendor非常大。Vite生态里使用unplugin-vue-components实现按需加载配合ElementPlus的自动导入。还要注意把vite.config.js里的构建目标设为es2020这样可以减少代码转换带来的体积增长。// vite.config.js import { defineConfig } from vite import vue from vitejs/plugin-vue import AutoImport from unplugin-auto-import/vite import Components from unplugin-vue-components/vite import { ElementPlusResolver } from unplugin-vue-components/resolvers export default defineConfig({ plugins: [ vue(), AutoImport({ resolvers: [ElementPlusResolver()] }), Components({ resolvers: [ElementPlusResolver()] }) ], build: { target: es2020, chunkSizeWarningLimit: 600 } })自动导入的副作用是模板中el-button这种自定义标签不会被IDE识别第一次看代码会觉得是魔法。团队里新成员容易困惑所以我在项目README里写明了自动导入规则并要求在components.d.ts中保存声明文件。chunkSizeWarningLimit只是把超过体积的提示阈值调高真正解体积要看下一条。6.2 vue打包后布局异常的检查清单Vue项目打包后布局异常是个高频问题根因往往是样式作用域、静态资源路径或CDN缓存。下面这张表是我在交付前必然过一遍的检查清单每一项都对应真实踩过的坑。现象可能原因处理方式字体图标打包后没显示字体文件路径是绝对路径/base: ./用相对路径二级路由刷新404history路由未配fallbackNginx配置try_files样式丢失或覆盖顺序错CSS选择器优先级和加载顺序变化组件样式加scoped避免全局修改首屏白屏加载的js chunk太大或CDN过期按路由拆分动态导入清CDN缓存布局异常最常见的是public目录里图片资源用了/images/...打包后如果部署在子路径就会找不到。统一改成相对路径或者在运行时拼接import.meta.env.BASE_URL。如果是element-plus样式丢失优先检查是否手动引入了全量主题包。6.3 用路由级代码分割验证性能验证性能提升最直接的方法是把路由组件改成动态导入。Vite在构建时会把每个动态导入的路由组件单独打包成chunk。我用npm run build后查看dist/assets下是否生成多个js文件如果只有一个大文件说明路由没有生效。const TripSearchView () import(../modules/trip/views/TripSearchView.vue)改完以后用浏览器的Network面板模拟Slow 3G观察首次加载完成时间。OTA系统的用户通常在出差路上用企业Wi-Fi网络质量并不稳定所以我会把首屏限制在核心模块登录和搜索审批、政策管理这些低频模块都放到二级路由里懒加载。最后再配合vite-plugin-compression开启gzip整体压缩率能到70%。这些操作都完成才算把Vue工程真正调到可交付状态。本文还有配套的精品资源点击获取 基于Vue的差旅OTA系统设计与实现：状态管理与性能优化实践
简介一份基于Vue的差旅服务OTA系统前端源码包面向需要搭建在线差旅预订与管理平台的前端工程师、毕业设计学生及对完整业务系统感兴趣的学习者适合具备Vue基础并希望深入理解模块化开发思路的中高级人员。资源共包含121个文件压缩包整体仅3.66MB体量适中便于下载与本地运行调试。从文件构成看包含43个Vue单文件组件、38个JavaScript脚本、31个PNG图标以及JSON、HTML、EditorConfig、Development与Production等配置类文件其中Vue组件负责页面结构与交互更新JavaScript脚本承担接口调用、数据流转与权限控制图片图标提供界面视觉支撑配置文件则用于区分开发和生产环境的工程参数。项目内部覆盖后台管理、用户管理、角色权限、航班信息等典型OTA业务模块目录划分清晰利于快速定位关键代码并进行二次改造。目前已有307人学习下载既可用于课程设计与项目实训也可作为学习Vue工程化组织、组件通信和复杂业务实现的参考案例帮助读者高效掌握差旅服务系统的前端落地方法。1. 差旅OTA系统的前端难在状态和边界做过企业差旅后台的人都知道这类系统表面上是机票酒店搜索下单实际是把差旅政策、审批流、多供应商比价、费用归属全部压在前端交互里。一个Vue页面要让员工快速完成行程预订同时不违反企业成本标准还得让审批人一眼看清超标原因。很多团队把精力花在组件样式上最后发现订单状态错乱、重复请求和大列表卡顿才是真正耗时的部分。我这次围绕“基于Vue的差旅服务OTA系统设计源码”按实际工程落地顺序讲清楚Vue在OTA系统里怎么搭架构、管状态、封装请求、处理业务边界。适合正在写企业级Vue应用的前端开发也适合需要理解前端如何支撑差旅审批流程的后端和产品同学。不讲花哨的UI只讲能复制过去改的业务代码。2. 差旅OTA系统的领域模型与前端模块划分2.1 差旅业务的对象关系行程、订单、政策、费用在做前端之前先把业务对象理清。差旅系统里最常见的关系是员工发起一次出差申请申请里包含多段行程行程下面挂具体的航班或酒店订单。企业差旅政策约束着行程的选择而费用归属决定这笔订单计入哪个成本中心。前端的模块划分如果不跟着这些对象走后面加需求就会到处打补丁。领域对象关键字段前端责任出差申请出差人、起止日期、目的地、审批状态表单校验、行程列表、状态展示行程出发地、到达地、日期、舱位等级搜索条件构建、多段行程联动政策职级、可订舱位、酒店价格上限、是否允许自选规则校验、超标提示订单产品类型、供应商、金额、支付状态下单提交、退款/改签入口费用归属成本中心、预算项目、备注表单联动、提交前校验前端真正要管住的是这些对象之间的组合关系。比如一线员工选了头等舱政策引擎会返回超标信息页面需要立刻展示“超出标准320元”并允许他填写超标原因。这个交互不是简单的表单校验它要求前端持有当前职级和目的地再把政策规则拉下来做本地计算。所以Vue目录不能按“页面”划分要按“业务能力”划分。2.2 按feature划分的Vue工程目录我见过太多OTA前端项目把所有组件塞进components目录结果组件文件名全是OrderList.vue这种看不出业务归属的命名。差旅系统应该按功能域建模块常见做法是src/modules下面放trip、approval、policy、finance每个模块自带组件、store和路由配置。src/ modules/ auth/ store/ # 登录态与角色 views/LoginView.vue trip/ store/ # 查询条件、行程状态 components/ # 航班筛选、酒店日历 services/ # 请求API views/TripSearchView.vue approval/ store/ # 审批流状态 views/ApprovalDetailView.vue policy/ store/ # 政策缓存 components/PolicyChecker.vue finance/ views/CostCenterView.vue shared/ components/ # 通用UI组件 utils/date.js router/ index.js每个模块的store只管理自己的领域对象模块之间通过路由参数和service层传数据。比如trip模块的行程准备提交时把行程数据写到订单模块的store里而不是让TripSearchView直接拿approval的数据。这样做的好处是当差旅政策调整时只需要动policy模块不会牵扯到页面组件。2.3 状态驱动的订单流转差旅订单的状态不是单纯的下单成功或失败而是经过“待提交、政策合规、待审批、审批通过、出票中、完成”等阶段。前端不能只在按钮上做判断而要用状态机驱动。Vue里我一般用Pinia的action作为推进状态变化的唯一入口视图层不直接修改订单字段。例如审批拒绝时store会把订单状态改成“已驳回”同时把驳回原因写进审计列表前端各个页面因为这个状态变化自动更新徽标和按钮权限。这种设计最大的收益是排错容易。用户反馈“明明审批通过了名单里还显示待审批”我先看store里的状态流转日志而不是逐个点页面。下一章就按这个思路从工程搭建到路由和store把差旅预约主流程跑通。3. 用Vue Router和Pinia落地差旅预约主流程3.1 Vite Vue3 工程搭建与依赖安装差旅OTA这类后台系统追求的是开发效率和按需构建所以我选择Vite Vue3的script setup写法。新工程可以直接用create命令生成注意要选vue模板而不是vue-ts除非团队已经统一TypeScript。Vite在依赖预构建阶段会自动处理vue核心依赖但我们还要额外安装vue-router和pinia。npm create vitelatest travel-ota -- --template vue cd travel-ota npm install npm install vue-router4 pinia安装完成后检查package.json里vue-router版本是否大于4.0这是Vue3对应的路由库。pinia要新的2.x版本1.x只能配Vue2。跑npm run dev之前先确认node_modules里没有残留旧包遇到vite版本和插件冲突时我一般会删掉node_modules和package-lock.json重新安装这能解决绝大多数vue安装依赖的玄学问题。3.2 路由守卫与差旅审批角色控制差旅系统至少有三种角色普通员工、部门审批人、差旅管理员。页面访问权限不只是登录态拦截还要看当前用户有没有对应模块的权限。路由守卫里不应该写死角色名而是从用户store里取“能力列表”。// router/index.js import { createRouter, createWebHistory } from vue-router const router createRouter({ history: createWebHistory(import.meta.env.BASE_URL), routes: [ { path: /trip/search, name: trip-search, component: () import(../modules/trip/views/TripSearchView.vue) }, { path: /approval/:taskId, name: approval-detail, component: () import(../modules/approval/views/ApprovalDetailView.vue), meta: { requiresApproval: true } } ] }) router.beforeEach((to) { const authStore useAuthStore() if (to.meta.requiresApproval !authStore.canApprove) { return { name: forbidden } } })上面的路由配置里审批详情页通过meta.requiresApproval标记权限。beforeEach中调用useAuthStore()时不要在组件外直接使用要确保store实例已经被Pinia初始化。实际项目中我还遇到过vue路由参数在刷新后丢失的问题解决方法是把审批任务ID留在query上而不是只存在组件state里。3.3 Pinia中的查询与购物车状态差旅搜索页的筛选条件非常多出发城市、到达城市、日期、舱位、航空公司。这些条件如果每个组件维护一份切换Tab时会丢。我统一放进tripStore并且对航班查询做“按条件缓存”和“请求去重”。3.3.1 航班搜索的请求去重与缓存用户拖动日期滑块时会疯狂触发搜索接口后端如果扛不住前端要做防抖和缓存。用一个简单的对象作为缓存keykey由departure arrival date cabin拼成请求在途时返回同一个Promise避免重复发送。// modules/trip/store/tripStore.js import { defineStore } from pinia const cacheMap new Map() const pendingMap new Map() function searchKey(query) { return [flight, query.departure, query.arrival, query.date, query.cabin].join(-) } export const useTripStore defineStore(trip, { state: () ({ query: { departure: BJS, arrival: SHA, date: 2025-06-18, cabin: Y }, flightList: [] }), actions: { async searchFlights(query) { const key searchKey(query) if (cacheMap.has(key)) { this.flightList cacheMap.get(key) return this.flightList } if (pendingMap.has(key)) { return pendingMap.get(key) } const request fetchFlightList(query).then(data { cacheMap.set(key, data) this.flightList data return data }).finally(() { pendingMap.delete(key) }) pendingMap.set(key, request) return request } } })搜索参数里cabin字段是舱位代码Y代表经济舱。缓存Map只保存最后一次结果避免内存无限增长pendingMap用于防止连续点击产生重复请求。在组件里调用时不需要关心请求是否已经返回直接await store.searchFlights(store.query)界面所有关心flightList的地方都会自动更新。3.3.2 订单状态机订单状态我用一个只读的状态表定义没有用复杂的状态机库。原因是在差旅场景里状态迁移是直线型但每个状态会附带不同操作。状态表能同时驱动按钮显示和操作日志。状态可执行操作对应后端动作DRAFT提交审批submitApprovalPENDING_APPROVAL撤回cancelApprovalAPPROVED去下单createOrderTICKETING无轮询出票COMPLETED下载行程单getInvoiceREJECTED重新编辑editDraftPinia的action里写状态迁移时我总是先校验当前状态是否允许跳转比如APPROVED状态下点击“撤回”必须被禁用。前端要做双保险按钮v-if控制显示action里也要判断防止用户用浏览器控制台调方法。4. 封装OTA系统的API层与政策组件4.1 请求层设计统一响应、取消重复请求差旅OTA对接多家供应商后端返回的响应格式可能不一致但前端必须统一。我在shared/services/request.js里用axios做封装core逻辑包括统一时间格式化、错误码映射和取消重复请求。错误码不只是HTTP状态码业务错误码如POLICY_ERROR需要走单独提示。// shared/services/request.js import axios from axios const http axios.create({ baseURL: import.meta.env.VITE_API_BASE, timeout: 15000 }) http.interceptors.request.use(config { const authStore useAuthStore() config.headers.Authorization Bearer ${authStore.token} return config }) http.interceptors.response.use( response { const { code, data } response.data if (code 0) return data if (code 1001) { // token过期跳转登录 window.location.href /login return Promise.reject(new Error(登录过期)) } return Promise.reject(new Error(data?.message || 业务错误)) }, error { return Promise.reject(error) } )拦截器里把response.data的code字段作为业务状态判断0代表成功。注意不要在拦截器里直接跳转路由因为这里没有router实例直接window.location虽然粗暴但在token失效时最可靠。请求层还需要支持取消重复操作尤其是机票提交这种用户喜欢连点按钮的场景后面可结合组件统一处理。4.2 差旅政策校验组件政策校验组件是OTA系统里最值得抽出来的业务组件。例如航班预订时需要根据当前员工职级算出可预订最高舱位并展示超标金额。我把校验逻辑放在一个纯函数模块组件只负责显示结果这样页面和store都能复用。// modules/policy/components/PolicyChecker.vue script setup import { computed } from vue const props defineProps({ policy: { type: Object, required: true }, selected: { type: Object, required: true } }) const exceedAmount computed(() { if (!props.policy.priceLimit) return 0 const diff props.selected.price - props.policy.priceLimit return diff 0 ? diff : 0 }) /script template div classpolicy-checker span v-ifexceedAmount 0 classexceed-msg 超出标准 {{ exceedAmount }} 元 /span span v-else classok-msg符合差旅标准/span /div /templatepolicy对象由后端在登录时下发或按目的地动态加载。组件内只做展示不负责请求因为政策是一个全局性数据多个组件共享。实际中超标时还需要弹出文本输入框让用户填写原因我把这个逻辑拆成了PolicyExceedDialog由父组件控制弹窗避免PolicyChecker越来越臃肿。4.3 高频交互组件虚拟滚动日历差旅搜索页的日历要展示低价提醒一次性渲染两三个月的日期会造成卡顿。用虚拟滚动是在Vue列表性能优化里最直接有效的方案。常见做法是用vueuse/core的useVirtualList或者自己按可视高度计算渲染数量。我倾向于用插件因为它已经把滚动位置和缓存处理好了。import { useVirtualList } from vueuse/core const { list, containerProps, wrapperProps } useVirtualList( dateItems, { itemHeight: 44, overscan: 6 } )这里的overscan是额外渲染的行数设为6可以防止快速滚动时出现白屏。虚拟滚动的关键是itemHeight必须固定如果日期格子高度不固定需要先测量第一个元素的实际高度再赋值。差旅日历通常有一个“价格”和一个“星期几”高度可以固定为44px这属于可以优化的前提。5. 差旅业务中的特殊场景处理5.1 多平台比价结果的排序与聚合差旅OTA的典型场景是同一航班在多个供应商出价不同后端可能返回长列表也可能要求前端合并。我习惯在后端做聚合但前端也要处理展示逻辑。如果后端返回的列表里出现同一航班号、不同价格的多条记录前端要按“起飞时间 最低价”规则去重。排序时不要直接用字符串比较价格而要把机票价格扣除税费后的净价做数值比较。function dedupeFlightList(list) { const map new Map() list.forEach(item { const key item.flightNo item.departureDate const prev map.get(key) if (!prev || Number(item.netPrice) Number(prev.netPrice)) { map.set(key, item) } }) return Array.from(map.values()) }netPrice是机票净价不含机建燃油费用于内部比较展示时用totalPrice。这个函数要放在纯工具模块里因为搜索结果列表和收藏夹都可能用。如果后端已经返回了排序前端再做一次去重需要把去重后的顺序保持后端的“推荐”语义所以去重时要保留第一个出现的顺序而不是重排。5.2 审批流与Vue动态表单审批详情页显示的字段会根据当前审批节点变化比如部门审批人需要看到成本中心财务审批人需要看到超标原因。Vue里做动态表单关键在于把表单配置数据和字段组件解耦。我用一个schema数组描述每个字段的类型、校验规则和可见条件然后遍历渲染。const schema [ { field: reason, label: 超标原因, type: textarea, required: true }, { field: costCenter, label: 成本中心, type: select, required: false }, { field: budgetCode, label: 预算代码, type: input, required: true } ]渲染时用component :is切换字段组件required属性映射到VeeValidate的校验规则。如果某些字段只在某个审批节点显示就在schema里加visibleWhen回调函数。这个方案的缺点是schema会变得复杂因此我规定每个schema对象只能引用shared/validators里的规则不允许内联正则方便测试。5.3 金额精度与费率换算差旅订单涉及多币种和退改费率前端计算金额时必须用整数做单位和差值。比如机票总价是1500.50元后端返回单位是分前端展示时再做换算运算过程中永远不出现小数。退改费率更复杂常见的是“起飞前24小时免费起飞前4小时收取10%”。前端只做展示和简易试算真正的费率计算必须以后端为准。字段单位示例totalPrice分150050refundFee分15005currencyISO码CNY前端在做试算时把费率百分比转成小数再用整数价格乘以百分比。注意Math.round的行为对于0.5这样的小数会向上取整但银行家舍入法可能更符合财务规则差旅系统建议让后端返回已经舍入好的费用前端不要重复计算。6. 构建配置、布局异常排查与性能验证6.1 Vite按需加载与组件库引入OTA系统往往引用了完整UI组件库但很多页面只用其中几个组件。直接用全量引入会让打包后chunk-vendor非常大。Vite生态里使用unplugin-vue-components实现按需加载配合ElementPlus的自动导入。还要注意把vite.config.js里的构建目标设为es2020这样可以减少代码转换带来的体积增长。// vite.config.js import { defineConfig } from vite import vue from vitejs/plugin-vue import AutoImport from unplugin-auto-import/vite import Components from unplugin-vue-components/vite import { ElementPlusResolver } from unplugin-vue-components/resolvers export default defineConfig({ plugins: [ vue(), AutoImport({ resolvers: [ElementPlusResolver()] }), Components({ resolvers: [ElementPlusResolver()] }) ], build: { target: es2020, chunkSizeWarningLimit: 600 } })自动导入的副作用是模板中el-button这种自定义标签不会被IDE识别第一次看代码会觉得是魔法。团队里新成员容易困惑所以我在项目README里写明了自动导入规则并要求在components.d.ts中保存声明文件。chunkSizeWarningLimit只是把超过体积的提示阈值调高真正解体积要看下一条。6.2 vue打包后布局异常的检查清单Vue项目打包后布局异常是个高频问题根因往往是样式作用域、静态资源路径或CDN缓存。下面这张表是我在交付前必然过一遍的检查清单每一项都对应真实踩过的坑。现象可能原因处理方式字体图标打包后没显示字体文件路径是绝对路径/base: ./用相对路径二级路由刷新404history路由未配fallbackNginx配置try_files样式丢失或覆盖顺序错CSS选择器优先级和加载顺序变化组件样式加scoped避免全局修改首屏白屏加载的js chunk太大或CDN过期按路由拆分动态导入清CDN缓存布局异常最常见的是public目录里图片资源用了/images/...打包后如果部署在子路径就会找不到。统一改成相对路径或者在运行时拼接import.meta.env.BASE_URL。如果是element-plus样式丢失优先检查是否手动引入了全量主题包。6.3 用路由级代码分割验证性能验证性能提升最直接的方法是把路由组件改成动态导入。Vite在构建时会把每个动态导入的路由组件单独打包成chunk。我用npm run build后查看dist/assets下是否生成多个js文件如果只有一个大文件说明路由没有生效。const TripSearchView () import(../modules/trip/views/TripSearchView.vue)改完以后用浏览器的Network面板模拟Slow 3G观察首次加载完成时间。OTA系统的用户通常在出差路上用企业Wi-Fi网络质量并不稳定所以我会把首屏限制在核心模块登录和搜索审批、政策管理这些低频模块都放到二级路由里懒加载。最后再配合vite-plugin-compression开启gzip整体压缩率能到70%。这些操作都完成才算把Vue工程真正调到可交付状态。本文还有配套的精品资源点击获取