kyugao
ec02a791ee
- R-027 静态化：策略恒为内置两项（不可增删改名，保留显隐/排序）；设置页移除「策略分组」； 字段配置入口迁到策略 tab 内「列设置」旁（FieldConfigDialog + schema-update 单策略写入） - R-026 计算字段：自写公式引擎（中文变量、四则/括号/round·abs·min·max、缺值短路→—）+ 变量目录（行情/合约/持仓/自定义字段）+ strategy-positions 逐行现算（只读内存缓存，不落库、列只读） - R-028 判定型：比较运算 + and/or + inferResultKind + 结果类型一致性校验 + 判定列 ✓/— 渲染； 网格超市落地 可下空单=涨停价>基准值+网格大小、可下多单=跌停价<基准值-网格大小 - 变量选择改标签平铺（老师反馈）；公式手册 docs/99-其他材料/计算字段公式说明.md - 约束同步：产品约束-002/003/004/009/013/014、技术约束-014/015/022/023/024、UI约束-002/003/005/008 - 回归：新增 test-r026/test-r027，更新 r011/r013/r017，17 个脚本全绿；typecheck/build 通过
47 lines
5.4 KiB
Markdown
47 lines
5.4 KiB
Markdown
# 迭代复盘：12-持仓内存快照（服务端 10s 定时同步，请求不再穿透 QMT）
|
||
|
||
> 复盘日期：2026-09-02 ｜ 迭代状态：**已实施，待老师人工验收**
|
||
> 关联需求：R-014（持仓内存快照，已定稿）
|
||
> 关联计划：PLAN-013（计划-持仓内存快照）
|
||
|
||
## 结果
|
||
|
||
迭代 12 达成：服务端建全量持仓**内存快照**（PositionSync，10s 定时全量同步，**不落库**），策略持仓 / 全部持仓 / 未分配三个接口改读快照为准；同步失败保留上次快照（QMT 抖动不再白屏）；空快照双重确认（health + 账户身份）；快照为空读穿透兜底；**幽灵持仓自动清仓**（连续 3 轮消失 + 账户身份守卫防误清）。前端零改动，SQLite 零 schema 变更。
|
||
|
||
## 过程事实
|
||
|
||
1. **起因（架构梳理讨论）**：老师要求梳理持仓/实盘数据存储与同步机制 → 梳理结论「本地数据准确性靠打开 tab 时与实盘当场对账，无对账任务、无修正、无告警」+ 幽灵持仓盲区（QMT 卖光的票本地账本仍记着，UI 隐身）→ 老师提出优化方向（服务端缓存 + 10s 同步 + 策略持仓改读缓存）；
|
||
2. **方案反转（落库 → 内存）**：AI 初版方案建 positions_cache 表（惯性抄 market_quotes_cache / trade_fills 先例）；老师质疑是否可复用 strategy_holdings 或放内存 → AI 论证修正：**判断落库的标准是「数据能否随时一次调用重拿全」**，持仓快照满足，落库反引入「过期快照冒充实时的说谎风险」；strategy_holdings 是账本不可掺对账单（holding_id 是交易归属锚点）→ 定稿纯内存方案；
|
||
3. **四问拍板**（老师，2026-09-02）：① 内存不落库；② 读穿透兜底（首启/QMT 从未连上时当场拉一次并回填）；③ 幽灵持仓同步时自动清仓（加防抖护栏）；④ 同步时间前端本轮不显示；
|
||
4. **实现**：PositionSync（快照 + 定时 + 空快照双确认 + 幽灵清仓防抖 + 账户守卫 + stats）、PositionManager.getAllPositions 读快照 + 读穿透 + 未注入兼容、index.js 装配、回归脚本 34 项；
|
||
5. **修复两处**（测试驱动发现）：syncNow 的 mounted 守卫拦住了手动同步（测试直接调用返回 null）→ 移除该守卫（mounted 只管定时循环，手动同步/热切换后刷新不受限）；账户切换守卫从「重置后当轮继续计数」收紧为「当轮直接跳过」（旧账户快照不可信）；
|
||
6. **验证**：typecheck + build 通过；test-position-sync 34/34；test-r013-custom-fields 21/21（未注入 positionSync 旧行为兼容证明）；
|
||
7. **文档链补全**（先实施后补档）：R-014 + PLAN-013 + 迭代三件套 + 技术约束-017 + 数据存储设计.md §11；修正一处归档操作（R-014 未验收先写了 已完成/，按规范移回需求池根目录）。
|
||
|
||
## 经验教训（复盘沉淀）
|
||
|
||
### 1. 「抄先例」要过适用性检查
|
||
- 行情缓存落库（重启首屏有价）与交易落库（QMT 只有当日数据，不存即丢）各有硬理由；持仓快照两个理由都不占。判断标准沉淀：**外部可重取的实时投影不落库**（落库换不来任何能力，只带来说谎风险）；
|
||
- 数据该放哪一层，先问三个问题：不可再生吗？重启首屏依赖吗？有读放大或复杂查询需求吗？——全否 → 内存。
|
||
|
||
### 2. 账本与对账单分离
|
||
- strategy_holdings（人为分配、生命周期、holding_id 锚点）与实盘持仓快照（外部投影、易变）是两类数据；复用同一张表会污染交易归属链。合并的诱惑来自「都是持仓」，分辨的依据是「谁写、谁信、活了多久」。
|
||
|
||
### 3. 幽灵清仓的误清防线 = 防抖 × 身份守卫
|
||
- 单纯「消失即清仓」在 QMT 半可用（未登录返回空）和账户热切换两个场景都会误清；连续 3 轮 + accountId 守卫（未知跳过 / 切换重置跳过）把误清窗口压到可忽略；
|
||
- 沉淀：**对「删/清」类自动化动作，默认加两道独立护栏再上**。
|
||
|
||
### 4. mounted 守卫的语义边界
|
||
- 定时器服务的 mounted 应只表达「定时循环是否运行」，不应拦截手动触发（syncNow/sync 类方法）；否则测试、手动刷新、热切换后的即时同步全被误伤。
|
||
|
||
### 5. 先实施后补档的可行边界
|
||
- 本迭代代码在讨论中当场落地、文档事后补全；补档过程顺畅依赖两点：讨论中老师拍板结论明确（四问有记录）+ 实现严格按结论执行无偏移。若讨论结论含糊，不允许先实施（文档先行约束不破）。
|
||
|
||
## 遗留/后续
|
||
|
||
1. **部分减持的自动修正**（未分配负数仍靠 UI 暴露，人工「移出」修正）：如需「检测账实不符 → 提示一键按实盘修正」可另立需求；
|
||
2. **同步时间前端显示**：老师拍板本轮不做；如持仓滞后感知需要，可加「更新于 HH:mm:ss」小标注（后端 syncedAt 已就绪）；
|
||
3. **既有观察点未动**（另行登记评估）：getStrategyPositions 的 N+1 委托查询（可改 IN 一次查）；src/api/trades.js orders 端点绕 DataStore 门面直摸 sqlite.db（层级破洞）；calcOrderFees 数据源/前端双实现（可收敛）；数据存储设计.md §9.1 库文件名（one-divine-lot.db vs 实际 store.db）等历史偏差。
|
||
## 验收状态更新（2026-09-08）
|
||
> 老师 2026-09-08 归档指令：确认验收并归档；R-014 已按归档清单移入 05-需求池/已完成/。
|