# 交易 SDK 成交推送去重与排序优化
## 修复提交

| 仓库 | 分支 | Commit ID | 说明 |
| --- | --- | --- | --- |
| `harmony-ths-futures` | `work-20260818-clz-FUHM-1979-apm-appfreeze` | `ce0719178530b5ca64272c6c1e90b5bcdb8297fc` | 接入本地 `libs/FuTrade-1.0.13-match-push-opt.har`（含成交推送去重与排序） |
| `harmony_futures_trade_sdk` | `feature/FUHM-1979-match-push-optimization` | `9e56923cfaadb14fff0fa928cabe4e5aef615490` | 优化成交推送处理（去重与稳定排序） |
| `harmony_futures_trade_sdk` | `feature/FUHM-1979-match-push-optimization` | `31256eff45b51a96551a2ba8f2b31bb02e4258af` | 优化推送缓存查重 |

SDK 侧成交推送去重/排序来源于 `harmony_futures_trade_sdk` 仓库上述源码提交，本仓库以本地 HAR 携带，接入提交见上表首行。

## 问题

成交推送进入 `MatchOrderSummary.updateMatchOrders()` 时，旧逻辑需要遍历全部成交记录判断重复成交，并在每次新增后对完整数组执行一次排序。成交推送频繁或历史成交较多时，会重复消耗 CPU，并增加成交列表更新的耗时。


## 优化方案

1. 在 `MatchOrderSummary` 中增加 `Set<string>`，缓存已有成交的 `matchIdentify().identify`。重复推送直接通过 `Set.has()` 过滤，避免遍历成交数组。
2. 首次新增推送仍执行完整排序，确保查询结果初始顺序不确定时可以恢复到成交排序规则。
3. 首次排序完成后，后续推送使用二分查找确定插入位置，再插入 `matchOrderRsps`，避免每次对全部成交记录重新排序。
4. 二分插入在比较结果相同时继续向后查找，使相同成交时间和开平方向的记录保持稳定顺序。
5. 增加单元测试，覆盖重复成交、稳定排序插入和不同账号推送过滤。

## 影响范围

- 交易 SDK 的成交汇总、成交推送和成交列表排序。
- 当前项目通过本地 `libs/FuTrade-1.0.13-match-push-opt.har` 使用该版本，依赖配置位于根目录 `oh-package.json5`。
- 成交量、平仓盈亏、盯市平仓盈亏的汇总规则不变。
- 账号过滤规则和成交唯一标识规则不变；`Set` 仅用于查重，不参与成交列表排序。

## 预期收益与边界

重复推送判断由数组遍历变为近似 O(1)，后续新增成交由全量排序变为二分查找加数组插入。优化主要针对高频成交推送和较大历史成交列表，业务展示顺序不应发生变化。

`matchOrderRsps` 仍是公开可变数组。如果外部代码直接修改、排序或替换数组内容，可能导致成交数组、去重 `Set` 和有序状态不一致；业务代码应通过 SDK 的成交汇总接口读取，避免直接修改该数组。初始查询数据中的重复项也不会由本次改动主动清理。

## 验证建议

### 单元测试

在交易 SDK 的 `FuTrade` 模块运行 `MatchOrderSummary` 测试，确认以下场景：

- 相同成交推送只保留一条，汇总值不重复增加；
- 首次推送后成交记录按既有时间和开平方向规则排序；
- 后续推送插入到正确位置，相同排序值保持稳定顺序；
- 不同账号的成交推送被过滤；
- 空初始列表、白盘/夜盘边界和不同开平方向均可正常插入。

### 当前项目验证

确认 `oh-package.json5` 指向本地 HAR 后，执行：

```bash
./claude_tool/claude_compile.sh
```

并在成交页面回归查询成交、接收新成交推送、重复推送和账号切换，检查成交条数、成交量、盈亏汇总及列表顺序均保持正确。