367 lines
12 KiB
Markdown
367 lines
12 KiB
Markdown
# 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()` 增加分页能力。
|
||
|
||
若可以同时做两项，最佳组合是：
|
||
|
||
- 采购件入库分页。
|
||
- 取消查询后自动勾选。
|
||
|
||
这两项组合最有希望直接解决当前“查询就卡页面崩溃”的核心问题。
|