22787b3e0a
- Generate full AI-consumable docs (docs/ai/): system overview, architecture, module cheatsheet, API contracts, data model, build guide, decision log, glossary, and open questions (deep tier coverage) - Add PROBLEM_REPORT.md: categorized bug/risk summary - Add DETAILED_CODE_REVIEW.md: full line-by-line review of all 15 backend files, documenting 4 fatal issues, 5 critical deployment bugs, 4 security vulnerabilities, and 6 architecture defects with prioritized fix plan
142 lines
6.7 KiB
Markdown
142 lines
6.7 KiB
Markdown
---
|
||
generated_by: repo-insight
|
||
version: 1
|
||
created: 2026-03-03
|
||
last_updated: 2026-03-03
|
||
source_commit: 0d9dffa
|
||
coverage: deep
|
||
---
|
||
|
||
# 99 — Open Questions
|
||
|
||
## Purpose
|
||
记录文档生成过程中发现的未解决问题、不确定点和潜在风险。
|
||
|
||
## TL;DR
|
||
- `requirements.txt` 不完整，实际依赖需手动补齐。
|
||
- `users` 表在两个地方定义且 schema 不一致（db.py vs auth.py）。
|
||
- live_executor / risk_guard 直连 Cloud SQL 但 signal_engine 写本地 PG，存在数据同步延迟风险。
|
||
- 策略是否支持热重载（每次循环重读 JSON）未确认。
|
||
- uvicorn 监听端口 4332 未在启动脚本中显式确认。
|
||
- 无 CI/CD，无自动化测试。
|
||
|
||
## Open Questions
|
||
|
||
### 高优先级（影响正确性）
|
||
|
||
#### Q1：users 表 schema 双定义不一致
|
||
**问题**：`db.py` 的 `SCHEMA_SQL` 和 `auth.py` 的 `AUTH_SCHEMA` 均定义了 `users` 表，但字段不同：
|
||
- `db.py` 版本：`id, email, password_hash, role, created_at`（无 `discord_id`、无 `banned`）
|
||
- `auth.py` 版本：`id, email, password_hash, discord_id, role, banned, created_at`
|
||
|
||
`init_schema()` 和 `ensure_auth_tables()` 都在 FastAPI startup 中调用，两次 `CREATE TABLE IF NOT EXISTS` 第一次成功后第二次静默跳过。**实际创建的是哪个版本？** 取决于调用顺序（先 `init_schema` 后 `ensure_auth_tables`），如果本地 PG 已有旧版表则字段可能缺失。
|
||
|
||
**影响**：auth 相关功能（discord_id 关联、banned 状态检查）可能在 schema 未更新的环境下失效。
|
||
|
||
**建议行动**：统一到 auth.py 版本，或添加 `ALTER TABLE ... ADD COLUMN IF NOT EXISTS` 迁移。
|
||
|
||
**来源**：`db.py:269-276`，`auth.py:28-37`
|
||
|
||
---
|
||
|
||
#### Q2：live_executor 读 Cloud SQL，signal_engine 写本地 PG，双写延迟是否可接受
|
||
**问题**：signal_engine 写入本地 PG（`signal_indicators`），同时双写 Cloud SQL；live_executor 直连 Cloud SQL 读取信号。若某次双写失败或延迟，live_executor 可能错过信号或读到不一致数据。
|
||
|
||
**影响**：实盘信号丢失或执行延迟。
|
||
|
||
**建议行动**：确认 NOTIFY 是否也发送到 Cloud SQL（即 live_executor 通过 LISTEN 接收信号，不依赖轮询读表）；或将 live_executor 改为连接本地 PG。
|
||
|
||
**来源**：`live_executor.py:50-55`，`db.py:76-95`
|
||
|
||
---
|
||
|
||
#### Q3：requirements.txt 不完整
|
||
**问题**：`requirements.txt` 只列出 `fastapi, uvicorn, httpx, python-dotenv, psutil`，但源码还 import 了 `asyncpg`、`psycopg2`（用于 psycopg2-binary）、`aiohttp`、`websockets`（推断）等。
|
||
|
||
**影响**：新环境安装后进程无法启动。
|
||
|
||
**建议行动**：执行 `pip freeze > requirements.txt` 或手动补全所有依赖。
|
||
|
||
**来源**：`backend/requirements.txt:1-5`，`backend/db.py:9-11`，`backend/live_executor.py:28-29`
|
||
|
||
---
|
||
|
||
### 中优先级（影响维护性）
|
||
|
||
#### Q4：策略 JSON 是否支持热重载
|
||
**问题**：`load_strategy_configs()` 在 `main()` 函数开头调用一次。不清楚 signal_engine 的主循环是否每次迭代都重新调用此函数。
|
||
|
||
**影响**：如果不支持热重载，修改策略 JSON 后需要重启 signal_engine 进程。
|
||
|
||
**来源**：`signal_engine.py:44-67, 964`（需查看 main 函数结构）
|
||
|
||
---
|
||
|
||
#### Q5：uvicorn 端口确认
|
||
**问题**：从 `frontend/next.config.ts` 推断 uvicorn 运行在 `127.0.0.1:4332`，但没有找到后端启动脚本明确指定此端口。
|
||
|
||
**建议行动**：在 `ecosystem.dev.config.js` 或启动脚本中显式记录端口。
|
||
|
||
**来源**：`frontend/next.config.ts:8`
|
||
|
||
---
|
||
|
||
#### Q6：market_indicators 表 schema 未在 SCHEMA_SQL 中定义
|
||
**问题**：signal_engine 从 `market_indicators` 表读取数据（指标类型：`long_short_ratio`, `top_trader_position`, `open_interest_hist`, `coinbase_premium`, `funding_rate`），但该表的 CREATE TABLE 语句不在 `db.py` 的 `SCHEMA_SQL` 中。
|
||
|
||
**影响**：表由 `market_data_collector.py` 单独创建；如果该进程未运行过，表不存在，signal_engine 会报错或返回空数据。
|
||
|
||
**建议行动**：将 `market_indicators` 表定义加入 `SCHEMA_SQL`，确保 `init_schema()` 能覆盖全量 schema。
|
||
|
||
**来源**：`signal_engine.py:123-158`，`db.py:166-357`（未见 market_indicators 定义）
|
||
|
||
---
|
||
|
||
#### Q7：liquidations 表 schema 未确认
|
||
**问题**：signal_engine 查询 `liquidations` 表（`SELECT FROM liquidations WHERE symbol=%s AND trade_time >= %s`），但该表定义在 `SCHEMA_SQL` 中同样未找到。可能由 `liquidation_collector.py` 自行创建。
|
||
|
||
**来源**：`signal_engine.py:395-407`，`liquidation_collector.py:28`（`ensure_table()` 函数）
|
||
|
||
---
|
||
|
||
### 低优先级（长期健康度）
|
||
|
||
#### Q8：无 CI/CD 流水线
|
||
**问题**：仓库中没有 `.github/workflows/`、Dockerfile、docker-compose.yml 等部署自动化文件。所有部署为手动操作（ssh + git pull + pm2 restart）。
|
||
|
||
**建议行动**：添加 GitHub Actions 用于基本 lint 检查和依赖安全扫描。
|
||
|
||
---
|
||
|
||
#### Q9：无自动化测试
|
||
**问题**：未发现任何测试文件（`test_*.py`、`*.test.ts` 等）。策略验证完全依赖人工回测和模拟盘。
|
||
|
||
**建议行动**：至少为 `evaluate_signal()`、`TradeWindow`、`ATRCalculator` 添加单元测试，防止重构回归。
|
||
|
||
---
|
||
|
||
#### Q10：生产环境硬编码密码风险
|
||
**问题**：`db.py`、`live_executor.py`、`risk_guard.py` 中均有 testnet 默认密码 `arb_engine_2026` 硬编码在源代码里（通过 `os.getenv(..., "arb_engine_2026")` 方式）。
|
||
|
||
**影响**：代码一旦泄露，testnet 数据库可被访问；生产环境如果环境变量设置失败，会静默使用错误密码（失败时的错误信息较明确，但仍有风险）。
|
||
|
||
**建议行动**：testnet 默认密码移除或通过单独的 `.env.testnet` 文件管理，不内嵌到源代码。
|
||
|
||
**来源**：`db.py:19`，`live_executor.py:44`，`risk_guard.py:42`
|
||
|
||
---
|
||
|
||
#### Q11：`signal_indicators` 表含 `strategy` 字段但 schema 未声明
|
||
**问题**：`save_indicator()` 函数的 INSERT 语句包含 `strategy` 字段，但 `SCHEMA_SQL` 中的 `signal_indicators` 表定义不包含该字段。可能通过 `ALTER TABLE ADD COLUMN IF NOT EXISTS` 在运行时补充，或是后续版本添加但忘记更新 schema。
|
||
|
||
**来源**：`signal_engine.py:690-699`，`db.py:205-224`（signal_indicators 定义）
|
||
|
||
## Source Refs
|
||
- `backend/db.py:269-276` — db.py 版 users 表
|
||
- `backend/auth.py:28-37` — auth.py 版 users 表（含 discord_id, banned）
|
||
- `backend/requirements.txt` — 不完整的依赖列表
|
||
- `backend/live_executor.py:44, 50-55` — DB_HOST 和默认密码
|
||
- `backend/risk_guard.py:42, 47-53` — DB_HOST 和默认密码
|
||
- `backend/signal_engine.py:395-407` — liquidations 表查询
|
||
- `backend/signal_engine.py:690-699` — strategy 字段 INSERT
|