702 lines
65 KiB
Markdown
702 lines
65 KiB
Markdown
# 03 采集数据批处理与结果文件优化
|
||
|
||
> 对应总览任务：41-60
|
||
> 计划来源：`docs/plans/00-plan-overview.md`；仓库当前没有 `docs/specs/`，本模块计划根据现有代码审计结果生成。
|
||
|
||
## 模块目标
|
||
|
||
将采集结果从逐行对象存储/逐行 upsert 改为可控批处理，降低数据库往返、RustFS 小对象数量、序列化次数和结果文件生成内存。
|
||
|
||
## 模块级执行规则
|
||
|
||
- 开发阶段单线程串行执行，不并行实现多个任务；完成一个任务的测试、实现、验证和 commit 后才能进入下一个任务。
|
||
- 每个任务严格按“先写全部测试 → 运行确认 RED → 实现 → 运行确认 GREEN → lint/format → commit”执行。
|
||
- 每个普通任务至少包含 8 个语义化测试；涉及 I/O、数据库、HTTP、Redis、RustFS、文件或 UI 时，测试必须同时覆盖 mock 依赖和真实集成/启动调用。
|
||
- 禁止纯 echo、硬编码成功、空实现、跳过真实依赖调用或仅以 import 成功作为验收。
|
||
|
||
## 任务 41：建立 Collect Data 1k/10k 行、多个 chunk 和品牌检测场景基线
|
||
|
||
**所属模块**：采集数据批处理与结果文件优化
|
||
**依赖**：无
|
||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||
|
||
### 功能点要求
|
||
- 围绕“建立 Collect Data 1k/10k 行、多个 chunk 和品牌检测场景基线”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||
- 实现范围限定在 backend-java 的 collectdata 解析、品牌检查、ASIN 去重、结果项持久化和结果文件生成。
|
||
|
||
### 测试用例（必须先写，确认 RED）
|
||
1. `test_task_041_chunk_brand_normal_default_path` — 使用正常输入验证“建立 Collect Data 1k/10k 行、多个 chunk 和品牌检测场景基线”的默认成功路径和主输出。
|
||
2. `test_task_041_chunk_brand_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||
3. `test_task_041_chunk_brand_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||
4. `test_task_041_chunk_brand_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||
5. `test_task_041_chunk_brand_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||
6. `test_task_041_chunk_brand_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||
7. `test_task_041_chunk_brand_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||
8. `test_task_041_chunk_brand_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||
|
||
### TDD 流程
|
||
|
||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||
|
||
### 验证方法
|
||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||
- 重点观察：backend-java 的 collectdata 解析、品牌检查、ASIN 去重、结果项持久化和结果文件生成。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||
|
||
## 任务 42：限制采集解析的文件大小、最大行数和单 chunk 行数
|
||
|
||
**所属模块**：采集数据批处理与结果文件优化
|
||
**依赖**：41
|
||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||
|
||
### 功能点要求
|
||
- 围绕“限制采集解析的文件大小、最大行数和单 chunk 行数”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||
- 实现范围限定在 backend-java 的 collectdata 解析、品牌检查、ASIN 去重、结果项持久化和结果文件生成。
|
||
|
||
### 测试用例（必须先写，确认 RED）
|
||
1. `test_task_042_file_size_row_count_chunk_normal_default_path` — 使用正常输入验证“限制采集解析的文件大小、最大行数和单 chunk 行数”的默认成功路径和主输出。
|
||
2. `test_task_042_file_size_row_count_chunk_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||
3. `test_task_042_file_size_row_count_chunk_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||
4. `test_task_042_file_size_row_count_chunk_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||
5. `test_task_042_file_size_row_count_chunk_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||
6. `test_task_042_file_size_row_count_chunk_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||
7. `test_task_042_file_size_row_count_chunk_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||
8. `test_task_042_file_size_row_count_chunk_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||
|
||
### TDD 流程
|
||
|
||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||
|
||
### 验证方法
|
||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||
- 重点观察：backend-java 的 collectdata 解析、品牌检查、ASIN 去重、结果项持久化和结果文件生成。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||
|
||
## 任务 43：将采集源文件查找改为确定路径/索引查询
|
||
|
||
**所属模块**：采集数据批处理与结果文件优化
|
||
**依赖**：42
|
||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||
|
||
### 功能点要求
|
||
- 围绕“将采集源文件查找改为确定路径/索引查询”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||
- 实现范围限定在 backend-java 的 collectdata 解析、品牌检查、ASIN 去重、结果项持久化和结果文件生成。
|
||
|
||
### 测试用例（必须先写，确认 RED）
|
||
1. `test_task_043_collect_normal_default_path` — 使用正常输入验证“将采集源文件查找改为确定路径/索引查询”的默认成功路径和主输出。
|
||
2. `test_task_043_collect_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||
3. `test_task_043_collect_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||
4. `test_task_043_collect_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||
5. `test_task_043_collect_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||
6. `test_task_043_collect_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||
7. `test_task_043_collect_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||
8. `test_task_043_collect_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||
|
||
### TDD 流程
|
||
|
||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||
|
||
### 验证方法
|
||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||
- 重点观察：backend-java 的 collectdata 解析、品牌检查、ASIN 去重、结果项持久化和结果文件生成。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||
|
||
## 任务 44：保留原始 chunk payload 的同时，减少逐行 extra JSON 的重复序列化
|
||
|
||
**所属模块**：采集数据批处理与结果文件优化
|
||
**依赖**：43
|
||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||
|
||
### 功能点要求
|
||
- 围绕“保留原始 chunk payload 的同时，减少逐行 extra JSON 的重复序列化”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||
- 实现范围限定在 backend-java 的 collectdata 解析、品牌检查、ASIN 去重、结果项持久化和结果文件生成。
|
||
|
||
### 测试用例（必须先写，确认 RED）
|
||
1. `test_task_044_payload_chunk_normal_default_path` — 使用正常输入验证“保留原始 chunk payload 的同时，减少逐行 extra JSON 的重复序列化”的默认成功路径和主输出。
|
||
2. `test_task_044_payload_chunk_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||
3. `test_task_044_payload_chunk_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||
4. `test_task_044_payload_chunk_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||
5. `test_task_044_payload_chunk_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||
6. `test_task_044_payload_chunk_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||
7. `test_task_044_payload_chunk_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||
8. `test_task_044_payload_chunk_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||
|
||
### TDD 流程
|
||
|
||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||
|
||
### 验证方法
|
||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||
- 重点观察：backend-java 的 collectdata 解析、品牌检查、ASIN 去重、结果项持久化和结果文件生成。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||
|
||
## 任务 45：将 ASIN 去重查询与无效品牌查询统一为批量集合查询
|
||
|
||
**所属模块**：采集数据批处理与结果文件优化
|
||
**依赖**：44
|
||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||
|
||
### 功能点要求
|
||
- 围绕“将 ASIN 去重查询与无效品牌查询统一为批量集合查询”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||
- 实现范围限定在 backend-java 的 collectdata 解析、品牌检查、ASIN 去重、结果项持久化和结果文件生成。
|
||
|
||
### 测试用例（必须先写，确认 RED）
|
||
1. `test_task_045_asin_brand_normal_default_path` — 使用正常输入验证“将 ASIN 去重查询与无效品牌查询统一为批量集合查询”的默认成功路径和主输出。
|
||
2. `test_task_045_asin_brand_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||
3. `test_task_045_asin_brand_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||
4. `test_task_045_asin_brand_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||
5. `test_task_045_asin_brand_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||
6. `test_task_045_asin_brand_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||
7. `test_task_045_asin_brand_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||
8. `test_task_045_asin_brand_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||
|
||
### TDD 流程
|
||
|
||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||
|
||
### 验证方法
|
||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||
- 重点观察：backend-java 的 collectdata 解析、品牌检查、ASIN 去重、结果项持久化和结果文件生成。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||
|
||
## 任务 46：跳过空品牌批次的无效远程品牌检查请求
|
||
|
||
**所属模块**：采集数据批处理与结果文件优化
|
||
**依赖**：45
|
||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||
|
||
### 功能点要求
|
||
- 围绕“跳过空品牌批次的无效远程品牌检查请求”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||
- 实现范围限定在 backend-java 的 collectdata 解析、品牌检查、ASIN 去重、结果项持久化和结果文件生成。
|
||
|
||
### 测试用例（必须先写，确认 RED）
|
||
1. `test_task_046_brand_normal_default_path` — 使用正常输入验证“跳过空品牌批次的无效远程品牌检查请求”的默认成功路径和主输出。
|
||
2. `test_task_046_brand_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||
3. `test_task_046_brand_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||
4. `test_task_046_brand_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||
5. `test_task_046_brand_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||
6. `test_task_046_brand_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||
7. `test_task_046_brand_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||
8. `test_task_046_brand_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||
|
||
### TDD 流程
|
||
|
||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||
|
||
### 验证方法
|
||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||
- 重点观察：backend-java 的 collectdata 解析、品牌检查、ASIN 去重、结果项持久化和结果文件生成。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||
|
||
## 任务 47：为品牌检查结果增加任务内短期缓存，避免同品牌重复远程调用
|
||
|
||
**所属模块**：采集数据批处理与结果文件优化
|
||
**依赖**：46
|
||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||
|
||
### 功能点要求
|
||
- 围绕“为品牌检查结果增加任务内短期缓存，避免同品牌重复远程调用”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||
- 实现范围限定在 backend-java 的 collectdata 解析、品牌检查、ASIN 去重、结果项持久化和结果文件生成。
|
||
|
||
### 测试用例（必须先写，确认 RED）
|
||
1. `test_task_047_cache_brand_normal_default_path` — 使用正常输入验证“为品牌检查结果增加任务内短期缓存，避免同品牌重复远程调用”的默认成功路径和主输出。
|
||
2. `test_task_047_cache_brand_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||
3. `test_task_047_cache_brand_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||
4. `test_task_047_cache_brand_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||
5. `test_task_047_cache_brand_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||
6. `test_task_047_cache_brand_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||
7. `test_task_047_cache_brand_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||
8. `test_task_047_cache_brand_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||
|
||
### TDD 流程
|
||
|
||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||
|
||
### 验证方法
|
||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||
- 重点观察：backend-java 的 collectdata 解析、品牌检查、ASIN 去重、结果项持久化和结果文件生成。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||
|
||
## 任务 48：将 invalid ASIN 记录改为批量 INSERT IGNORE/upsert
|
||
|
||
**所属模块**：采集数据批处理与结果文件优化
|
||
**依赖**：47
|
||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||
|
||
### 功能点要求
|
||
- 围绕“将 invalid ASIN 记录改为批量 INSERT IGNORE/upsert”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||
- 实现范围限定在 backend-java 的 collectdata 解析、品牌检查、ASIN 去重、结果项持久化和结果文件生成。
|
||
|
||
### 测试用例（必须先写，确认 RED）
|
||
1. `test_task_048_asin_normal_default_path` — 使用正常输入验证“将 invalid ASIN 记录改为批量 INSERT IGNORE/upsert”的默认成功路径和主输出。
|
||
2. `test_task_048_asin_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||
3. `test_task_048_asin_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||
4. `test_task_048_asin_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||
5. `test_task_048_asin_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||
6. `test_task_048_asin_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||
7. `test_task_048_asin_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||
8. `test_task_048_asin_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||
|
||
### TDD 流程
|
||
|
||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||
|
||
### 验证方法
|
||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||
- 重点观察：backend-java 的 collectdata 解析、品牌检查、ASIN 去重、结果项持久化和结果文件生成。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||
|
||
## 任务 49：将结果明细从逐行 RustFS 对象改为 chunk 级 payload 存储
|
||
|
||
**所属模块**：采集数据批处理与结果文件优化
|
||
**依赖**：48
|
||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||
|
||
### 功能点要求
|
||
- 围绕“将结果明细从逐行 RustFS 对象改为 chunk 级 payload 存储”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||
- 实现范围限定在 backend-java 的 collectdata 解析、品牌检查、ASIN 去重、结果项持久化和结果文件生成。
|
||
|
||
### 测试用例（必须先写，确认 RED）
|
||
1. `test_task_049_payload_chunk_rustfs_normal_default_path` — 使用正常输入验证“将结果明细从逐行 RustFS 对象改为 chunk 级 payload 存储”的默认成功路径和主输出。
|
||
2. `test_task_049_payload_chunk_rustfs_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||
3. `test_task_049_payload_chunk_rustfs_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||
4. `test_task_049_payload_chunk_rustfs_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||
5. `test_task_049_payload_chunk_rustfs_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||
6. `test_task_049_payload_chunk_rustfs_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||
7. `test_task_049_payload_chunk_rustfs_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||
8. `test_task_049_payload_chunk_rustfs_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||
|
||
### TDD 流程
|
||
|
||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||
|
||
### 验证方法
|
||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||
- 重点观察：backend-java 的 collectdata 解析、品牌检查、ASIN 去重、结果项持久化和结果文件生成。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||
|
||
## 任务 50：为结果明细设计批量 upsert mapper 与幂等唯一键
|
||
|
||
**所属模块**：采集数据批处理与结果文件优化
|
||
**依赖**：49
|
||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||
|
||
### 功能点要求
|
||
- 围绕“为结果明细设计批量 upsert mapper 与幂等唯一键”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||
- 实现范围限定在 backend-java 的 collectdata 解析、品牌检查、ASIN 去重、结果项持久化和结果文件生成。
|
||
|
||
### 测试用例（必须先写，确认 RED）
|
||
1. `test_task_050_task_normal_default_path` — 使用正常输入验证“为结果明细设计批量 upsert mapper 与幂等唯一键”的默认成功路径和主输出。
|
||
2. `test_task_050_task_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||
3. `test_task_050_task_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||
4. `test_task_050_task_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||
5. `test_task_050_task_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||
6. `test_task_050_task_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||
7. `test_task_050_task_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||
8. `test_task_050_task_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||
|
||
### TDD 流程
|
||
|
||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||
|
||
### 验证方法
|
||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||
- 重点观察：backend-java 的 collectdata 解析、品牌检查、ASIN 去重、结果项持久化和结果文件生成。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||
|
||
## 任务 51：将 accepted 行的序列化和 hash 计算改为批量处理
|
||
|
||
**所属模块**：采集数据批处理与结果文件优化
|
||
**依赖**：50
|
||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||
|
||
### 功能点要求
|
||
- 围绕“将 accepted 行的序列化和 hash 计算改为批量处理”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||
- 实现范围限定在 backend-java 的 collectdata 解析、品牌检查、ASIN 去重、结果项持久化和结果文件生成。
|
||
|
||
### 测试用例（必须先写，确认 RED）
|
||
1. `test_task_051_task_normal_default_path` — 使用正常输入验证“将 accepted 行的序列化和 hash 计算改为批量处理”的默认成功路径和主输出。
|
||
2. `test_task_051_task_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||
3. `test_task_051_task_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||
4. `test_task_051_task_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||
5. `test_task_051_task_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||
6. `test_task_051_task_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||
7. `test_task_051_task_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||
8. `test_task_051_task_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||
|
||
### TDD 流程
|
||
|
||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||
|
||
### 验证方法
|
||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||
- 重点观察：backend-java 的 collectdata 解析、品牌检查、ASIN 去重、结果项持久化和结果文件生成。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||
|
||
## 任务 52：生成结果文件时按 chunk 一次读取，取消逐行对象读取
|
||
|
||
**所属模块**：采集数据批处理与结果文件优化
|
||
**依赖**：51
|
||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||
|
||
### 功能点要求
|
||
- 围绕“生成结果文件时按 chunk 一次读取，取消逐行对象读取”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||
- 实现范围限定在 backend-java 的 collectdata 解析、品牌检查、ASIN 去重、结果项持久化和结果文件生成。
|
||
|
||
### 测试用例（必须先写，确认 RED）
|
||
1. `test_task_052_chunk_normal_default_path` — 使用正常输入验证“生成结果文件时按 chunk 一次读取，取消逐行对象读取”的默认成功路径和主输出。
|
||
2. `test_task_052_chunk_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||
3. `test_task_052_chunk_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||
4. `test_task_052_chunk_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||
5. `test_task_052_chunk_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||
6. `test_task_052_chunk_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||
7. `test_task_052_chunk_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||
8. `test_task_052_chunk_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||
|
||
### TDD 流程
|
||
|
||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||
|
||
### 验证方法
|
||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||
- 重点观察：backend-java 的 collectdata 解析、品牌检查、ASIN 去重、结果项持久化和结果文件生成。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||
|
||
## 任务 53：将 rawRows 与 finalRows 的内存生命周期分段，避免同时长期驻留
|
||
|
||
**所属模块**：采集数据批处理与结果文件优化
|
||
**依赖**：52
|
||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||
|
||
### 功能点要求
|
||
- 围绕“将 rawRows 与 finalRows 的内存生命周期分段，避免同时长期驻留”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||
- 实现范围限定在 backend-java 的 collectdata 解析、品牌检查、ASIN 去重、结果项持久化和结果文件生成。
|
||
|
||
### 测试用例（必须先写，确认 RED）
|
||
1. `test_task_053_task_normal_default_path` — 使用正常输入验证“将 rawRows 与 finalRows 的内存生命周期分段，避免同时长期驻留”的默认成功路径和主输出。
|
||
2. `test_task_053_task_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||
3. `test_task_053_task_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||
4. `test_task_053_task_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||
5. `test_task_053_task_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||
6. `test_task_053_task_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||
7. `test_task_053_task_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||
8. `test_task_053_task_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||
|
||
### TDD 流程
|
||
|
||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||
|
||
### 验证方法
|
||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||
- 重点观察：backend-java 的 collectdata 解析、品牌检查、ASIN 去重、结果项持久化和结果文件生成。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||
|
||
## 任务 54：将 finalRowCount 从每个 chunk COUNT(*) 改为任务内增量计数
|
||
|
||
**所属模块**：采集数据批处理与结果文件优化
|
||
**依赖**：53
|
||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||
|
||
### 功能点要求
|
||
- 围绕“将 finalRowCount 从每个 chunk COUNT(*) 改为任务内增量计数”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||
- 实现范围限定在 backend-java 的 collectdata 解析、品牌检查、ASIN 去重、结果项持久化和结果文件生成。
|
||
|
||
### 测试用例（必须先写，确认 RED）
|
||
1. `test_task_054_chunk_normal_default_path` — 使用正常输入验证“将 finalRowCount 从每个 chunk COUNT(*) 改为任务内增量计数”的默认成功路径和主输出。
|
||
2. `test_task_054_chunk_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||
3. `test_task_054_chunk_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||
4. `test_task_054_chunk_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||
5. `test_task_054_chunk_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||
6. `test_task_054_chunk_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||
7. `test_task_054_chunk_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||
8. `test_task_054_chunk_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||
|
||
### TDD 流程
|
||
|
||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||
|
||
### 验证方法
|
||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||
- 重点观察：backend-java 的 collectdata 解析、品牌检查、ASIN 去重、结果项持久化和结果文件生成。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||
|
||
## 任务 55：将进度统计更新改为节流/合并写，减少高频 task UPDATE
|
||
|
||
**所属模块**：采集数据批处理与结果文件优化
|
||
**依赖**：54
|
||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||
|
||
### 功能点要求
|
||
- 围绕“将进度统计更新改为节流/合并写，减少高频 task UPDATE”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||
- 实现范围限定在 backend-java 的 collectdata 解析、品牌检查、ASIN 去重、结果项持久化和结果文件生成。
|
||
|
||
### 测试用例（必须先写，确认 RED）
|
||
1. `test_task_055_merge_progress_normal_default_path` — 使用正常输入验证“将进度统计更新改为节流/合并写，减少高频 task UPDATE”的默认成功路径和主输出。
|
||
2. `test_task_055_merge_progress_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||
3. `test_task_055_merge_progress_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||
4. `test_task_055_merge_progress_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||
5. `test_task_055_merge_progress_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||
6. `test_task_055_merge_progress_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||
7. `test_task_055_merge_progress_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||
8. `test_task_055_merge_progress_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||
|
||
### TDD 流程
|
||
|
||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||
|
||
### 验证方法
|
||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||
- 重点观察：backend-java 的 collectdata 解析、品牌检查、ASIN 去重、结果项持久化和结果文件生成。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||
|
||
## 任务 56：为采集结果文件增加流式写入失败后的临时文件清理
|
||
|
||
**所属模块**：采集数据批处理与结果文件优化
|
||
**依赖**：55
|
||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||
|
||
### 功能点要求
|
||
- 围绕“为采集结果文件增加流式写入失败后的临时文件清理”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||
- 实现范围限定在 backend-java 的 collectdata 解析、品牌检查、ASIN 去重、结果项持久化和结果文件生成。
|
||
|
||
### 测试用例（必须先写，确认 RED）
|
||
1. `test_task_056_collect_cleanup_normal_default_path` — 使用正常输入验证“为采集结果文件增加流式写入失败后的临时文件清理”的默认成功路径和主输出。
|
||
2. `test_task_056_collect_cleanup_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||
3. `test_task_056_collect_cleanup_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||
4. `test_task_056_collect_cleanup_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||
5. `test_task_056_collect_cleanup_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||
6. `test_task_056_collect_cleanup_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||
7. `test_task_056_collect_cleanup_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||
8. `test_task_056_collect_cleanup_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||
|
||
### TDD 流程
|
||
|
||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||
|
||
### 验证方法
|
||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||
- 重点观察：backend-java 的 collectdata 解析、品牌检查、ASIN 去重、结果项持久化和结果文件生成。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||
|
||
## 任务 57：为采集结果对象增加数据库删除与物理对象删除的一致性处理
|
||
|
||
**所属模块**：采集数据批处理与结果文件优化
|
||
**依赖**：56
|
||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||
|
||
### 功能点要求
|
||
- 围绕“为采集结果对象增加数据库删除与物理对象删除的一致性处理”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||
- 实现范围限定在 backend-java 的 collectdata 解析、品牌检查、ASIN 去重、结果项持久化和结果文件生成。
|
||
|
||
### 测试用例（必须先写，确认 RED）
|
||
1. `test_task_057_collect_normal_default_path` — 使用正常输入验证“为采集结果对象增加数据库删除与物理对象删除的一致性处理”的默认成功路径和主输出。
|
||
2. `test_task_057_collect_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||
3. `test_task_057_collect_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||
4. `test_task_057_collect_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||
5. `test_task_057_collect_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||
6. `test_task_057_collect_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||
7. `test_task_057_collect_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||
8. `test_task_057_collect_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||
|
||
### TDD 流程
|
||
|
||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||
|
||
### 验证方法
|
||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||
- 重点观察：backend-java 的 collectdata 解析、品牌检查、ASIN 去重、结果项持久化和结果文件生成。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||
|
||
## 任务 58：补充外部品牌服务不可用、RustFS 超时和重复 chunk 的降级测试
|
||
|
||
**所属模块**：采集数据批处理与结果文件优化
|
||
**依赖**：57
|
||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||
|
||
### 功能点要求
|
||
- 围绕“补充外部品牌服务不可用、RustFS 超时和重复 chunk 的降级测试”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||
- 实现范围限定在 backend-java 的 collectdata 解析、品牌检查、ASIN 去重、结果项持久化和结果文件生成。
|
||
|
||
### 测试用例（必须先写，确认 RED）
|
||
1. `test_task_058_chunk_brand_rustfs_normal_default_path` — 使用正常输入验证“补充外部品牌服务不可用、RustFS 超时和重复 chunk 的降级测试”的默认成功路径和主输出。
|
||
2. `test_task_058_chunk_brand_rustfs_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||
3. `test_task_058_chunk_brand_rustfs_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||
4. `test_task_058_chunk_brand_rustfs_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||
5. `test_task_058_chunk_brand_rustfs_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||
6. `test_task_058_chunk_brand_rustfs_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||
7. `test_task_058_chunk_brand_rustfs_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||
8. `test_task_058_chunk_brand_rustfs_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||
|
||
### TDD 流程
|
||
|
||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||
|
||
### 验证方法
|
||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||
- 重点观察：backend-java 的 collectdata 解析、品牌检查、ASIN 去重、结果项持久化和结果文件生成。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||
|
||
## 任务 59：完成采集模块数据库索引、批量 SQL 和对象存储调用次数验证
|
||
|
||
**所属模块**：采集数据批处理与结果文件优化
|
||
**依赖**：58
|
||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||
|
||
### 功能点要求
|
||
- 围绕“完成采集模块数据库索引、批量 SQL 和对象存储调用次数验证”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||
- 实现范围限定在 backend-java 的 collectdata 解析、品牌检查、ASIN 去重、结果项持久化和结果文件生成。
|
||
|
||
### 测试用例（必须先写，确认 RED）
|
||
1. `test_task_059_collect_object_storage_normal_default_path` — 使用正常输入验证“完成采集模块数据库索引、批量 SQL 和对象存储调用次数验证”的默认成功路径和主输出。
|
||
2. `test_task_059_collect_object_storage_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||
3. `test_task_059_collect_object_storage_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||
4. `test_task_059_collect_object_storage_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||
5. `test_task_059_collect_object_storage_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||
6. `test_task_059_collect_object_storage_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||
7. `test_task_059_collect_object_storage_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||
8. `test_task_059_collect_object_storage_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||
|
||
### TDD 流程
|
||
|
||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||
|
||
### 验证方法
|
||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||
- 重点观察：backend-java 的 collectdata 解析、品牌检查、ASIN 去重、结果项持久化和结果文件生成。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||
|
||
## 任务 60：完成采集模块 10k 行压测并验收结果完整性、内存和吞吐
|
||
|
||
**所属模块**：采集数据批处理与结果文件优化
|
||
**依赖**：59
|
||
**预估耗时**：8-15 分钟（写测试 + 实现 + 自测）
|
||
|
||
### 功能点要求
|
||
- 围绕“完成采集模块 10k 行压测并验收结果完整性、内存和吞吐”实现一个独立、可验证的功能点，不扩大到同模块其他未完成任务。
|
||
- 输入、输出、异常和资源上限必须明确；空输入、单元素、最大允许值和超限值必须有确定行为。
|
||
- 成功路径必须保留现有业务语义、幂等性和兼容字段；失败路径必须释放临时文件、连接、锁、线程任务和未引用对象。
|
||
- 实现范围限定在 backend-java 的 collectdata 解析、品牌检查、ASIN 去重、结果项持久化和结果文件生成。
|
||
|
||
### 测试用例（必须先写，确认 RED）
|
||
1. `test_task_060_collect_normal_default_path` — 使用正常输入验证“完成采集模块 10k 行压测并验收结果完整性、内存和吞吐”的默认成功路径和主输出。
|
||
2. `test_task_060_collect_normal_multiple_items` — 使用多个任务、行、chunk 或页面状态验证批量场景下结果不丢失且顺序稳定。
|
||
3. `test_task_060_collect_normal_repeated_operation_is_idempotent` — 重复执行同一输入，验证不会产生重复记录、重复对象、重复请求或重复 UI 状态。
|
||
4. `test_task_060_collect_boundary_empty_input` — 空集合、空字符串或无可处理数据时验证返回空结果/安全跳过，不创建无效资源。
|
||
5. `test_task_060_collect_boundary_single_item` — 单任务、单行、单图片或单页面状态时验证不依赖批量路径且结果正确。
|
||
6. `test_task_060_collect_boundary_limit_and_overflow` — 达到最大配置值以及超过最大值时验证限流、拒绝或降级行为，不发生无界内存增长。
|
||
7. `test_task_060_collect_invalid_input_rejected` — 非法参数、缺少必填字段或格式错误时验证抛出项目约定异常及可识别错误消息。
|
||
8. `test_task_060_collect_dependency_failure_releases_resources` — mock 数据库/Redis/RustFS/HTTP/文件依赖失败后验证错误可恢复，临时资源、锁和队列任务均释放。
|
||
|
||
### TDD 流程
|
||
|
||
1. 先写上述全部测试，运行项目测试命令，确认该功能测试 **RED**；如果测试一开始通过，必须先检查测试是否真正覆盖待实现行为。
|
||
2. 实现功能，运行该任务定向测试和相关模块测试，确认 **GREEN**。
|
||
3. 执行 lint/format、编译或前端构建检查，确保没有新增错误。
|
||
4. 完成资源释放、异常路径和兼容性验证后创建该任务对应 commit。
|
||
|
||
### 验证方法
|
||
- `mvn -q test` 通过；涉及模块时补充定向测试命令。
|
||
- 涉及 I/O、外部服务或数据库时，必须再执行 mock 测试和真实集成/启动调用，并记录资源释放结果。
|
||
- 重点观察：backend-java 的 collectdata 解析、品牌检查、ASIN 去重、结果项持久化和结果文件生成。中的功能结果正确，且 CPU、堆内存、GC、数据库/对象存储调用次数和临时磁盘占用没有超过任务设定上限。
|
||
|
||
## 模块完成 Gate
|
||
|
||
- 20 个任务全部有对应 commit，任务状态均更新为 `done` 前不得开始下一个模块。
|
||
- 运行模块定向测试、项目全量测试和 lint/format；真实依赖调用、异常降级和资源释放均有记录。
|
||
- 运行模块对应的性能基准，记录吞吐、P95/P99 延迟、峰值堆、GC、CPU、DB QPS、Redis/RustFS QPS 和临时磁盘。
|