简介这是一份面向 Vue.js 前端开发者的组合查询条件功能源码演示如何将输入框、下拉选择、日期选择等表单控件封装为可复用组件并动态拼接查询参数、请求后端数据并刷新列表。资源共 32 个文件压缩后 139KB以 14 个 js 文件、4 个 vue 文件为核心包含 Vue CLI 工程配置、Vuex 状态管理、路由权限控制与 axios 请求封装另附 json、xml、gitignore 等辅助配置目录结构清晰适合初学者对照完整项目理解组件通信、计算属性、侦听器和表单 v-model 的实际用法。已有 1277 人学习下载。通过阅读源码可以掌握 Vue 项目从脚手架搭建到查询条件组合、数据请求、状态同步的完整链路同时查询条件已按输入框、下拉、日期等类型拆分便于直接复用或改造成后台管理系统的筛选模块。整体代码量适中是学习 Vue 组件化开发与前后端联调思路的实用参考。1. 组合查询条件源码一个 Vue 查询组件的完整实现给列表页做搜索条件的时候我猜你大概率遇到过这样的需求字段不固定、条件可增删、查询逻辑还能在 AND/OR 之间切换。如果后端同学再补上一句「条件组合你们前端拼好传给我」那基本就宣告手写if/else时代结束。这份 vue 组合查询条件源码就是把这些痛点收敛成一个现成的 Vue 组件方案——它不依赖后端不绑定 UI 库纯 Vue 实现动态条件行的增删改查适合做中后台管理系统、数据报表筛选器和数据看板的高级搜索。打开源码包你会发现核心其实就是一个组件加一个解析器既能在 Vue 2 里跑也能迁移到 Vue 3属于那种「看懂了一张图就能自己改出花」的项目。作为插件类资源它比你自己从零拼条件表单要省下至少一个迭代周期。2. 整体架构与数据模型先看条件 DSL 怎么设计2.1 目录结构一个组件和一个解析器就能干活解压源码后整个项目的结构非常克制没有把简单的事情复杂化。常见 Vue 工程的src目录在这里被浓缩成一个组件目录、一个工具目录和一个类型声明文件。我拆过不少类似项目很多源码包喜欢堆十几个辅助文件但这个项目的组织方式更接近实战团队的写法——把「条件渲染」和「条件解析」拆成两个独立关注点其余逻辑都塞进各自的index.js。src/ ├── components/ │ └── query-builder/ │ ├── index.vue // 组件入口负责整体渲染与状态管理 │ ├── condition-row.vue // 单行条件组件字段/运算符/值三栏联动 │ └── group.vue // 条件组组件支持嵌套分组与 AND/OR 切换 ├── utils/ │ ├── parser.js // 将条件树转换成查询参数对象 │ └── validator.js // 校验条件完整性跳过空行和未选字段 ├── types/ │ └── index.js // 条件节点、运算符枚举、字段配置表结构 ├── App.vue // 演示页面展示组件双向绑定与查询触发 └── main.js // Vue 入口这个拆分思路值得借鉴组件只管「用户看到的操作界面」解析器负责「把界面状态翻译成后端能用的数据结构」。哪怕你之后要把项目改成 React 版本parser.js和types/index.js几乎是零成本平移的。演示页App.vue里有完整的字段配置示例把组件接入自己的业务时直接照抄这个配置结构就行。2.2 条件的数据结构字段、运算符、值的最小组合查询条件的本质是「字段 运算符 值」的三元组。但这个项目的设计没有停留在三元组而是把多个条件组合成一个树形结构支持分组嵌套。每一层都带logic字段标记是 AND 还是 OR这样后端拿到的数据天然就是可递归解析的表达式树。// types/index.js export const LOGIC_MAP { AND: and, OR: or } export const OPERATOR_MAP { eq: { label: 等于, symbol: }, ne: { label: 不等于, symbol: ! }, gt: { label: 大于, symbol: }, lt: { label: 小于, symbol: }, contains: { label: 包含, symbol: like }, between: { label: 区间, symbol: between }, in: { label: 在列表中, symbol: in } } export function createEmptyCondition() { return { field: , operator: eq, value: , // 一个条件节点内部也可以继续嵌套形成树形结构 children: [], logic: LOGIC_MAP.AND, // 标记是否已经被用户修改过用于校验时跳过低价值的空行 touched: false } }LOGIC_MAP和OPERATOR_MAP是整个组件的「字典表」。前端 UI 下拉框里的展示文案、提交给后端时用到的符号、以及条件校验时的逻辑判断全都查这两张表。createEmptyCondition()工厂函数看起来简单但touched这个字段很关键——用户刚点「添加条件」时会立刻生成一个空节点但还没交互过这时候如果你直接把它提交给后端就会产生{ field: , operator: eq, value: }这种脏数据。有了touched标记校验器就能精准跳过「用户加了但没碰过」的空行。括号嵌套的表示方式一般采用children数组。一行条件既可以承载自己的字段、运算符和值也可以只有一个逻辑运算符和子条件组等价于 SQL 里的(A OR B) AND C。这个递归结构是整棵条件树的骨架后面的渲染、解析、回显全都在这个模型上做文章。顺带提醒一句field的值不要存中文名存字段的 key比如createTime中文标签在配置表里用label映射。很多初写这个组件的开发者会在field里直接塞中文结果提交给后端还得再转换一次属于比较典型的「绕远路」写法。3. 核心模块拆解从条件操作到查询参数生成的链路3.1 条件行交互增删行与字段联动condition-row.vue是用户最常打交道的文件。它在界面上渲染成一行「字段下拉框 运算符下拉框 值输入框 删除按钮」右侧通常还有一个「添加条件」按钮点击后在当前行后面插入一个新的空条件。这个组件的设计核心是「受控组件」——它不自己管理数据而是通过v-model接收外部传入的条件对象再通过$emit通知父组件更新。template div classcondition-row select :valuecondition.field changeonFieldChange option value disabled请选择字段/option option v-forfield in fieldOptions :keyfield.key :valuefield.key {{ field.label }} /option /select select :valuecondition.operator changeonOperatorChange option v-for(op, key) in availableOperators :keykey :valuekey {{ op.label }} /option /select !-- 根据字段类型动态切换输入控件 -- input v-ifinputType text v-modelcondition.value typetext placeholder请输入值 / input v-else-ifinputType number v-modelcondition.value typenumber placeholder请输入数值 / input v-else-ifinputType date v-modelcondition.value typedate / button click$emit(remove, condition)删除/button /div /templateonFieldChange的联动逻辑是这段代码的灵魂。用户切换字段时组件会清空operator和value避免上一个字段残留的运算符污染新字段的展示。实际操作中我一般会在这里做一下字段type的判断比如日期字段只给gt/lt/between文本字段只给eq/contains数字字段才开放全部运算符——参考下面这段伪代码onFieldChange(event) { const fieldKey event.target.value const fieldConfig this.findFieldConfig(fieldKey) // 重置运算符为默认值避免新旧字段语义冲突 this.$emit(update:condition, { ...this.condition, field: fieldKey, operator: eq, value: , touched: true }) // 根据字段类型决定可用运算符列表 this.availableOperators this.filterOperatorsByFieldType(fieldConfig) }filterOperatorsByFieldType推荐的做法是给字段配置加一个operators白名单数组。比如{ key: createTime, label: 创建时间, type: date, operators: [gt, lt, between] }。这样哪类字段支持哪些运算符一目了然运营要加字段也不用翻代码。真实业务中字段动辄几十个如果每个字段的运算符全靠组件内部逻辑推断维护成本会直线上升。父组件index.vue则保存整个条件树数组处理「添加条件」「删除条件」「切换分组逻辑」等操作。删除操作要注意索引问题如果条件在循环里用index作为key删除中间行时可能导致 Vue 复用了错误的 DOM 节点最稳妥的做法是给每条条件生成一个唯一的id删除时按id过滤而不是按数组下标splice。3.2 参数生成把条件列表还原成查询对象条件树的 UI 操作只是第一步真正决定这个组件能不能被后端同学接纳的是parser.js的输出格式。大部分组合查询组件的翻车现场都在这里界面上条件排布得很好看但生成的结果不是嵌套太深就是字段名和值对不上。这个项目的解析器采用递归下降的思路每一层都负责处理自己的children最后拼出一个层次清晰的查询对象。// utils/parser.js export function buildQueryParams(conditionTree) { if (!conditionTree || !conditionTree.children || conditionTree.children.length 0) { return null } const conditionList conditionTree.children .map(node parseNode(node)) .filter(Boolean) if (conditionList.length 0) { return null } return { logic: conditionTree.logic || and, conditions: conditionList } } function parseNode(node) { // 处理嵌套分组节点 if (node.children node.children.length 0) { return buildQueryParams(node) } // 跳过用户未配置完整的条件 if (!node.field || (node.operator ! in node.operator ! between !node.value)) { return null } // 简单条件节点 return { field: node.field, operator: node.operator, value: normalizeValue(node.operator, node.value) } } function normalizeValue(operator, value) { // between 和 in 是数组形态其余是普通标量 if (operator between) { return Array.isArray(value) ? value : [value, value] } if (operator in) { return Array.isArray(value) ? value : value.split(,) } return value }这里buildQueryParams承担了两个职责一是把条件树中配置了children的分组节点递归地再转成子查询对象二是通过parseNode对叶子节点做数据清洗。空值过滤的逻辑放得很隐蔽但特别重要——用户在前端加了条件但没填值parseNode会直接返回null然后被filter(Boolean)吞掉。如果少了这一步后端会收到大量残缺的查询条件轻则报错重则泄露全表数据某些后端框架会把空字符串当成「不查这个字段」而返回不该返回的数据。normalizeValue函数处理的是运算符对值格式的要求差异。between和in这两个运算符天然需要多个值对前端来说between的 UI 应该是两个输入框in则可能是多选框或逗号分隔的文本框。解析器在组装参数时统一归一化成数组后端不管收到的是一个值还是两个值都能正确处理。这种边界细节很多是从真实接口血泪里补出来的第一次写的人大概率会在联调时被后端指出「你传的 value 格式不对」。3.3 条件回显拿接口数据反向填充表单条件回显是另一个容易被低估的模块。编辑已保存的查询方案时接口通常会把条件数据原样返回比如{ logic: and, conditions: [{ field: status, operator: eq, value: 1 }] }前端要做的是把这个平铺或者嵌套的对象反向渲染成之前的条件行。这个源码里的validator.js除了做提交校验也承担了回显前的数据修正工作。回显的核心难点在于两类字段的还原一类是touched标记在回显时不需要了所有从接口拿到的条件都是「真实条件」必须标记为已交互另一类是value的还原——接口返回的between值是数组[start, end]组件里要拆成两个输入框分别填充in的数组值要塞进多选组件。一个常见的坑是日期类型的字段接口返回2024-01-01字符串但日期组件要求接收 Date 实例这时候回显逻辑里需要补一步格式转换function normalizeIncomingCondition(rawCondition) { const { field, operator, value } rawCondition let normalizedValue value if (operator between Array.isArray(value)) { // 区间查询回显到双输入框 normalizedValue { start: value[0], end: value[1] } } if (operator in Array.isArray(value) fieldConfig.type date) { // 日期列表转成 Date 格式 normalizedValue value.map(item new Date(item)) } return { ...rawCondition, value: normalizedValue, touched: true } }这块的逻辑虽然不复杂但缺少的话组件就只能「新建查询」而不能「编辑查询」实用性直接减半。毕竟一个成熟的高级搜索组件保存和回显几乎是标配能力。所谓完整闭环不只是 UI 上能点、数据能查还包括下次进来时状态能百分百复原少了任何一个环节项目落地都要返工。4. 避坑指南组合查询组件的三个高频问题4.1 切换运算符后值控件没有跟着变现象字段从「日期」切到「文本」后输入框还是日期选择器用户手动输入的文本根本存不进去。原因inputType是根据字段类型计算的但切换字段后组件的availableOperators更新了condition.operator却还是旧值value控件的v-if判断依据没变。更隐蔽的情况是组件复用了旧的 DOM 节点Vue 的 diff 算法没有重建输入框。解决在onFieldChange中强制重置operator为eq并清空value同时给value输入控件加上:keycondition.field condition.operator强制 Vue 在字段或运算符变化时销毁并重建输入控件。这个key绑定是很多 Vue 表单组件的通用解法花小钱办大事。4.2 嵌套分组时父子组件的逻辑混乱现象一个分组里拖入另一个分组外层选 AND内层选 OR生成查询参数时内层条件全部「穿透」到了外层结果与 UI 上看到的条件关系完全不符。原因buildQueryParams递归时没有检查子节点的logic字段导致所有条件被平铺到同一层级。这个问题的本质是递归函数的「递归出口」和「递归分支」没有严格区分。解决在parseNode里先判断children children.length 0如果存在子节点就递归调用buildQueryParams并确保该节点输出结构为{ logic: node.logic, conditions: childrenNested }否则直接当叶子处理。调试时先在控制台打印JSON.stringify(queryParams)两层嵌套一眼就能看出结构是否对。4.3 提交给后端时空值和全角符号兜底不完整现象用户在条件值里输入了空格或者全角括号后端like查询返回 500部分框架还会把 SQL 拼错。原因normalizeValue只做了数组归一化没有清理空白字符也没有处理运算符本身的字符转义。全角括号在 MySQL 里不属于危险字符但某些查询引擎要求精确匹配此时空字符串、纯空格会被当成非法输入。解决在normalizeValue增加String.prototype.trim()处理条件校验再加一道如果 value 在 trim 后为空且运算符是eq/ne/contains直接过滤掉该条件。这类兜底看起来是小细节但真实联调时能省下一整轮的沟通成本——毕竟后端不会告诉你是哪条记录的空格没处理。5. 二次开发把这个组件改造成你项目的查询协议接手这个源码后第一步不是改组件而是先理清你的后端需要什么协议。比如 ERP 系统的查询接口只接受扁平参数?status1createTime_gt2024-01-01那么parser.js的输出就不能用嵌套结构而应该把条件树拍平export function buildFlatParams(tree, prefix ) { const params {} tree.children.forEach(node { if (node.children node.children.length 0) { Object.assign(params, buildFlatParams(node, prefix)) } else { // 扁平化 key字段名_运算符 params[${node.field}_${node.operator}] node.value } }) return params }一旦你掌握了这个组件的改造套路会发现它的扩展点非常清晰。我实际项目里的做法是这样拆分需求的新增字段类型只需要在字段配置表里加一条记录比如{ key: age, label: 年龄, type: number, operators: [gt, lt, between] }组件渲染会自动识别。替换 UI 框架把condition-row.vue里的原生select替换成 Element 的el-select会节省大量样式维护成本。但务必确认v-model还是绑定在condition.field上$emit事件名不要动这样其他模块不受影响。对接后端动态字段如果字段本身是后台配置下发的那fieldOptions就不能写死在App.vue里而应该换成接口请求后把数据注入组件 props同时保留一份静态默认配置作为兜底。我的建议是改动时先用App.vue做 playground跑通一条完整的「添加条件 → 填写值 → 生成参数 → 回显」链路再去接真实后端。改完以后记得回归测试两个边界场景第一只有一层条件时生成结果是否正确第二条件全是空值时提交按钮是否被禁用或生成null。有一次我就是只顾着加新运算符忘了校验in和between的数组格式结果 main 分支炸了一下午。从那以后我每次改完parser.js都强制自己先在浏览器控制台跑一遍JSON.stringify(buildQueryParams(tree))确认输出协议没有问题再去碰 UI 层。后续你再接入权限系统或者多租户隔离时组件的条件树本身就是很好的结构逻辑往里面塞一个userId字段或者租户 ID 就能实现数据隔离。灵活性的天花板比想象中高。希望帮到你。本文还有配套的精品资源点击获取