更新采购订单、发货、合同查询、盘点、入库和配置文件，新增零改单和文档

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

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