update api,libs
This commit is contained in:
82
docs/todo.md
82
docs/todo.md
@@ -1,5 +1,87 @@
|
||||
|
||||
|
||||
### 4.2 IPO 没有校验真实交易日,只判断周一至周五和盘中时间
|
||||
|
||||
位置:
|
||||
|
||||
- `py-client/strategy/ipo/boot.py:27`
|
||||
- `py-client/libs/calc.py:5-7`
|
||||
|
||||
`trading_time()` 只排除周末,法定节假日、临时休市仍会进入申购逻辑。模块中已有 `TRADING_CALENDAR_SYMBOL` 常量,但没有实际查询交易日接口。
|
||||
|
||||
建议:调用 SDK 的 `trading_dates()` 验证当天交易日;接口失败时按安全策略跳过,不应猜测为交易日。
|
||||
|
||||
### 4.8 启动脚本仍会强制终止机器上的所有 Python 进程
|
||||
|
||||
位置:`run.bat:1-7`
|
||||
|
||||
`taskkill /IM python.exe /F` 不区分项目和 PID;`python main.py` 又依赖调用时工作目录。它可能杀死无关任务后仍因找不到根目录下的 `main.py` 而启动失败。
|
||||
|
||||
建议:只管理本项目 PID;脚本先切换至 `%~dp0py-client`;生产启动不要无条件 `git pull`。
|
||||
|
||||
## 5. P2:代码冗余与过度验证
|
||||
|
||||
### 5.1 两份 API 文件逐字节重复,正式入口被删除
|
||||
|
||||
位置:
|
||||
|
||||
- `api/qmt_api_new.py`
|
||||
- `api/qmt_api_rele.py`
|
||||
- 当前处于删除状态的 `api/QMT_API.py`
|
||||
|
||||
两个新文件 SHA-256 相同,属于完整重复;原正式文件被删除,启动和部署入口不清晰。继续维护会造成修复只落在其中一份的风险。
|
||||
|
||||
建议:保留唯一正式文件,版本差异交给 Git 管理。
|
||||
|
||||
### 5.2 IPO 模块保留大量未使用的设计残留
|
||||
|
||||
位置:`py-client/strategy/ipo/boot.py:5-19`
|
||||
|
||||
`json`、`Any`、`IPO_STRATEGY_NAME`、`IPO_REMARKS`、`IPO_SESSIONS`、`TRADING_CALENDAR_SYMBOL` 当前均未使用。它们与测试要求一起表明完整对账实现被缩减,但残留符号没有同步整理。
|
||||
|
||||
建议:先恢复交易日、券商对账和统计逻辑,再清除确认无用的符号,不要只做表面删减。
|
||||
|
||||
### 3.5 开仓金额可能超过配置值,同轮多信号会重复使用现金
|
||||
|
||||
位置:
|
||||
|
||||
- `py-client/libs/calc.py:10-12`
|
||||
- `py-client/strategy/trend/boot.py:119-164`
|
||||
- `py-client/strategy/trend/open.py:41-70`
|
||||
|
||||
`calc_buy_volume()` 在预算不足一手时仍强制返回 100 股。趋势开仓仅检查一次现金比例,没有校验单笔预计金额,也没有为同一轮后续信号扣减已提交订单占用的资金。
|
||||
|
||||
影响:高价股单笔超出 `buy_value`;多信号集中出现时可能发送总额超过可用资金的委托。
|
||||
|
||||
建议:不足一手返回 0;开仓入口维护本轮共享 `remaining_cash`,成功提交后立即预留资金,并考虑价格滑点。
|
||||
|
||||
### 3.2 IPO 仅依赖本地空文件防重,锁丢失或落盘失败会重复申购
|
||||
|
||||
位置:
|
||||
|
||||
- `py-client/strategy/ipo/boot.py:37-51`
|
||||
- `py-client/libs/lockfile.py:9-18`
|
||||
|
||||
当前实现没有查询 `trade_detail_data("order")` 或 `deals()`,也没有按账户、交易日和申购备注对账。本地锁文件被清理、数据目录切换、写入失败或下单成功后进程崩溃时,下一次任务会再次提交同一新股。
|
||||
|
||||
影响:产生重复申购请求;实际结果取决于券商拦截,不能把安全性寄托在券商拒单上。
|
||||
|
||||
建议:本地记录只能作为快速幂等缓存,最终防重必须以“账户 + 交易日 + 证券代码”的券商委托/成交记录为准;下单前后二次核对。
|
||||
|
||||
### 3.4 开仓可能超过单笔配置金额,多信号还会重复使用同一份现金
|
||||
|
||||
位置:
|
||||
|
||||
- `py-client/libs/calc.py:10-12`
|
||||
- `py-client/strategy/trend/boot.py:119-164`
|
||||
- `py-client/strategy/trend/open.py:41-70`
|
||||
|
||||
`calc_buy_volume()` 使用 `max(1, floor(...)) * 100`。当 `buy_value < price * 100` 时,它不是返回 0,而是强制购买 100 股,实际金额必然超过 `buy_value`。趋势开仓只检查一次总账户现金比例,没有检查单笔预计金额是否小于可用现金,也没有在同一轮多个信号之间扣减已预留资金。
|
||||
|
||||
影响:高价股或同轮多信号可能导致单笔超预算、连续发送超过可用资金的委托,产生券商拒单或非预期仓位。
|
||||
|
||||
建议:预算不足一手时返回 0;像补仓路径一样维护本轮 `remaining_cash`;每次成功提交后立即预留 `price * volume`,并给价格滑点留安全余量。
|
||||
|
||||
### 2.1 每次启动都会无条件执行新股申购
|
||||
|
||||
整改状态:已于 2026-08-29 按本节方案完成,新增 4 项专项测试。
|
||||
|
||||
Reference in New Issue
Block a user