JY1.0/docs/JY1.0-采购件入库查询卡顿修改方案.md

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() 增加分页能力。

若可以同时做两项，最佳组合是：

• 采购件入库分页。
• 取消查询后自动勾选。

这两项组合最有希望直接解决当前“查询就卡页面崩溃”的核心问题。