zhixing-system/.trellis/tasks/archive/2026-08/08-12-optimize-selection-execution-performance/implement.md

实现计划：选股执行性能优化

Phase 1：基线与配置

1. 增加 selection_max_workers=4 和 selection_batch_size=200 配置，并同步 .env.example、开发/生产 compose 的可配置环境变量。
2. 为运行执行器增加 read/evaluate/persist 的安全汇总计时；不要输出单股行情或 凭据。
3. 先运行现有 selection 测试，记录基线；确认工作区中没有用户并行改动。

Phase 2：连接池与批量存储

4. 新增 selection PostgreSQL pool resource owner，支持注入 fake pool、open/close 和借用连接；在 presentation 组合层按数据库配置缓存并注册退出清理。
5. 改造 PostgresMarketDataReader 和 PostgresSelectionRunRepository 使用共享 pool，同时保留直接构造/测试兼容路径。
6. 在 SelectionRunStore 增加 record_items；实现 chunk 内一次事务、item executemany、signal executemany 和重试幂等删除。
7. 更新应用层 FakeStore、PostgreSQL adapter tests，锁定每批写入的 SQL 数量和 独立 signal 不丢失。

Phase 3：批量读取与四 worker

8. 在 reader 的可选批量扩展和 EvaluateZhixingB1 测试 seam 中加入批量 history 读取/已有 history 评估能力；保持单股 execute 兼容。
9. 实现按 ts_code 分组的 qfq 批量 SQL，移除当前 B1 不使用的历史 daily-basic join/字段，保留执行源的目标日 basic 完整性校验。
10. 将 RunZhixingB1.execute 改为 200 股票分块：批量读、4 worker 评估、聚合、批量 写入；批量扩展缺失时 fallback 到旧单股/单项接口；保留单股异常隔离和最终状态统计。
11. 增加批量读取、缺失 history、worker 异常、重复批次写入和结果顺序稳定性测试。

Phase 4：质量门禁与实测

12. 运行 selection 单元/golden/HTTP 测试，确认七类独立信号和重跑契约不变。
13. 如 PostgreSQL 环境可用，使用固定目标日运行一次真实 harness，记录 worker=1 与 worker=4 的 read/evaluate/persist 以及总耗时；检查连接数没有超过 pool 上限。
14. 运行完整后端格式、lint、type-check、pytest；必要时运行根目录 check/test。
15. 检查 diff 只包含本任务文件，确认不包含 Redis 或无关前端改动。

主要验证命令

cd zhixing-server
uv run pytest tests/unit/selection tests/integration/test_zhixing_b1_golden.py -q
uv run pytest tests/test_selection_http.py -q
uv run ruff format --check .
uv run ruff check .
uv run pyright
uv run pytest

风险与回滚点

• pool 生命周期：先用 fake pool 测试 open/close，再接入 HTTP dependency；发生资源 泄漏时回滚组合层缓存，不动公式。
• 批量 SQL：先保持旧单股 reader/record wrapper，批量路径验证通过后再切换应用调用。
• 线程 worker：先以 max_workers=1 验证结果等价，再使用默认 4；任何状态/信号差异 都回滚并发切换，保留批量读取/写入的独立改动。
• 内存：固定分块 200 并在每批完成后释放 histories；如果真实数据峰值过高，先调低 selection_batch_size，不增加 Redis。