# JY1.0 采购件入库查询卡顿修改方案 ## 1. 背景说明 仓储管理模块页面 `src/views/WarehouseManagement/PurchasePartsStorage/index.vue` 在执行查询操作时，存在页面明显卡顿、浏览器长时间无响应、严重时看起来像页面崩溃的问题。 本方案用于整理当前排查结论、明确问题成因，并提出分阶段修改建议。本文档只给出修改方案，不直接改动代码。 ## 2. 问题现象 当前页面包含采购件入库、自制件入库、外协到货等多个页签，其中采购件入库页签在选择供应商或合同后会自动执行查询。 现场表现主要包括： - 点击查询后页面长时间卡住。 - 表格数据返回后界面渲染明显变慢。 - 数据量较大时浏览器出现假死或无响应。 - 用户主观感受为“查询就崩”。 ## 3. 涉及文件 - `src/views/WarehouseManagement/PurchasePartsStorage/index.vue` - `src/main.js` - `src/utils/request.js` 重点排查方法： - `searchTable1()` - `searchTable3()` - `getSummaries()` - `getSummaries1()` - `handleSelectionChange()` - `recalcSelection()` ## 4. 原因分析 ### 4.1 采购件入库查询未分页，前端一次性加载全量数据 在 `searchTable1()` 中，查询请求通过 `CreateData('11', ..., param)` 发送，但未传入分页参数。 这会带来两个问题： - 后端可能直接返回该供应商或合同下的全部数据。 - 前端需要一次性渲染整张大表，数据量较大时会明显拖慢页面。 相比之下，自制件入库的 `searchTable3()` 已传入 `pageSize1` 和 `pageCurrent1`，说明当前页面内部本身就存在两种不同的数据加载策略，采购件入库部分的实现明显更重。 ### 4.2 查询完成后自动逐行全选，进一步放大渲染压力 在 `searchTable1()` 中，查询成功后会遍历 `tableData1`，并对满足条件的行逐个执行： - `this.$refs.table.toggleRowSelection(row, true)` 虽然代码里使用了 `_suppressSelectionChange` 来避免自定义选中计算被重复触发，但 Element UI 表格内部仍需要为每一行更新选中状态、复选框状态和相关渲染结果。 当查询结果很多时，这段“逐行自动勾选”的逻辑会成为非常重的同步操作，容易造成主线程阻塞。 ### 4.3 表格每行挂载多个重量级组件，导致大表渲染成本过高 采购件入库与自制件入库表格中，每行都包含较多交互组件，例如： - `el-select` - `el-input-number` - 选择列 - 按钮列 其中 `el-input-number` 和 `el-select` 在大数据表格中本身就属于渲染和响应式开销较高的组件。若查询结果达到数百行甚至更多，组件实例数、watcher 数量、DOM 节点数量都会迅速增大。 ### 4.4 表格启用汇总行，汇总函数会对数据做多轮遍历 页面使用了： - `show-summary` - `summary-method` 而 `getSummaries()`、`getSummaries1()` 中对多个列执行了多次 `map + reduce` 计算。 这意味着： - 查询后首次渲染要做汇总计算。 - 表格数据变化、选中变化、输入变化后，汇总有机会被再次触发。 - 当数据量大时，汇总计算会持续放大卡顿感。 ### 4.5 查询动作与下拉联动查询存在叠加请求 例如自制件入库页签中，订单切换时会同时触发： - `searchTable3()` - `getnumberSelection()` 这类逻辑虽然不是采购件入库“卡死”的唯一主因，但会增加同一时间段内的请求数和页面状态更新次数，让用户更容易感知到页面迟滞。 ### 4.6 当前超时配置较大，不容易快速暴露性能问题 `src/utils/request.js` 中 Axios `timeout` 设置为 `1500000`。 这会导致： - 如果接口慢，页面会长时间停留在等待状态。 - 如果前端渲染本身很重，用户更容易把“卡顿”感知为“页面崩溃”。 这不是根因，但会放大问题表现。 ## 5. 结论判断 综合代码结构，当前“查询就卡页面崩溃”的高概率原因不是单一点故障，而是以下因素叠加： 1. 采购件入库查询无分页。 2. 查询完成后自动逐行勾选可入库数据。 3. 大表格中每行挂载多个重量级输入组件。 4. 汇总行对全量数据重复做统计计算。 其中，优先级最高、最值得首先处理的是前两项。 ## 6. 修改目标 本次优化建议以“先止血，再优化体验”为原则，目标如下： - 将查询后的页面卡顿控制在可接受范围内。 - 避免浏览器因大数据量渲染出现假死。 - 保持现有业务流程基本不变。 - 尽量复用项目现有分页、查询、表格处理模式。 - 将改动范围控制在 `PurchasePartsStorage` 页面内部，避免影响其他模块。 ## 7. 修改方案 ### 7.1 方案一：为采购件入库查询增加分页 这是首要方案。 #### 修改思路 - 为采购件入库表格引入与自制件入库一致的分页机制。 - 在 `searchTable1()` 中调用 `CreateData()` 时补充分页参数。 - 页面新增采购件入库对应的分页组件与分页状态。 - 后端查询过程若已支持分页，则直接接入。 - 后端若尚未支持分页，需要同步补充分页查询能力。 #### 预期收益 - 避免一次性返回几百或几千条数据。 - 大幅降低首屏渲染压力。 - 为后续汇总优化、选择优化提供基础。 #### 风险点 - 需要确认后端 `仓储管理_采购入库合同明细_查询` 是否支持分页返回 `rows/total`。 - 如果当前接口只返回普通数组，前后端都需要调整返回结构。 ### 7.2 方案二：取消查询后自动全选所有可入库行 这是与分页并列的高优先级方案。 #### 修改思路 - 查询完成后不再自动执行 `toggleRowSelection` 遍历全表。 - 保留手工勾选模式，由用户自主选择入库数据。 - 如业务上确实需要批量选择，可增加单独按钮，例如“勾选当前页可入库项”。 - 如仍需保留自动选择能力，建议限制为只处理当前页数据，而不是全量结果。 #### 预期收益 - 避免一次查询后产生大量同步 UI 更新。 - 显著降低 Element 表格内部状态维护成本。 - 使查询动作本身更纯粹，减少联动副作用。 #### 风险点 - 用户操作习惯会发生轻微变化。 - 若一线人员依赖默认全选，需要补充一个显式批量勾选按钮作为替代。 ### 7.3 方案三：降低表格每行组件数量 这是第二阶段优化方案。 #### 修改思路 - 默认以文本方式展示数值和货位。 - 仅在用户点击某行或某单元格后切换为可编辑组件。 - 或将数量、货位编辑能力迁移到弹窗/侧边表单中进行。 #### 可选实现方式 - 方式 A：保留表格编辑，但只对当前编辑行渲染 `el-input-number` 和 `el-select`。 - 方式 B：表格只展示，编辑统一在“设置货位/修改本次到货数”弹窗内完成。 #### 预期收益 - 大幅减少页面初次渲染和更新渲染的组件实例数。 - 降低响应式系统负担。 #### 风险点 - 交互形式改变较大，需业务确认。 - 改动量大于分页和取消自动全选。 ### 7.4 方案四：优化汇总逻辑 这是辅助优化方案。 #### 修改思路 - 汇总只统计当前页数据，不统计全量数据。 - 或在查询成功后一次性计算并缓存汇总结果，避免在渲染阶段多次 `map + reduce`。 - 对不必要展示汇总的列取消统计。 #### 预期收益 - 降低表格重渲染时的计算开销。 - 对大页数据场景效果明显。 #### 风险点 - 需确认业务是否要求“全量合计”还是“当前页合计”。 ### 7.5 方案五：收敛筛选联动查询，减少重复请求 这是体验优化方案。 #### 修改思路 - 将“切换筛选项即自动查询”改为“选择条件后点击查询按钮再执行”。 - 对必须联动的下拉，仅查询下一级选项，不立即刷新大表。 - 对输入型查询条件增加节流或按回车触发。 #### 预期收益 - 避免用户频繁切换条件时重复打接口和重复渲染。 - 页面行为更可控。 #### 风险点 - 与当前“选择即查”的使用习惯不完全一致。 ## 8. 推荐实施顺序 建议按以下顺序推进： ### 第一阶段：快速止血 目标是在不大改页面交互的前提下，尽快解决“查询卡死”。 建议执行： 1. 采购件入库增加分页。 2. 取消查询后自动全选。 3. 采购件入库增加显式“勾选当前页可入库项”按钮，作为自动全选替代。 ### 第二阶段：性能优化 目标是继续提升大数据场景下的流畅度。 建议执行： 1. 优化汇总函数。 2. 减少表格内 `el-input-number`、`el-select` 的常驻渲染数量。 3. 调整筛选联动逻辑，减少重复请求。 ### 第三阶段：体验收敛 目标是统一仓储大表页面的实现模式。 建议执行： 1. 对采购件入库、自制件入库、外协到货的查询行为做统一规范。 2. 明确哪些页签必须分页、哪些页签允许全量查。 3. 统一表格汇总、批量勾选、行编辑的实现方式。 ## 9. 建议的具体改动点 以下为建议修改点，不代表本次已经改动： ### 9.1 页面状态 在 `PurchasePartsStorage/index.vue` 中补充采购件入库分页状态，例如： - `pageCurrentRK` - `pageSizeRK` - `totalRK` 或直接复用现有命名体系，保持与页面其他分区一致。 ### 9.2 查询方法 重点调整： - `searchTable1()` 建议： - 查询请求增加分页参数。 - 查询结果改为接收分页结构。 - 删除查询成功后的逐行 `toggleRowSelection` 自动勾选逻辑。 ### 9.3 表格区域 采购件入库表格下方增加分页组件，行为对齐自制件入库分页实现。 ### 9.4 批量选择逻辑 新增显式按钮： - “勾选当前页可入库” - “取消当前页勾选” 这样既能保留批量能力，也能避免查询完成后立即执行重计算。 ### 9.5 汇总逻辑 重构： - `getSummaries()` - `getSummaries1()` 建议尽量减少重复遍历次数，并明确统计口径为“当前页合计”。 ## 10. 验证方案 修改完成后建议按以下方式验证： ### 10.1 功能验证 - 选择供应商后能正常查询采购件入库数据。 - 切换合同后能正常刷新结果。 - 分页切换后数据正确。 - 手工勾选、批量勾选后入库功能正常。 - 货位选择、数量输入、打印功能不受影响。 ### 10.2 性能验证 - 查询 50 条、100 条、300 条时页面响应是否明显改善。 - 查询后页面是否仍出现长时间卡死。 - 批量勾选当前页时是否可接受。 - 输入数量、选择货位时是否仍然卡顿。 ### 10.3 回归验证 - 自制件入库页签行为不受影响。 - 外协到货页签行为不受影响。 - 入库单弹窗显示和合并逻辑不受影响。 ## 11. 风险与注意事项 - 若后端接口当前不支持分页，本次优化需要前后端联动处理。 - 若业务习惯依赖“查询即默认勾选全部可入库项”，需要提前通知用户交互变更。 - 若汇总口径从全量改为当前页，需业务确认是否接受。 - 若后续计划继续扩展该页面，建议优先统一仓储大表的分页和编辑规范，避免重复出现同类问题。 ## 12. 最终建议 推荐采用“先小改止血，再做结构优化”的策略： 1. 先做采购件入库分页。 2. 同时取消查询后的自动逐行全选。 3. 再根据现场体验决定是否继续推进表格轻量化和汇总优化。 若只能先做一项，优先级最高的是： - `searchTable1()` 增加分页能力。 若可以同时做两项，最佳组合是： - 采购件入库分页。 - 取消查询后自动勾选。 这两项组合最有希望直接解决当前“查询就卡页面崩溃”的核心问题。