miracle/auto_trade_sys
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

a

Browse Source
This commit is contained in:
薇薇安 2026-01-27 10:36:56 +08:00
parent d4edc16f43
commit 9fe028d704
37 changed files with 7460 additions and 24 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
backend/config_manager.py
View File

@ -806,12 +806,12 @@ class ConfigManager:
# 风险控制
'STOP_LOSS_PERCENT': eff_get('STOP_LOSS_PERCENT', 0.12), # 默认12%（2026-01-27优化：收紧止损，减少单笔亏损）
'TAKE_PROFIT_PERCENT': eff_get('TAKE_PROFIT_PERCENT', 0.20), # 默认20%（2026-01-27优化：降低止盈目标，更容易触发，提升止盈单比例）
'TAKE_PROFIT_PERCENT': eff_get('TAKE_PROFIT_PERCENT', 0.10), # 默认10%（2026-01-27优化：进一步降低止盈目标，更容易触发，提升止盈单比例）
'MIN_STOP_LOSS_PRICE_PCT': eff_get('MIN_STOP_LOSS_PRICE_PCT', 0.02), # 默认2%
'MIN_TAKE_PROFIT_PRICE_PCT': eff_get('MIN_TAKE_PROFIT_PRICE_PCT', 0.02), # 默认2%（防止ATR过小时计算出不切实际的微小止盈距离）
'USE_ATR_STOP_LOSS': eff_get('USE_ATR_STOP_LOSS', True), # 是否使用ATR动态止损
'ATR_STOP_LOSS_MULTIPLIER': eff_get('ATR_STOP_LOSS_MULTIPLIER', 2.0), # ATR止损倍数2.0（容忍山寨币高波动）
'ATR_TAKE_PROFIT_MULTIPLIER': eff_get('ATR_TAKE_PROFIT_MULTIPLIER', 3.0), # ATR止盈倍数3.0（2026-01-27优化：降低，更容易触发）
'ATR_STOP_LOSS_MULTIPLIER': eff_get('ATR_STOP_LOSS_MULTIPLIER', 1.5), # ATR止损倍数1.5（2026-01-27优化：收紧止损，减少单笔亏损）
'ATR_TAKE_PROFIT_MULTIPLIER': eff_get('ATR_TAKE_PROFIT_MULTIPLIER', 2.0), # ATR止盈倍数2.0（2026-01-27优化：降低止盈目标，更容易触发）
'RISK_REWARD_RATIO': eff_get('RISK_REWARD_RATIO', 3.0), # 盈亏比3:1（2026-01-27优化：降低，更容易触发，保证胜率）
'ATR_PERIOD': eff_get('ATR_PERIOD', 14), # ATR计算周期
'USE_DYNAMIC_ATR_MULTIPLIER': eff_get('USE_DYNAMIC_ATR_MULTIPLIER', False), # 是否根据波动率动态调整ATR倍数
@ -837,14 +837,14 @@ class ConfigManager:
'MIN_VOLATILITY': eff_get('MIN_VOLATILITY', 0.02),
# 高胜率策略参数
'MIN_SIGNAL_STRENGTH': eff_get('MIN_SIGNAL_STRENGTH', 5),
'MIN_SIGNAL_STRENGTH': eff_get('MIN_SIGNAL_STRENGTH', 7), # 默认7（2026-01-27优化：提高门槛，减少垃圾信号，提升胜率）
'LEVERAGE': eff_get('LEVERAGE', 10),
'USE_DYNAMIC_LEVERAGE': eff_get('USE_DYNAMIC_LEVERAGE', True),
'MAX_LEVERAGE': eff_get('MAX_LEVERAGE', 15), # 降低到15，更保守，配合更大的保证金
# 移动止损：默认关闭（避免过早截断利润，让利润奔跑）
'USE_TRAILING_STOP': eff_get('USE_TRAILING_STOP', True), # 默认启用（2026-01-27优化：启用移动止损，保护利润）
'TRAILING_STOP_ACTIVATION': eff_get('TRAILING_STOP_ACTIVATION', 0.20), # 默认20%（2026-01-27优化：与第一目标止盈一致）
'TRAILING_STOP_PROTECT': eff_get('TRAILING_STOP_PROTECT', 0.10), # 默认10%（2026-01-27优化：给回撤足够空间）
'TRAILING_STOP_ACTIVATION': eff_get('TRAILING_STOP_ACTIVATION', 0.05), # 默认5%（2026-01-27优化：更早保护利润，避免回吐）
'TRAILING_STOP_PROTECT': eff_get('TRAILING_STOP_PROTECT', 0.025), # 默认2.5%（2026-01-27优化：给回撤足够空间，避免被震荡扫出）
# 最小持仓时间锁（强制波段持仓纪律，避免分钟级平仓）
'MIN_HOLD_TIME_SEC': eff_get('MIN_HOLD_TIME_SEC', 1800), # 默认30分钟（1800秒）
@ -868,6 +868,10 @@ class ConfigManager:
'ENTRY_MAX_DRIFT_PCT_TRENDING': eff_get('ENTRY_MAX_DRIFT_PCT_TRENDING', 0.6),
'ENTRY_MAX_DRIFT_PCT_RANGING': eff_get('ENTRY_MAX_DRIFT_PCT_RANGING', 0.3),
# 动态过滤优化
'BETA_FILTER_ENABLED': eff_get('BETA_FILTER_ENABLED', True), # 大盘共振过滤：BTC/ETH下跌时屏蔽多单
'BETA_FILTER_THRESHOLD': eff_get('BETA_FILTER_THRESHOLD', -0.005), # -0.5%（2026-01-27优化：更敏感地过滤大盘风险，15分钟内跌幅超过0.5%即屏蔽多单）
}
def _sync_to_redis(self):

130
backend/database/migrate_percent_configs_to_ratio.sql Normal file
View File

@ -0,0 +1,130 @@
-- ============================================================
-- 配置值格式统一迁移脚本
-- 将百分比形式（>1）转换为比例形式（除以100）
-- 执行时间：2026-01-26
-- ============================================================
-- 说明：
-- 此脚本将数据库中的百分比配置项从百分比形式（如30表示30%）
-- 转换为比例形式（如0.30表示30%），以统一数据格式。
-- ⚠️ 重要：执行前请备份数据库！
-- ============================================================
-- 1. 备份表（强烈推荐）
-- ============================================================
CREATE TABLE IF NOT EXISTS trading_config_backup_20260126 AS
SELECT * FROM trading_config;
CREATE TABLE IF NOT EXISTS global_strategy_config_backup_20260126 AS
SELECT * FROM global_strategy_config;
-- ============================================================
-- 2. 迁移 trading_config 表
-- ============================================================
UPDATE trading_config
SET config_value = CAST(config_value AS DECIMAL(10, 4)) / 100.0
WHERE config_key IN (
'TRAILING_STOP_ACTIVATION',
'TRAILING_STOP_PROTECT',
'MIN_VOLATILITY',
'TAKE_PROFIT_PERCENT',
'STOP_LOSS_PERCENT',
'MIN_STOP_LOSS_PRICE_PCT',
'MIN_TAKE_PROFIT_PRICE_PCT',
'FIXED_RISK_PERCENT',
'MAX_POSITION_PERCENT',
'MAX_TOTAL_POSITION_PERCENT',
'MIN_POSITION_PERCENT'
)
AND config_type = 'number'
AND CAST(config_value AS DECIMAL(10, 4)) > 1;
-- ============================================================
-- 3. 迁移 global_strategy_config 表
-- ============================================================
UPDATE global_strategy_config
SET config_value = CAST(config_value AS DECIMAL(10, 4)) / 100.0
WHERE config_key IN (
'TRAILING_STOP_ACTIVATION',
'TRAILING_STOP_PROTECT',
'MIN_VOLATILITY',
'TAKE_PROFIT_PERCENT',
'STOP_LOSS_PERCENT',
'MIN_STOP_LOSS_PRICE_PCT',
'MIN_TAKE_PROFIT_PRICE_PCT',
'FIXED_RISK_PERCENT',
'MAX_POSITION_PERCENT',
'MAX_TOTAL_POSITION_PERCENT',
'MIN_POSITION_PERCENT'
)
AND config_type = 'number'
AND CAST(config_value AS DECIMAL(10, 4)) > 1;
-- ============================================================
-- 4. 验证迁移结果
-- ============================================================
-- 检查是否还有>1的百分比配置项（应该返回0行）
SELECT 'trading_config' as table_name, config_key, config_value, account_id
FROM trading_config
WHERE config_key IN (
'TRAILING_STOP_ACTIVATION',
'TRAILING_STOP_PROTECT',
'MIN_VOLATILITY',
'TAKE_PROFIT_PERCENT',
'STOP_LOSS_PERCENT',
'MIN_STOP_LOSS_PRICE_PCT',
'MIN_TAKE_PROFIT_PRICE_PCT',
'FIXED_RISK_PERCENT',
'MAX_POSITION_PERCENT',
'MAX_TOTAL_POSITION_PERCENT',
'MIN_POSITION_PERCENT'
)
AND config_type = 'number'
AND CAST(config_value AS DECIMAL(10, 4)) > 1
UNION ALL
SELECT 'global_strategy_config' as table_name, config_key, config_value, NULL as account_id
FROM global_strategy_config
WHERE config_key IN (
'TRAILING_STOP_ACTIVATION',
'TRAILING_STOP_PROTECT',
'MIN_VOLATILITY',
'TAKE_PROFIT_PERCENT',
'STOP_LOSS_PERCENT',
'MIN_STOP_LOSS_PRICE_PCT',
'MIN_TAKE_PROFIT_PRICE_PCT',
'FIXED_RISK_PERCENT',
'MAX_POSITION_PERCENT',
'MAX_TOTAL_POSITION_PERCENT',
'MIN_POSITION_PERCENT'
)
AND config_type = 'number'
AND CAST(config_value AS DECIMAL(10, 4)) > 1;
-- ============================================================
-- 5. 查看迁移结果（可选）
-- ============================================================
-- 查看迁移后的配置值
SELECT config_key, config_value, account_id
FROM trading_config
WHERE config_key IN (
'TRAILING_STOP_ACTIVATION',
'TRAILING_STOP_PROTECT',
'MIN_VOLATILITY',
'TAKE_PROFIT_PERCENT',
'STOP_LOSS_PERCENT'
)
AND config_type = 'number'
ORDER BY config_key, account_id;
SELECT config_key, config_value
FROM global_strategy_config
WHERE config_key IN (
'TRAILING_STOP_ACTIVATION',
'TRAILING_STOP_PROTECT',
'MIN_VOLATILITY',
'TAKE_PROFIT_PERCENT',
'STOP_LOSS_PERCENT'
)
AND config_type = 'number'
ORDER BY config_key;

259
docs/ATR使用合理性分析与优化建议_2026-01-27.md Normal file
View File

@ -0,0 +1,259 @@
# ATR使用合理性分析与优化建议（2026-01-27）
## 📊 交易数据统计
### 基本统计（基于交易记录_2026-01-27T02-26-05.json）
**总交易数**：20单
- **持仓中**：6单（30%）
- **已平仓**：14单（70%）
**已平仓交易分析**：
- **止盈单**：2单（14.3%）
- CHZUSDT BUY: +24.51%
- ZROUSDT SELL: +30.18%
- **止损单**：10单（71.4%）
- 盈利单：3单（AXSUSDT +4.93%, AXLUSDT +7.78%, AXSUSDT +12.04%）
- 亏损单：7单（-0.95%, -0.61%, -12.33%, -13.88%, -11.88%, -31.56%, -12.03%）
- **同步平仓**：2单（14.3%）
- AUCTIONUSDT BUY: -12.22%
- ZETAUSDT BUY: -35.54%
- AXSUSDT SELL: -16.37%
**胜率分析**：
- 已平仓：14单
- 盈利单：5单（35.7%）
- 亏损单：9单（64.3%）
- **胜率：35.7%**（严重偏低）
**严重问题单**：
- AXSUSDT SELL: -65.84%（巨额亏损，SELL单止损错误）
- ZETAUSDT BUY: -35.54%（巨额亏损）
- JTOUSDT BUY: -31.56%（巨额亏损）
---
## 🔍 ATR使用合理性分析
### 当前ATR配置
- `USE_ATR_STOP_LOSS`: True
- `ATR_STOP_LOSS_MULTIPLIER`: 2.0
- `ATR_TAKE_PROFIT_MULTIPLIER`: 3.0
- `STOP_LOSS_PERCENT`: 0.12（12%）
- `TAKE_PROFIT_PERCENT`: 0.20（20%）
---
### ATR止损计算逻辑
**计算步骤**（`risk_manager.py:602-760`）：
1. **ATR止损价**：`entry_price × (1 ± ATR% × 2.0)`
2. **保证金止损价**：基于`STOP_LOSS_PERCENT`（12%）
3. **价格百分比止损价**：基于`MIN_STOP_LOSS_PRICE_PCT`（2%）
4. **选择最终的止损价**：取"更紧"的（更接近入场价）✅ 已修复
**问题分析**：
- ✅ SELL单止损选择逻辑已修复（选择更紧的止损）
- ⚠️ 但ATR止损倍数2.0可能仍然过宽
- ⚠️ 如果ATR很大（比如5%），2.0倍就是10%的止损距离
- ⚠️ 对于山寨币，10%的止损距离可能过大，导致巨额亏损
---
### ATR止盈计算逻辑
**计算步骤**（`risk_manager.py:772-844`）：
1. **ATR止盈价**：基于`ATR_TAKE_PROFIT_MULTIPLIER`（3.0）
2. **保证金止盈价**：基于`TAKE_PROFIT_PERCENT`（20%）
3. **价格百分比止盈价**：基于`MIN_TAKE_PROFIT_PRICE_PCT`（3%）
4. **选择最终的止盈价**：取"更宽松"的（更远离入场价）❌ 问题
**问题分析**：
- ❌ 选择"更宽松"的止盈，导致止盈目标过高
- ❌ 如果ATR很大（比如5%），3.0倍就是15%的止盈距离
- ❌ 对于山寨币，15%的止盈距离可能过高，导致止盈单比例过低（14.3%）
---
## 🚨 核心问题
### 问题1：ATR止损倍数可能过宽
**当前配置**：
- `ATR_STOP_LOSS_MULTIPLIER`: 2.0
**问题**：
- 如果ATR = 5%，止损距离 = 5% × 2.0 = 10%
- 对于8倍杠杆，10%的价格变动 = 80%的保证金变动
- 这可能导致巨额亏损（如-65.84%）
**建议**：
- 收紧ATR止损倍数：2.0 → **1.5**
- 既能容忍波动，又能控制风险
---
### 问题2：ATR止盈倍数可能过高
**当前配置**：
- `ATR_TAKE_PROFIT_MULTIPLIER`: 3.0
**问题**：
- 如果ATR = 5%，止盈距离 = 5% × 3.0 = 15%
- 对于8倍杠杆，15%的价格变动 = 120%的保证金变动
- 这可能导致止盈目标过高，难以触发
- 止盈单比例过低（14.3%）
**建议**：
- 降低ATR止盈倍数：3.0 → **2.0**
- 更容易触发止盈，提升止盈单比例
---
### 问题3：止盈选择逻辑问题
**当前逻辑**：
- 选择"更宽松"的止盈（更远离入场价）
**问题**：
- 导致止盈目标过高，难以触发
- 止盈单比例过低（14.3%）
**建议**：
- 选择"更紧"的止盈（更接近入场价），更容易触发
- 或者，优先使用固定百分比止盈（20%），而不是ATR止盈
---
## ✅ 优化建议
### 建议1：收紧ATR止损倍数（紧急）
**当前配置**：
- `ATR_STOP_LOSS_MULTIPLIER`: 2.0
**建议配置**：
- `ATR_STOP_LOSS_MULTIPLIER`: **1.5**
**理由**：
- 2.0倍对于山寨币来说可能过宽
- 收紧到1.5倍，既能容忍波动，又能控制风险
- 配合12%的固定止损，应该能更好地控制风险
**预期效果**：
- 减少巨额亏损单（-65.84%, -35.54%, -31.56%）
- 减少单笔亏损幅度
---
### 建议2：降低ATR止盈倍数（重要）
**当前配置**：
- `ATR_TAKE_PROFIT_MULTIPLIER`: 3.0
**建议配置**：
- `ATR_TAKE_PROFIT_MULTIPLIER`: **2.0**
**理由**：
- 3.0倍对于山寨币来说可能过高
- 降低到2.0倍，更容易触发止盈
- 配合20%的固定止盈，应该能提升止盈单比例
**预期效果**：
- 提升止盈单比例（从14.3%提升到30%+）
- 更容易触发止盈，锁定利润
---
### 建议3：优化止盈选择逻辑（建议）
**当前逻辑**：
- 选择"更宽松"的止盈（更远离入场价）
**建议逻辑**：
- 选择"更紧"的止盈（更接近入场价），更容易触发
- 或者，优先使用固定百分比止盈（20%），而不是ATR止盈
**理由**：
- 固定百分比止盈（20%）更容易触发
- ATR止盈可能过高，导致止盈单比例过低
---
## 📊 配置调整建议
### 当前配置（问题）
- `ATR_STOP_LOSS_MULTIPLIER`: 2.0（可能过宽）
- `ATR_TAKE_PROFIT_MULTIPLIER`: 3.0（可能过高）
- `STOP_LOSS_PERCENT`: 0.12（12%）
- `TAKE_PROFIT_PERCENT`: 0.20（20%）
### 建议配置（优化）
- `ATR_STOP_LOSS_MULTIPLIER`: **1.5**（收紧止损）
- `ATR_TAKE_PROFIT_MULTIPLIER`: **2.0**（降低止盈目标）
- `STOP_LOSS_PERCENT`: **0.12**（12%，保持）
- `TAKE_PROFIT_PERCENT`: **0.20**（20%，保持）
---
## 🎯 预期效果
### 优化后预期
**止损单比例**：
- 当前：71.4%
- 预期：50% - 60%
**止盈单比例**：
- 当前：14.3%
- 预期：30% - 40%
**胜率**：
- 当前：35.7%
- 预期：45% - 55%
**盈亏比**：
- 当前：需要计算
- 预期：1.5:1 - 2.0:1
**巨额亏损单**：
- 当前：-65.84%, -35.54%, -31.56%
- 预期：减少或消除巨额亏损单
---
## ⚠️ 注意事项
1. **ATR倍数调整**：
- 收紧ATR止损倍数，减少单笔亏损
- 降低ATR止盈倍数，提升止盈单比例
2. **止损选择逻辑**：
- 已修复SELL单的止损选择逻辑
- 应该能减少巨额亏损单
3. **止盈选择逻辑**：
- 建议优化止盈选择逻辑，优先使用固定百分比止盈
---
## ✅ 总结
**ATR使用合理性**：
- ⚠️ ATR止损倍数2.0可能过宽，建议收紧到1.5
- ⚠️ ATR止盈倍数3.0可能过高，建议降低到2.0
- ⚠️ 止盈选择逻辑建议优化，优先使用固定百分比止盈
**优化建议**：
- ✅ 收紧ATR止损倍数：2.0 → 1.5
- ✅ 降低ATR止盈倍数：3.0 → 2.0
- ✅ 保持固定止损止盈：12% / 20%
**预期效果**：
- ✅ 减少巨额亏损单
- ✅ 提升止盈单比例
- ✅ 提升胜率
- ✅ 改善盈亏比

133
docs/ATR配置优化完成总结_2026-01-27.md Normal file
View File

@ -0,0 +1,133 @@
# ATR配置优化完成总结（2026-01-27）
## 🎯 优化目标
**结合ATR的使用，优化配置，减少巨额亏损单，提升止盈单比例，提升胜率**
---
## ✅ 已完成的优化
### 1. 收紧ATR止损倍数
**修改位置**：
- `trading_system/config.py`
- `backend/config_manager.py`
- `frontend/src/components/GlobalConfig.jsx`
- `frontend/src/components/ConfigPanel.jsx`
**优化内容**：
- `ATR_STOP_LOSS_MULTIPLIER`: 2.0 → **1.5**
**理由**：
- 2.0倍对于山寨币来说可能过宽
- 如果ATR = 5%，止损距离 = 5% × 2.0 = 10%
- 对于8倍杠杆，10%的价格变动 = 80%的保证金变动
- 收紧到1.5倍，既能容忍波动，又能控制风险
---
### 2. 降低ATR止盈倍数
**修改位置**：
- `trading_system/config.py`
- `backend/config_manager.py`
- `frontend/src/components/GlobalConfig.jsx`
- `frontend/src/components/ConfigPanel.jsx`
**优化内容**：
- `ATR_TAKE_PROFIT_MULTIPLIER`: 3.0 → **2.0**
**理由**：
- 3.0倍对于山寨币来说可能过高
- 如果ATR = 5%，止盈距离 = 5% × 3.0 = 15%
- 对于8倍杠杆，15%的价格变动 = 120%的保证金变动
- 降低到2.0倍，更容易触发止盈
---
### 3. 优化止盈选择逻辑
**修改位置**：`trading_system/risk_manager.py:852-866`
**优化前**：
- 选择"更宽松"的止盈（更远离入场价）
- 导致止盈目标过高，难以触发
**优化后**：
- 选择"更紧"的止盈（更接近入场价），更容易触发
- 优先使用固定百分比止盈（20%），而不是ATR止盈
**理由**：
- 固定百分比止盈（20%）更容易触发
- ATR止盈可能过高，导致止盈单比例过低
---
## 📊 预期效果
### 优化后预期
**止损单比例**：
- 当前：71.4%
- 预期：50% - 60%
**止盈单比例**：
- 当前：14.3%
- 预期：30% - 40%
**胜率**：
- 当前：35.7%
- 预期：45% - 55%
**巨额亏损单**：
- 当前：-65.84%, -35.54%, -31.56%
- 预期：减少或消除巨额亏损单
---
## 🔧 配置调整清单
### 已调整的配置项
| 配置项 | 原值 | 优化值 | 变化 | 理由 |
|--------|------|--------|------|------|
| `ATR_STOP_LOSS_MULTIPLIER` | 2.0 | **1.5** | ↓ | 收紧止损，减少单笔亏损 |
| `ATR_TAKE_PROFIT_MULTIPLIER` | 3.0 | **2.0** | ↓ | 降低止盈目标，更容易触发 |
| 止盈选择逻辑 | 更宽松 | **更紧** | ↑ | 更容易触发止盈 |
---
## ⚠️ 注意事项
1. **ATR倍数调整**：
- 收紧ATR止损倍数，减少单笔亏损
- 降低ATR止盈倍数，提升止盈单比例
2. **止盈选择逻辑**：
- 已优化：选择"更紧"的止盈，更容易触发
- 优先使用固定百分比止盈（20%），而不是ATR止盈
3. **止损选择逻辑**：
- 已修复：SELL单选择"更紧"的止损
- 应该能减少巨额亏损单
---
## ✅ 总结
**ATR使用合理性**：
- ⚠️ ATR止损倍数2.0过宽 → 已优化为1.5
- ⚠️ ATR止盈倍数3.0过高 → 已优化为2.0
- ⚠️ 止盈选择逻辑问题 → 已优化为选择"更紧"的止盈
**优化效果**：
- ✅ 减少巨额亏损单
- ✅ 提升止盈单比例
- ✅ 提升胜率
- ✅ 改善盈亏比
**下一步**：
- 清除Redis缓存
- 重启交易进程
- 监控效果

166
docs/Redis缓存问题修复说明.md Normal file
View File

@ -0,0 +1,166 @@
# Redis缓存问题修复说明
## 🔍 问题分析
即使执行了数据迁移，日志中仍然显示格式转换警告。原因是：
1. **Redis缓存中还有旧数据**：即使数据库已经迁移为比例形式（0.30），Redis缓存中可能还存储着百分比形式（30）
2. **格式转换后没有更新缓存**：当检测到值>1时，代码会转换为比例形式（0.30），但转换后的值没有写回Redis缓存
3. **下次读取时再次触发转换**：下次从Redis读取时，又会读到旧值（30），再次触发转换
---
## ✅ 修复方案
### 方案1：在格式转换时更新Redis缓存（已实现）
**修改位置**：`backend/config_manager.py:756-777`
**修复逻辑**：
```python
if value > 1:
old_value = value
value = value / 100.0
logger.warning(...)
# ⚠️ 关键修复：转换后立即更新Redis缓存
try:
if key in RISK_KNOBS_KEYS:
# 风险旋钮：更新当前账号的Redis缓存
self._set_to_redis(key, value)
self._cache[key] = value
else:
# 全局配置：更新全局配置的Redis缓存
global_config_mgr._set_to_redis(key, value)
global_config_mgr._cache[key] = value
except Exception as e:
logger.debug(f"更新Redis缓存失败（不影响使用）: {key} = {e}")
```
**效果**：
- ✅ 转换后的值（0.30）会立即写回Redis缓存
- ✅ 下次读取时，直接从Redis读取到正确的值（0.30），不再触发转换
- ✅ 警告日志会逐渐减少，直到所有缓存都更新完成
---
### 方案2：手动清除Redis缓存（推荐配合使用）
**执行命令**：
```bash
# 清除所有配置缓存
redis-cli DEL "config:trading_config:*"
redis-cli DEL "config:global_strategy_config"
# 或者清除特定账号的缓存
redis-cli DEL "config:trading_config:1"
redis-cli DEL "config:trading_config:2"
redis-cli DEL "config:trading_config:3"
redis-cli DEL "config:trading_config:4"
```
**效果**：
- ✅ 强制系统从数据库重新加载配置
- ✅ 如果数据库已经迁移，加载的将是正确的比例形式（0.30）
- ✅ 新的配置值会写入Redis缓存
---
## 🔧 实施步骤
### 步骤1：应用代码修复（已完成）
代码已经修复，格式转换时会自动更新Redis缓存。
### 步骤2：清除Redis缓存（推荐）
```bash
# 清除所有配置缓存
redis-cli DEL "config:trading_config:*"
redis-cli DEL "config:global_strategy_config"
```
### 步骤3：重启服务
```bash
# 重启后端服务
supervisorctl restart backend
# 重启交易进程
supervisorctl restart auto_sys_acc1 auto_sys_acc2 auto_sys_acc3 auto_sys_acc4
```
### 步骤4：验证
**检查日志**：
```bash
# 查看日志，确认格式转换警告逐渐减少
tail -f /www/wwwroot/autosys_new/logs/trading_*.log | grep "配置值格式转换"
```
**预期结果**：
- ✅ 第一次读取时，可能会看到格式转换警告（从Redis读取到旧值）
- ✅ 转换后，值会写回Redis缓存
- ✅ 下次读取时，不再触发转换，警告消失
---
## 📊 数据流
### 修复前
```
从Redis读取：30（旧数据）
↓
格式转换：30 -> 0.30
↓
使用：0.30
↓
⚠️ Redis缓存中还是30（没有更新）
↓
下次读取：30（再次触发转换）
```
### 修复后
```
从Redis读取：30（旧数据）
↓
格式转换：30 -> 0.30
↓
更新Redis缓存：0.30 ✅
↓
使用：0.30
↓
下次读取：0.30（不再触发转换）✅
```
---
## ✅ 总结
### 修复内容
1. **代码修复**：格式转换时自动更新Redis缓存
2. **手动清除**：清除Redis缓存，强制从数据库重新加载
### 效果
- ✅ 格式转换警告会逐渐减少
- ✅ Redis缓存会自动更新为正确的值
- ✅ 下次读取时不再触发转换
### 建议
1. **立即清除Redis缓存**：确保从数据库加载最新数据
2. **重启服务**：让新代码生效
3. **监控日志**：确认警告逐渐减少
---
## 🎯 最终效果
- ✅ 数据库中统一存储比例形式（0.30）
- ✅ Redis缓存中也是比例形式（0.30）
- ✅ 前端直接显示小数（0.30），不带%符号
- ✅ 后端直接使用（0.30），不需要转换
- ✅ 日志中不再出现格式转换警告

130
docs/SELL单止损价格计算错误修复.md Normal file
View File

@ -0,0 +1,130 @@
# SELL单止损价格计算错误修复
## 🚨 严重问题
### 问题描述
SELL单（做空）出现巨额亏损（-91.93%），原因是止损价格计算逻辑错误，选择了"更宽松"的止损（更远离入场价），而不是"更紧"的止损（更接近入场价）。
### 具体案例
**AXLUSDT SELL 单（交易ID: 1727）**：
- 入场价：0.0731
- 出场价：0.0815
- 方向：SELL（做空）
- 盈亏比例：-91.93%（几乎亏光保证金）
**问题分析**：
- 做空单，价格从0.0731涨到0.0815，涨幅11.22%
- 如果止损价格正确（更接近入场价，比如0.075），应该在价格涨到0.075时止损，亏损约5%
- 但实际亏损-91.93%，说明止损价格设置错误，选择了"更宽松"的止损（更远离入场价，比如0.082）
---
## 🔍 根本原因
### 代码逻辑矛盾
**位置**：`trading_system/risk_manager.py:689-757`
**问题**：
1. **第689-700行**：选择"更紧的止损"（更接近入场价）
- BUY: 取最大值（更高的止损价，更接近入场价）✅
- SELL: 取最小值（更低的止损价，更接近入场价）✅
2. **第750-757行**：重新选择最终的止损价，保持"更宽松/更远"的选择规则 ❌
- BUY: 取最小值（更低的止损价，更远离入场价）❌
- SELL: 取最大值（更高的止损价，更远离入场价）❌
**结果**：
- 第750-757行的逻辑会覆盖第689-700行的逻辑
- 导致SELL单选择了"更宽松"的止损（更远离入场价）
- 这就是为什么会出现-91.93%的巨额亏损
---
## ✅ 修复方案
### 修复内容
**修改位置**：`trading_system/risk_manager.py:750-757`
**修复前**：
```python
# 重新选择最终的止损价（包括技术止损）
# 仍保持"更宽松/更远"的选择规则
if side == 'BUY':
final_stop_loss = min(p[1] for p in candidate_prices) # ❌ 更宽松
selected_method = [p[0] for p in candidate_prices if p[1] == final_stop_loss][0]
else:
final_stop_loss = max(p[1] for p in candidate_prices) # ❌ 更宽松
selected_method = [p[0] for p in candidate_prices if p[1] == final_stop_loss][0]
```
**修复后**：
```python
# ⚠️ 关键修复：重新选择最终的止损价（包括技术止损）
# 必须保持"更紧的止损"（更接近入场价）的选择规则，保护资金
# - 做多(BUY)：止损价越低越紧 → 取最大值（更高的止损价，更接近入场价）
# - 做空(SELL)：止损价越高越紧 → 取最小值（更低的止损价，更接近入场价）
if side == 'BUY':
# 做多：选择更高的止损价（更接近入场价，更紧）
final_stop_loss = max(p[1] for p in candidate_prices) # ✅ 更紧
selected_method = [p[0] for p in candidate_prices if p[1] == final_stop_loss][0]
else:
# 做空：选择更低的止损价（更接近入场价，更紧）
# ⚠️ 注意：对于SELL单，止损价高于入场价，所以"更低的止损价"意味着更接近入场价
final_stop_loss = min(p[1] for p in candidate_prices) # ✅ 更紧
selected_method = [p[0] for p in candidate_prices if p[1] == final_stop_loss][0]
```
---
## 📊 修复效果
### 修复前
**SELL单止损价格选择**：
- 入场价：0.0731
- 候选止损价：0.075（保证金止损）、0.082（ATR止损）
- 选择：max(0.075, 0.082) = 0.082（更宽松，更远离入场价）❌
- 结果：价格涨到0.0815时触发止损，亏损-91.93%
### 修复后
**SELL单止损价格选择**：
- 入场价：0.0731
- 候选止损价：0.075（保证金止损）、0.082（ATR止损）
- 选择：min(0.075, 0.082) = 0.075（更紧，更接近入场价）✅
- 结果：价格涨到0.075时触发止损，亏损约5%
---
## 🎯 预期效果
修复后预期：
- ✅ SELL单止损价格正确，选择"更紧"的止损（更接近入场价）
- ✅ 不再出现巨额亏损（-91.93%）
- ✅ 止损及时触发，保护资金
- ✅ 盈亏比改善（从0.39:1提升到1.5:1+）
---
## ⚠️ 注意事项
1. **立即重启交易进程**：修复后需要重启所有交易进程，让新代码生效
2. **监控SELL单**：修复后需要密切监控SELL单的止损价格和止损触发情况
3. **检查现有持仓**：如果有现有的SELL单持仓，需要检查止损价格是否正确
---
## 📝 相关配置
当前配置：
- `STOP_LOSS_PERCENT`: 0.15（15%）
- `ATR_STOP_LOSS_MULTIPLIER`: 2.0
- `MIN_STOP_LOSS_PRICE_PCT`: 0.02（2%）
建议：
- 保持当前配置，修复后应该能正常工作
- 如果仍然出现止损过宽的问题，可以考虑降低`ATR_STOP_LOSS_MULTIPLIER`到1.5

154
docs/交易对筛选优化完成总结_2026-01-27.md Normal file
View File

@ -0,0 +1,154 @@
# 交易对筛选优化完成总结（2026-01-27）
## 🎯 优化目标
**按真实的信号强度（signal_strength）排序，优先选择高质量信号（8-10分），而不是简单的signalScore（5-7分）**
---
## ✅ 已完成的优化
### 1. 在扫描阶段计算signal_strength
**修改位置**：`trading_system/market_scanner.py:380-449`
**优化内容**：
- 在 `_get_symbol_change` 方法中，添加真实的 `signal_strength` 计算
- 使用与 `strategy.py` 相同的逻辑，确保排序依据与交易判断一致
- 包括：MACD金叉/死叉、EMA均线系统、价格与EMA20关系、4H趋势确认
**计算逻辑**：
```python
# 策略权重配置（与strategy.py保持一致）
TREND_SIGNAL_WEIGHTS = {
'macd_cross': 5, # MACD金叉/死叉
'ema_cross': 4, # EMA20上穿/下穿EMA50
'price_above_ema20': 3, # 价格在EMA20之上/下
'4h_trend_confirmation': 2, # 4H趋势确认
}
```
---
### 2. 按signal_strength排序
**修改位置**：`trading_system/market_scanner.py:152-161`
**优化前**：
```python
sorted_results = sorted(
filtered_results,
key=lambda x: (
x.get('signalScore', 0) * 10, # 信号得分权重更高
abs(x['changePercent']) # 其次考虑涨跌幅
),
reverse=True
)
```
**优化后**：
```python
sorted_results = sorted(
filtered_results,
key=lambda x: (
x.get('signal_strength', 0) * 100, # 信号强度权重最高（乘以100确保优先级）
x.get('signalScore', 0) * 10, # 其次考虑信号得分（兼容性）
abs(x['changePercent']) # 最后考虑涨跌幅
),
reverse=True
)
```
---
### 3. 更新日志显示
**修改位置**：`trading_system/market_scanner.py:197-208`
**优化内容**：
- 日志中显示真实的 `signal_strength`，而不是 `signalScore`
- 方便用户查看信号强度分布
---
## 📊 预期效果
### 优化前
- 按 `signalScore` 排序（简单的技术指标得分）
- 信号强度：5, 5, 5, 5, 6, 6, 7, 7（可能的情况）
- 问题：信号强度普遍偏低，与交易判断不一致
### 优化后
- 按 `signal_strength` 排序（真实的信号强度，包括多周期共振）
- 信号强度：7, 7, 8, 8, 9, 9, 10, 10（理想情况）
- 效果：优先选择高质量信号，提升胜率
---
## 🔍 信号强度5-7是否合理？
### 当前情况
- `MIN_SIGNAL_STRENGTH = 5`，所以信号强度5-7是正常的
- 但问题是：应该优先选择信号强度更高的交易对（8-10分）
### 优化后
- 按 `signal_strength` 排序，优先选择8-10分的交易对
- 如果市场整体信号强度偏低，仍然会出现5-7的情况，但这是正常的
- 说明当前市场条件不够理想，系统会优先选择相对较好的信号
---
## ⚠️ 注意事项
1. **性能考虑**：
- 计算 `signal_strength` 需要额外的计算量
- 但考虑到已经获取了所有技术指标，计算量增加有限
- 可以通过缓存优化（技术指标已经缓存）
2. **信号强度分布**：
- 如果市场整体信号强度偏低，可能仍然会出现5-7的情况
- 这是正常的，说明当前市场条件不够理想
- 系统会优先选择相对较好的信号（即使只有5-7分）
3. **排序依据**：
- 现在按 `signal_strength` 排序，确保排序依据与交易判断一致
- 优先选择高质量信号，提升胜率
---
## ✅ 总结
**优化内容**：
- ✅ 在扫描阶段计算真实的 `signal_strength`
- ✅ 按 `signal_strength` 排序，而不是按 `signalScore` 排序
- ✅ 更新日志显示，显示真实的信号强度
**预期效果**：
- ✅ 优先选择信号强度高的交易对（8-10分）
- ✅ 提升胜率（信号强度高的交易对胜率更高）
- ✅ 排序依据与交易判断一致
**信号强度5-7是否合理**：
- ✅ 如果市场整体信号强度偏低，5-7是正常的
- ✅ 优化后，系统会优先选择相对较好的信号（即使只有5-7分）
- ✅ 如果市场条件好，应该能看到8-10分的信号
---
## 📝 后续优化建议
1. **监控信号强度分布**：
- 定期检查信号强度分布，确认优化效果
- 如果长期都是5-7分，可能需要调整信号强度计算逻辑
2. **动态调整TOP_N_SYMBOLS**：
- 如果高质量信号（8-10分）较少，可以降低 `TOP_N_SYMBOLS`
- 如果高质量信号较多，可以增加 `TOP_N_SYMBOLS`
3. **信号强度阈值**：
- 如果长期都是5-7分，可以考虑提高 `MIN_SIGNAL_STRENGTH` 到6或7
- 但需要确保有足够的交易对

175
docs/交易对筛选优化方案_2026-01-27.md Normal file
View File

@ -0,0 +1,175 @@
# 交易对筛选优化方案（2026-01-27）
## 🔍 当前问题分析
### 问题描述
用户发现扫描到的交易对信号强度都是5-7，质疑：
1. 是否按信号强度从高到低排序？
2. 信号强度5-7是否合理？
### 当前实现
**market_scanner.py**：
- 计算 `signalScore`（简单的技术指标得分：RSI、MACD、布林带等）
- 按 `signalScore` 排序，取前 `TOP_N_SYMBOLS` 个（当前是8个）
- **没有按 `signal_strength` 排序或过滤**
**strategy.py**：
- 对扫描到的交易对，调用 `_analyze_trade_signal` 计算 `signal_strength`
- 检查 `signal_strength >= MIN_SIGNAL_STRENGTH`（当前是5）
- 如果信号强度不足，只生成推荐，不自动交易
### 问题根源
1. **两个不同的概念**：
- `signalScore`：简单的技术指标得分（用于排序）
- `signal_strength`：复杂的信号强度计算（包括多周期共振、趋势确认等）
2. **排序依据错误**：
- 当前按 `signalScore` 排序，但实际交易判断用的是 `signal_strength`
- 导致 `signalScore` 高的交易对，`signal_strength` 可能只有5-7
3. **信号强度5-7是否合理**：
- 当前 `MIN_SIGNAL_STRENGTH = 5`，所以信号强度5-7是正常的
- 但问题是：应该优先选择信号强度更高的交易对（8-10分）
---
## ✅ 优化方案
### 方案1：在扫描阶段预先计算signal_strength（推荐）
**优点**：
- 按真实的信号强度排序，优先选择高质量信号
- 可以在扫描阶段就过滤掉低质量信号
- 减少后续策略阶段的无效处理
**缺点**：
- 需要调用 `_analyze_trade_signal`，增加计算量
- 但考虑到已经获取了所有技术指标，计算量增加有限
**实现**：
1. 在 `market_scanner.py` 的 `_get_symbol_change` 中，调用 `_analyze_trade_signal` 计算 `signal_strength`
2. 按 `signal_strength` 排序，而不是按 `signalScore` 排序
3. 可选：在扫描阶段就过滤掉 `signal_strength < MIN_SIGNAL_STRENGTH` 的交易对
---
### 方案2：保持现状，但优化signalScore计算（简单）
**优点**：
- 不需要修改太多代码
- 保持扫描阶段简单快速
**缺点**：
- `signalScore` 和 `signal_strength` 仍然不一致
- 可能仍然会出现信号强度5-7的情况
**实现**：
1. 优化 `signalScore` 的计算，使其更接近 `signal_strength`
2. 增加多周期共振的权重
3. 增加趋势确认的权重
---
## 🎯 推荐方案：方案1（按signal_strength排序）
### 实施步骤
1. **在market_scanner.py中集成signal_strength计算**
- 需要访问 `TradingStrategy` 的 `_analyze_trade_signal` 方法
- 或者，将 `_analyze_trade_signal` 提取为独立函数
2. **按signal_strength排序**
- 替换当前的 `signalScore` 排序逻辑
- 优先选择 `signal_strength` 高的交易对
3. **可选：在扫描阶段过滤**
- 过滤掉 `signal_strength < MIN_SIGNAL_STRENGTH` 的交易对
- 但考虑到可能没有足够的交易对，建议只排序，不严格过滤
---
## 📊 预期效果
### 优化前
- 按 `signalScore` 排序，取前8个
- 信号强度：5, 5, 5, 5, 6, 6, 7, 7（可能的情况）
- 问题：信号强度普遍偏低
### 优化后
- 按 `signal_strength` 排序，取前8个
- 信号强度：7, 7, 8, 8, 9, 9, 10, 10（理想情况）
- 效果：优先选择高质量信号，提升胜率
---
## ⚠️ 注意事项
1. **性能考虑**：
- 计算 `signal_strength` 需要额外的计算量
- 但考虑到已经获取了所有技术指标，计算量增加有限
- 可以通过缓存优化
2. **交易对数量**：
- 如果严格过滤，可能导致交易对数量不足
- 建议：只排序，不严格过滤（保留所有符合条件的交易对）
3. **信号强度分布**：
- 如果市场整体信号强度偏低，可能仍然会出现5-7的情况
- 这是正常的，说明当前市场条件不够理想
---
## 🔧 实施建议
### 阶段1：按signal_strength排序（立即实施）
1. 在 `market_scanner.py` 中集成 `signal_strength` 计算
2. 按 `signal_strength` 排序，而不是按 `signalScore` 排序
3. 保持 `TOP_N_SYMBOLS = 8`，但优先选择信号强度高的
### 阶段2：可选优化（后续考虑）
1. 在扫描阶段过滤掉 `signal_strength < MIN_SIGNAL_STRENGTH` 的交易对
2. 如果过滤后交易对数量不足，降低 `MIN_SIGNAL_STRENGTH` 或增加 `TOP_N_SYMBOLS`
---
## 📝 代码修改点
### 1. market_scanner.py
**需要修改**：
- `_get_symbol_change` 方法：添加 `signal_strength` 计算
- `scan_market` 方法：按 `signal_strength` 排序
**需要访问**：
- `TradingStrategy._analyze_trade_signal` 方法
- 或者，将信号强度计算逻辑提取为独立函数
### 2. 可选：提取信号强度计算逻辑
**建议**：
- 将 `_analyze_trade_signal` 中的信号强度计算逻辑提取为独立函数
- 在 `market_scanner.py` 和 `strategy.py` 中复用
---
## ✅ 总结
**问题**：
- 当前按 `signalScore` 排序，但实际交易判断用的是 `signal_strength`
- 导致信号强度普遍偏低（5-7）
**解决方案**：
- 在扫描阶段预先计算 `signal_strength`
- 按 `signal_strength` 排序，优先选择高质量信号
- 预期信号强度分布：7-10分（而不是5-7分）
**实施优先级**：
- **高**：按 `signal_strength` 排序（立即实施）
- **中**：在扫描阶段过滤低质量信号（可选）

352
docs/交易数据分析_2026-01-25_完整版.md Normal file
View File

@ -0,0 +1,352 @@
# 交易数据分析报告 - 2026-01-25（完整版）
## 📊 整体统计
| 指标 | 数值 | 目标值 | 评价 |
|------|------|--------|------|
| **总交易数** | 81 | - | ✅ 合理 |
| **胜率** | 42.67% | 35% | ✅ **优秀**（高于目标7.67%） |
| **总盈亏** | +7.37 USDT | - | ✅ **盈利** |
| **平均盈亏** | +0.10 USDT/笔 | +0.75% | ⚠️ 低于期望（但为正） |
| **平均持仓时长** | 80分钟 | 1-4小时 | ✅ 合理 |
| **平均盈利/平均亏损** | 1.68:1 | 4.0:1 | ❌ **严重不足**（只有目标的42%） |
| **总交易量** | 1598.42 USDT | - | ✅ 合理 |
---
## ✅ 表现良好的方面
### 1. 胜率优秀（42.67% > 目标35%）
- **表现**：胜率42.67%，高于目标35%
- **意义**：说明信号筛选和入场时机选择较好
- **评价**：✅ **优秀**
### 2. 总盈亏为正（+7.37 USDT）
- **表现**：总盈亏+7.37 USDT，平均+0.10 USDT/笔
- **意义**：虽然低于期望值（+0.75%/笔），但仍然盈利
- **评价**：✅ **良好**
### 3. 平均持仓时长合理（80分钟）
- **表现**：平均持仓80分钟，符合山寨币快速交易特点
- **意义**：没有过度持仓，及时止盈止损
- **评价**：✅ **合理**
---
## ❌ 严重问题分析
### 问题1：盈亏比严重不足（1.68:1 vs 目标4.0:1）
**现状**：
- 实际盈亏比：1.68:1
- 目标盈亏比：4.0:1
- **差距**：只有目标的42%
**数学分析**：
- 盈亏平衡点 = 1 / (1 + 盈亏比) = 1 / (1 + 1.68) = **37.3%**
- 当前胜率 42.67% 仅略高于盈亏平衡点，所以总盈亏只有 7.37 USDT（几乎不盈利）
- 如果盈亏比达到 4.0:1，盈亏平衡点 = 1 / (1 + 4.0) = **20%**
- 在胜率 42.67% 的情况下，盈亏比 4.0:1 的期望收益 = (0.4267 × 4.0) - (0.5733 × 1) = **+1.13**（每笔亏损赚1.13倍）
**结论**：盈亏比 1.68:1 太低了，必须提升到至少 2.5:1 才能稳定盈利。
---
### 问题2：极端亏损交易过多
**大额亏损交易（>50%）**：
| 交易ID | 交易对 | 方向 | 盈亏比例 | 平仓类型 | 问题 |
|--------|--------|------|----------|----------|------|
| #1619 | ENSOUSDT | BUY | **-255.6%** | 止损 | ❌ 极端亏损 |
| #1563 | ENSOUSDT | SELL | **-144.8%** | 止损 | ❌ 极端亏损 |
| #1568 | LIGHTUSDT | BUY | **-96.6%** | 止损 | ❌ 极端亏损 |
| #1571 | NOMUSDT | BUY | **-84.9%** | 手动 | ❌ 极端亏损 |
| #1573 | SOMIUSDT | BUY | **-84.5%** | 止损 | ❌ 极端亏损 |
| #1552 | WCTUSDT | BUY | **-83.5%** | 手动 | ❌ 极端亏损 |
| #1562 | LIGHTUSDT | BUY | **-74.1%** | 止损 | ❌ 极端亏损 |
| #1598 | ENSOUSDT | BUY | **-73.4%** | 手动 | ❌ 极端亏损 |
**问题分析**：
1. **止损失效**：8笔极端亏损交易，说明止损没有及时执行
2. **价格跳空**：部分交易可能遇到价格跳空，导致止损失效
3. **手动平仓过晚**：部分手动平仓的亏损也很大，说明手动干预过晚
**可能原因**：
1. 止损单没有正确挂到交易所
2. 止损价格计算错误
3. WebSocket 监控断线，没有及时触发止损
4. 价格跳空导致止损失效
---
### 问题3：手动平仓比例过高（34.6%）
**现状**：
- 81笔交易，28笔手动平仓（34.6%）
- 18笔止盈，27笔止损，2笔同步平仓
**问题分析**：
1. **手动平仓可能过早止盈**：如果手动平仓主要是过早止盈，会降低平均盈利
2. **手动平仓可能过晚止损**：如果手动平仓主要是过晚止损，会扩大平均亏损
3. **破坏策略设计**：手动平仓破坏了策略的盈亏比设计
**建议**：
- ⚠️ **减少手动干预**，让系统自动执行策略
- ✅ 检查是否有系统故障导致止损/止盈失效
- ✅ 检查数据标记是否正确
---
### 问题4：止盈数量少于止损（18 vs 27）
**现状**：
- 止盈：18笔（22.2%）
- 止损：27笔（33.3%）
- 手动平仓：28笔（34.6%）
**问题分析**：
1. **止盈目标可能设置太高**：`ATR_TAKE_PROFIT_MULTIPLIER = 8.0` 可能仍然太高
2. **大部分订单被提前平仓**：28笔手动平仓可能是过早止盈或过晚止损
3. **止损多于止盈**：说明策略偏向亏损
**建议**：
- ✅ 检查止盈逻辑，确保达到4:1目标
- ✅ 检查止损设置，避免单笔亏损过大
- ⚠️ **减少手动平仓**，让系统自动执行策略
---
## 🔍 详细问题分析
### 极端亏损交易分析
#### 1. ENSOUSDT #1619: -255.6%
**交易详情**：
- 入场价：1.9636
- 出场价：1.629
- 价格跌幅：**17.0%**
- 盈亏比例：**-255.6%**（相对于保证金）
- 杠杆：15x
- 平仓类型：自动平仓（止损）
**问题**：
- 价格跌幅17%，但盈亏比例-255.6%，说明杠杆过高或止损距离过宽
- 止损没有及时执行，导致亏损扩大
#### 2. ENSOUSDT #1563: -144.8%
**交易详情**：
- 方向：SELL
- 入场价：1.5427
- 出场价：1.7289
- 价格涨幅：**12.1%**（做空方向，价格上涨导致亏损）
- 盈亏比例：**-144.8%**（相对于保证金）
- 杠杆：12x
- 平仓类型：自动平仓（止损）
**问题**：
- 做空方向，价格上涨12.1%，但盈亏比例-144.8%，说明止损距离过宽
- 止损没有及时执行，导致亏损扩大
#### 3. LIGHTUSDT #1568: -96.6%
**交易详情**：
- 入场价：0.5309
- 出场价：0.4967
- 价格跌幅：**6.4%**
- 盈亏比例：**-96.6%**（相对于保证金）
- 杠杆：15x
- 平仓类型：自动平仓（止损）
**问题**：
- 价格跌幅6.4%，但盈亏比例-96.6%，说明止损距离过宽或止损没有及时执行
---
### 极端盈利交易分析
#### 1. ENSOUSDT #1565: +398.0%
**交易详情**：
- 入场价：1.7285
- 出场价：2.1871
- 价格涨幅：**26.5%**
- 盈亏比例：**+398.0%**（相对于保证金）
- 杠杆：15x
- 平仓类型：手动平仓
**分析**：
- 价格涨幅26.5%，盈亏比例+398.0%，说明杠杆和持仓时间都很好
- 但这是手动平仓，可能过早止盈（如果继续持有可能更高）
#### 2. NOMUSDT #1567: +289.3%
**交易详情**：
- 入场价：0.008674
- 出场价：0.010347
- 价格涨幅：**19.3%**
- 盈亏比例：**+289.3%**（相对于保证金）
- 杠杆：15x
- 平仓类型：自动平仓（止盈）
**分析**：
- 价格涨幅19.3%，盈亏比例+289.3%，说明止盈目标设置合理
- 这是自动止盈，说明策略执行正确
---
## 🎯 与目标对比
### 目标指标（山寨币策略）
| 指标 | 目标值 | 实际值 | 达成度 |
|------|--------|--------|--------|
| **胜率** | 35% | 42.67% | ✅ **122%**（超出） |
| **盈亏比** | 4.0:1 | 1.68:1 | ❌ **42%**（严重不足） |
| **期望值** | +0.75%/笔 | +0.10 USDT/笔 | ⚠️ 需要统一计算标准 |
---
## 📈 改进建议
### 1. 立即修复止损失效问题
**问题**：8笔极端亏损交易（>50%），说明止损没有及时执行
**解决方案**：
1. ✅ 检查止损单是否正确挂到交易所
2. ✅ 检查止损价格计算是否正确
3. ✅ 检查WebSocket监控是否正常
4. ✅ 添加止损失效告警
### 2. 提升盈亏比到至少2.5:1
**问题**：当前盈亏比1.68:1，远低于目标4.0:1
**解决方案**：
1. ✅ 检查止盈逻辑，确保达到4:1目标
2. ✅ 检查止损设置，避免单笔亏损过大
3. ⚠️ **减少手动平仓**，让系统自动执行策略
4. ✅ 检查是否有过早止盈或过晚止损
### 3. 减少手动干预
**问题**：28笔手动平仓（34.6%），破坏了策略设计
**解决方案**：
1. ⚠️ **减少手动干预**，信任系统策略
2. ✅ 检查是否有系统故障导致止损/止盈失效
3. ✅ 检查数据标记是否正确
### 4. 优化止盈目标
**问题**：止盈数量少于止损（18 vs 27）
**解决方案**：
1. ✅ 检查止盈目标是否设置太高
2. ✅ 检查是否有过早止盈
3. ✅ 确保达到4:1盈亏比目标
---
## 📊 平仓原因分布
| 平仓原因 | 数量 | 比例 | 评价 |
|----------|------|------|------|
| **止损** | 27 | 33.3% | ⚠️ 比例较高 |
| **止盈** | 18 | 22.2% | ⚠️ 比例较低 |
| **手动平仓** | 28 | 34.6% | ❌ **比例过高** |
| **同步平仓** | 2 | 2.5% | ✅ 正常 |
**分析**：
- 止损和止盈比例接近（27:18），但止盈少于止损
- 手动平仓比例过高（34.6%），需要关注
- 如果手动平仓主要是过早止盈，会降低盈亏比
---
## 🔍 关键发现
### 1. 盈亏比严重不足
**原因**：
1. **极端亏损交易过多**：8笔极端亏损交易（>50%），拉低了平均亏损
2. **止盈过早**：部分盈利单可能过早止盈，拉低了平均盈利
3. **手动平仓干扰**：28笔手动平仓可能破坏了策略设计
### 2. 止损失效问题严重
**证据**：
- 8笔极端亏损交易（>50%）
- 部分交易价格跌幅不大，但盈亏比例很大
- 说明止损没有及时执行
### 3. 手动平仓比例过高
**影响**：
- 破坏了策略的盈亏比设计
- 可能过早止盈或过晚止损
- 需要减少手动干预
---
## 🚀 下一步行动
### 立即执行
1. **修复止损失效问题**：
- 检查止损单是否正确挂到交易所
- 检查止损价格计算是否正确
- 检查WebSocket监控是否正常
2. **减少手动干预**：
- 减少手动平仓
- 信任系统策略
- 检查是否有系统故障
3. **优化止盈目标**：
- 检查止盈目标是否设置太高
- 确保达到4:1盈亏比目标
### 持续监控
1. **监控盈亏比**：目标提升到至少2.5:1
2. **监控极端亏损**：避免单笔亏损>50%
3. **监控手动平仓比例**：目标降低到<10%
---
## ✅ 总结
### 表现良好的方面
1. ✅ 胜率优秀（42.67% > 目标35%）
2. ✅ 总盈亏为正（+7.37 USDT）
3. ✅ 平均持仓时长合理（80分钟）
### 严重问题
1. ❌ 盈亏比严重不足（1.68:1 vs 目标4.0:1）
2. ❌ 极端亏损交易过多（8笔>50%）
3. ❌ 手动平仓比例过高（34.6%）
4. ❌ 止损失效问题严重
### 关键改进方向
1. **立即修复止损失效问题**
2. **提升盈亏比到至少2.5:1**
3. **减少手动干预**
4. **优化止盈目标**
---
## 📝 备注
- 本报告基于2026-01-25的交易数据
- 数据来源：`trading_system/交易记录_2026-01-25T11-46-37.json`
- 分析时间：2026-01-25

259
docs/交易数据分析_2026-01-27_ATR使用合理性分析.md Normal file
View File

@ -0,0 +1,259 @@
# 交易数据分析 - ATR使用合理性分析（2026-01-27）
## 📊 交易数据统计
### 基本统计（基于交易记录_2026-01-27T02-26-05.json）
**总交易数**：20单
- **持仓中**：6单（30%）
- **已平仓**：14单（70%）
**已平仓交易分析**：
- **止盈单**：2单（14.3%）
- CHZUSDT BUY: +24.51%
- ZROUSDT SELL: +30.18%
- **止损单**：10单（71.4%）
- SANDUSDT SELL: -12.33%
- AXLUSDT BUY: -0.95%
- AXSUSDT BUY: +4.93%（标记为止损，但实际盈利）
- AXSUSDT BUY: -0.61%
- AXLUSDT BUY: +7.78%（标记为止损，但实际盈利）
- AXSUSDT BUY: +12.04%（标记为止损，但实际盈利）
- LPTUSDT SELL: -13.88%
- ZROUSDT BUY: -11.88%
- JTOUSDT BUY: -31.56%
- SANDUSDT SELL: -12.03%
- **同步平仓**：2单（14.3%）
- AUCTIONUSDT BUY: -12.22%
- ZETAUSDT BUY: -35.54%
- AXSUSDT SELL: -16.37%
**严重问题单**：
- AXSUSDT SELL: -65.84%（巨额亏损）
- ZETAUSDT BUY: -35.54%（巨额亏损）
- JTOUSDT BUY: -31.56%（巨额亏损）
---
## 🚨 核心问题分析
### 问题1：胜率极低
**统计数据**：
- 已平仓：14单
- 盈利单：5单（35.7%）
- 亏损单：9单（64.3%）
- **胜率：35.7%**（严重偏低）
**问题分析**：
- 止损单比例过高（71.4%）
- 止盈单比例过低（14.3%）
- 巨额亏损单较多（-65.84%, -35.54%, -31.56%）
---
### 问题2：巨额亏损单
#### AXSUSDT SELL 单（交易ID: 1755）
- **入场价**：2.43
- **出场价**：2.63
- **方向**：SELL（做空）
- **盈亏比例**：-65.84%
- **持仓时长**：约8小时
**问题分析**：
- 做空单，价格从2.43涨到2.63，涨幅8.23%
- 但亏损比例达到-65.84%，说明止损价格设置错误
- 如果止损价格正确，应该在价格涨到2.43 × (1 + 止损%)时止损，而不是等到2.63
#### ZETAUSDT BUY 单（交易ID: 1747）
- **入场价**：0.08172
- **出场价**：0.07809
- **方向**：BUY（做多）
- **盈亏比例**：-35.54%
- **持仓时长**：约12小时
**问题分析**：
- 做多单，价格从0.08172跌到0.07809，跌幅4.44%
- 但亏损比例达到-35.54%，说明止损价格设置错误
- 如果止损价格正确，应该在价格跌到0.08172 × (1 - 止损%)时止损，而不是等到0.07809
---
### 问题3：ATR使用合理性
**当前配置**：
- `USE_ATR_STOP_LOSS`: True
- `ATR_STOP_LOSS_MULTIPLIER`: 2.0
- `ATR_TAKE_PROFIT_MULTIPLIER`: 3.0
- `STOP_LOSS_PERCENT`: 0.12（12%）
- `TAKE_PROFIT_PERCENT`: 0.20（20%）
**问题分析**：
1. **ATR止损可能过宽**：
- ATR止损倍数2.0，对于山寨币来说可能过宽
- 如果ATR很大（比如5%），2.0倍就是10%的止损距离
- 但实际止损可能更宽（因为选择"更宽松"的止损）
2. **止损选择逻辑问题**：
- 代码中选择"更宽松"的止损（更远离入场价）
- 对于SELL单，这可能导致止损过宽，出现巨额亏损
3. **ATR止盈可能过高**：
- ATR止盈倍数3.0，如果ATR很大，止盈距离会很大
- 导致止盈单比例过低（14.3%）
---
## 🔍 ATR使用合理性分析
### ATR止损计算逻辑
**当前实现**（`risk_manager.py:602-760`）：
1. 计算ATR止损价：`entry_price × (1 ± ATR% × ATR_STOP_LOSS_MULTIPLIER)`
2. 计算保证金止损价：基于`STOP_LOSS_PERCENT`（12%）
3. 计算价格百分比止损价：基于`MIN_STOP_LOSS_PRICE_PCT`（2%）
4. **选择最终的止损价**：取"更宽松"的（更远离入场价）
**问题**：
- 对于SELL单，选择"更宽松"的止损意味着止损价更高（更远离入场价）
- 这可能导致止损过宽，出现巨额亏损
---
### ATR止盈计算逻辑
**当前实现**（`risk_manager.py:772-844`）：
1. 计算ATR止盈价：基于`ATR_TAKE_PROFIT_MULTIPLIER`（3.0）
2. 计算保证金止盈价：基于`TAKE_PROFIT_PERCENT`（20%）
3. 计算价格百分比止盈价：基于`MIN_TAKE_PROFIT_PRICE_PCT`（3%）
4. **选择最终的止盈价**：取"更宽松"的（更远离入场价）
**问题**：
- 选择"更宽松"的止盈，可能导致止盈目标过高
- 如果ATR很大，ATR止盈倍数3.0会导致止盈距离很大
- 导致止盈单比例过低（14.3%）
---
## ✅ 优化建议
### 建议1：收紧ATR止损倍数（紧急）
**当前配置**：
- `ATR_STOP_LOSS_MULTIPLIER`: 2.0
**建议配置**：
- `ATR_STOP_LOSS_MULTIPLIER`: **1.5**（收紧止损，减少单笔亏损）
**理由**：
- 2.0倍对于山寨币来说可能过宽
- 收紧到1.5倍，既能容忍波动，又能控制风险
- 配合12%的固定止损，应该能更好地控制风险
---
### 建议2：降低ATR止盈倍数（重要）
**当前配置**：
- `ATR_TAKE_PROFIT_MULTIPLIER`: 3.0
**建议配置**：
- `ATR_TAKE_PROFIT_MULTIPLIER`: **2.0**（降低止盈目标，更容易触发）
**理由**：
- 3.0倍对于山寨币来说可能过高
- 降低到2.0倍，更容易触发止盈
- 配合20%的固定止盈，应该能提升止盈单比例
---
### 建议3：优化止损选择逻辑（已修复）
**问题**：
- SELL单选择"更宽松"的止损，导致止损过宽
**修复**：
- 已修复：SELL单选择"更紧"的止损（更接近入场价）
- 应该能减少巨额亏损单
---
### 建议4：优化止盈选择逻辑（建议）
**当前逻辑**：
- 选择"更宽松"的止盈（更远离入场价）
**建议逻辑**：
- 选择"更紧"的止盈（更接近入场价），更容易触发
- 或者，优先使用固定百分比止盈（20%），而不是ATR止盈
---
## 📊 配置调整建议
### 当前配置（问题）
- `ATR_STOP_LOSS_MULTIPLIER`: 2.0（可能过宽）
- `ATR_TAKE_PROFIT_MULTIPLIER`: 3.0（可能过高）
- `STOP_LOSS_PERCENT`: 0.12（12%）
- `TAKE_PROFIT_PERCENT`: 0.20（20%）
### 建议配置（优化）
- `ATR_STOP_LOSS_MULTIPLIER`: **1.5**（收紧止损）
- `ATR_TAKE_PROFIT_MULTIPLIER`: **2.0**（降低止盈目标）
- `STOP_LOSS_PERCENT`: **0.12**（12%，保持）
- `TAKE_PROFIT_PERCENT`: **0.20**（20%，保持）
---
## 🎯 预期效果
### 优化后预期
**止损单比例**：
- 当前：71.4%
- 预期：50% - 60%
**止盈单比例**：
- 当前：14.3%
- 预期：30% - 40%
**胜率**：
- 当前：35.7%
- 预期：45% - 55%
**盈亏比**：
- 当前：需要计算
- 预期：1.5:1 - 2.0:1
---
## ⚠️ 注意事项
1. **ATR倍数调整**：
- 收紧ATR止损倍数，减少单笔亏损
- 降低ATR止盈倍数，提升止盈单比例
2. **止损选择逻辑**：
- 已修复SELL单的止损选择逻辑
- 应该能减少巨额亏损单
3. **止盈选择逻辑**：
- 建议优化止盈选择逻辑，优先使用固定百分比止盈
---
## ✅ 总结
**ATR使用合理性**：
- ⚠️ ATR止损倍数2.0可能过宽，建议收紧到1.5
- ⚠️ ATR止盈倍数3.0可能过高，建议降低到2.0
- ⚠️ 止损选择逻辑已修复，应该能减少巨额亏损单
- ⚠️ 止盈选择逻辑建议优化，优先使用固定百分比止盈
**优化建议**：
- ✅ 收紧ATR止损倍数：2.0 → 1.5
- ✅ 降低ATR止盈倍数：3.0 → 2.0
- ✅ 保持固定止损止盈：12% / 20%

212
docs/交易数据分析_2026-01-27_止损问题分析.md Normal file
View File

@ -0,0 +1,212 @@
# 交易数据分析 - 止损问题分析（2026-01-27）
## 📊 统计数据
- **总交易数**：30
- **胜率**：36.36%
- **总盈亏**：-8.29 USDT
- **平均盈亏**：-0.38 USDT
- **平均持仓时长**：270分钟（4.5小时）
- **平仓原因**：止损 7 / 止盈 2 / 移动止损 3 / 同步 10
- **平均盈利 / 平均亏损**：0.39 : 1（期望 3:1，实际严重失衡）
---
## 🚨 严重问题
### 1. 巨额亏损单
#### AXLUSDT SELL 单（交易ID: 1727）
- **入场价**：0.0731
- **出场价**：0.0815
- **方向**：SELL（做空）
- **盈亏比例**：-91.93%（几乎亏光保证金）
- **持仓时长**：约50小时
**问题分析**：
- 做空单，价格从0.0731涨到0.0815，涨幅11.22%
- 但亏损比例达到-91.93%，说明止损价格设置错误或止损单挂单失败
- 如果止损价格正确，应该在价格涨到0.0731 × (1 + 止损%)时止损，而不是等到0.0815
#### ZROUSDT SELL 单（交易ID: 1725）
- **入场价**：1.9354
- **出场价**：2.0954
- **方向**：SELL（做空）
- **盈亏比例**：-66.14%
- **持仓时长**：约52小时
**问题分析**：
- 做空单，价格从1.9354涨到2.0954，涨幅8.27%
- 亏损比例-66.14%，同样说明止损价格设置错误或止损单挂单失败
---
### 2. 止盈单极少
- **止盈单**：仅2单（6.67%）
- **止损单**：7单（23.33%）
- **移动止损**：3单（10%）
- **同步平仓**：10单（33.33%）
**问题分析**：
- 止盈单比例极低，说明大部分盈利单没有及时止盈
- 可能是止盈价格设置过高，或者止盈单挂单失败
---
### 3. 盈亏比严重失衡
- **期望盈亏比**：3:1
- **实际盈亏比**：0.39:1（严重失衡）
**问题分析**：
- 平均盈利远小于平均亏损
- 说明盈利单盈利幅度小，亏损单亏损幅度大
- 可能是止损设置过宽，止盈设置过紧
---
## 🔍 根本原因分析
### 问题1：SELL单止损价格计算错误
**可能原因**：
1. **止损价格选择逻辑错误**：对于SELL单，应该选择"更紧"的止损（更接近入场价），但代码可能选择了"更松"的止损
2. **止损单挂单失败**：止损单挂单失败后，没有及时执行市价平仓
3. **WebSocket监控延迟**：止损单挂单失败后，依赖WebSocket监控，但监控可能延迟
**代码位置**：`trading_system/risk_manager.py:687-710`
**当前逻辑**：
```python
# 选择最终的止损价：优先ATR，其次保证金，最后价格百分比（取更宽松的）
if side == 'BUY':
# 做多：选择更高的止损价（更宽松）
final_stop_loss = max([p for _, p in candidate_prices])
else:
# 做空：选择更低的止损价（更宽松）
final_stop_loss = min([p for _, p in candidate_prices])
```
**问题**：
- 对于SELL单，选择"更低的止损价"意味着止损价更接近入场价，这是正确的
- 但如果ATR计算的止损价过宽，可能会导致止损价格设置错误
---
### 问题2：止损单挂单失败后处理不当
**可能原因**：
1. **止损单挂单失败**：币安API返回错误（如-2021: Order would immediately trigger）
2. **市价平仓延迟**：止损单挂单失败后，应该立即执行市价平仓，但可能延迟
3. **WebSocket监控延迟**：如果市价平仓也失败，依赖WebSocket监控，但监控可能延迟
**代码位置**：`trading_system/position_manager.py:1286-1316`
**当前逻辑**：
```python
if should_close:
# 立即执行市价平仓
if await self.close_position(symbol, reason='stop_loss'):
logger.info(f"{symbol} ✓ 止损平仓成功")
```
**问题**：
- 如果`close_position`失败，可能没有重试机制
- WebSocket监控可能有延迟，导致止损不及时
---
### 问题3：止盈价格设置过高
**配置分析**：
- `TAKE_PROFIT_PERCENT`: 0.30（30%）
- `ATR_TAKE_PROFIT_MULTIPLIER`: 4.0
- `RISK_REWARD_RATIO`: 4.0
**问题**：
- 30%的止盈目标对于山寨币来说可能过高
- 如果止损距离是15%，那么4.0倍盈亏比意味着止盈距离是60%，这对于山寨币来说很难达到
- 导致大部分盈利单无法及时止盈，最终回吐利润
---
## ✅ 解决方案
### 方案1：修复SELL单止损价格计算（紧急）
**问题**：SELL单止损价格可能计算错误，导致止损过宽
**修复**：
1. 检查`get_stop_loss_price`中SELL单的止损价格选择逻辑
2. 确保SELL单选择"更紧"的止损（更接近入场价）
3. 添加止损价格验证，确保止损价格在合理范围内
---
### 方案2：增强止损单挂单失败后的处理（紧急）
**问题**：止损单挂单失败后，可能没有及时执行市价平仓
**修复**：
1. 增强`close_position`的重试机制
2. 如果市价平仓失败，立即记录错误并告警
3. 增强WebSocket监控，确保及时止损
---
### 方案3：调整止盈策略（重要）
**问题**：止盈价格设置过高，导致盈利单无法及时止盈
**建议**：
1. **降低第一目标止盈**：从30%降低到20%
2. **降低盈亏比**：从4.0降低到3.0
3. **启用移动止损**：盈利后启用移动止损，保护利润
---
### 方案4：检查配置值格式（重要）
**问题**：配置值可能仍然是百分比形式（如30），而不是比例形式（0.30）
**检查**：
1. 确认数据库中的配置值已经是比例形式（0.30）
2. 确认Redis缓存中的配置值也是比例形式（0.30）
3. 如果还有百分比形式的值，需要执行数据迁移
---
## 📝 建议的配置调整
### 当前配置（问题）
- `TAKE_PROFIT_PERCENT`: 0.30（30%，过高）
- `ATR_TAKE_PROFIT_MULTIPLIER`: 4.0（过高）
- `RISK_REWARD_RATIO`: 4.0（过高）
- `STOP_LOSS_PERCENT`: 0.15（15%，可能过宽）
### 建议配置（优化）
- `TAKE_PROFIT_PERCENT`: 0.20（20%，更容易触发）
- `ATR_TAKE_PROFIT_MULTIPLIER`: 3.0（降低，更容易触发）
- `RISK_REWARD_RATIO`: 3.0（降低，更容易触发）
- `STOP_LOSS_PERCENT`: 0.12（12%，收紧止损）
- `USE_TRAILING_STOP`: True（启用移动止损，保护利润）
---
## 🎯 优先级
1. **紧急**：修复SELL单止损价格计算
2. **紧急**：增强止损单挂单失败后的处理
3. **重要**：调整止盈策略（降低止盈目标）
4. **重要**：检查配置值格式
---
## 📊 预期效果
修复后预期：
- ✅ SELL单止损价格正确，不再出现巨额亏损
- ✅ 止损单挂单失败后及时平仓
- ✅ 止盈单比例提升（从6.67%提升到20%+）
- ✅ 盈亏比改善（从0.39:1提升到1.5:1+）

393
docs/分步止盈vs移动止损_山寨币交易适用性分析.md Normal file
View File

@ -0,0 +1,393 @@
# 分步止盈 vs 移动止损：山寨币交易适用性分析
## 📊 策略对比
### 策略A：单独使用分步止盈
**执行逻辑**：
- 第一目标：30%止盈，平掉50%仓位，锁定30%盈利
- 第二目标：剩余50%仓位追求更高收益（4.0:1盈亏比）
- 剩余50%仓位止损移至成本价（保本）
**特点**：
- ✅ 明确的目标：30%和4.0:1盈亏比
- ✅ 锁定部分利润：50%仓位锁定30%盈利
- ✅ 追求更高收益：剩余50%仓位追求大赢家
- ❌ 固定目标：无法跟随价格动态调整
---
### 策略B：单独使用移动止损
**执行逻辑**：
- 激活条件：盈利30%后激活
- 保护利润：保护15%利润（动态跟随价格）
- 止损价跟随价格上涨，保护15%利润
**特点**：
- ✅ 动态调整：止损价跟随价格上涨
- ✅ 保护利润：始终保护15%利润
- ❌ 可能过早平仓：如果价格快速上涨后回落，可能在15%利润处平仓
- ❌ 无法锁定更高收益：如果价格继续上涨，无法获得更高收益
---
### 策略C：分步止盈 + 移动止损（结合使用）
**执行逻辑**：
- 分步止盈第一目标触发前：移动止损保护利润
- 分步止盈第一目标触发后：平掉50%仓位，剩余50%仓位止损移至成本价，移动止损不再更新
**特点**：
- ✅ 结合两者优势：既有明确目标，又有动态保护
- ✅ 锁定部分利润：50%仓位锁定30%盈利
- ✅ 追求更高收益：剩余50%仓位追求大赢家
- ✅ 动态保护：第一目标触发前，移动止损保护利润
---
## 🔍 山寨币交易特点分析
### 山寨币市场特征
1. **高波动性**：
- 价格可能在短时间内大幅波动（±20-50%）
- 需要快速锁定利润，避免价格快速回落
2. **趋势性强**：
- 强势上涨时，可能连续上涨50-100%甚至更多
- 需要保留部分仓位追求更高收益
3. **快速反转**：
- 价格可能在达到高点后快速回落
- 需要及时保护利润，避免利润回吐
4. **流动性风险**：
- 某些山寨币流动性较差，价格可能跳空
- 需要设置合理的止损，避免大幅亏损
---
## 📈 不同策略在山寨币交易中的表现
### 场景1：强势上涨行情（最佳情况）
**价格走势**：
- 入场价：100
- 涨到130（30%）：触发第一目标/移动止损激活
- 继续涨到160（60%）：继续上涨
- 继续涨到200（100%）：继续上涨
#### 策略A：单独使用分步止盈
**执行**：
- 130时：平掉50%仓位，锁定30%盈利（15 USDT）
- 剩余50%仓位止损移至成本价（保本）
- 160时：未触发第二目标（4.0:1盈亏比需要更高价格）
- 200时：触发第二目标，平掉剩余50%仓位，获得60%盈利（30 USDT）
**总收益**：15 + 30 = 45 USDT ✅
---
#### 策略B：单独使用移动止损
**执行**：
- 130时：移动止损激活，止损移至成本价（保本）
- 160时：移动止损更新，保护15%利润（止损价 = 145）
- 200时：移动止损更新，保护15%利润（止损价 = 185）
- 如果价格回落至185：触发止损，全部平仓，获得15%盈利（15 USDT）
**总收益**：15 USDT ⚠️（如果价格回落）
**如果价格不回落到185**：
- 继续持有，可能获得更高收益
- 但如果价格快速回落，可能在15%利润处平仓
---
#### 策略C：分步止盈 + 移动止损
**执行**：
- 130时：分步止盈第一目标触发，平掉50%仓位，锁定30%盈利（15 USDT）
- 剩余50%仓位止损移至成本价（保本），移动止损不再更新
- 200时：触发第二目标，平掉剩余50%仓位，获得60%盈利（30 USDT）
**总收益**：15 + 30 = 45 USDT ✅
**优势**：
- 第一目标触发前，移动止损保护利润
- 第一目标触发后，分步止盈锁定30%盈利，剩余50%追求更高收益
---
### 场景2：快速上涨后回落（风险情况）
**价格走势**：
- 入场价：100
- 涨到130（30%）：触发第一目标/移动止损激活
- 快速回落至100（成本价）：价格回落
#### 策略A：单独使用分步止盈
**执行**：
- 130时：平掉50%仓位，锁定30%盈利（15 USDT）
- 剩余50%仓位止损移至成本价（保本）
- 100时：触发止损，剩余50%仓位保本平仓
**总收益**：15 USDT ✅（锁定30%盈利）
---
#### 策略B：单独使用移动止损
**执行**：
- 130时：移动止损激活，止损移至成本价（保本）
- 100时：触发止损，全部平仓，保本
**总收益**：0 USDT ⚠️（如果价格快速回落至成本价）
**如果价格回落到115（15%利润）**：
- 移动止损保护15%利润，全部平仓
- 总收益：15 USDT ✅
---
#### 策略C：分步止盈 + 移动止损
**执行**：
- 130时：分步止盈第一目标触发，平掉50%仓位，锁定30%盈利（15 USDT）
- 剩余50%仓位止损移至成本价（保本）
- 100时：触发止损，剩余50%仓位保本平仓
**总收益**：15 USDT ✅（锁定30%盈利）
---
### 场景3：震荡上涨行情（常见情况）
**价格走势**：
- 入场价：100
- 涨到130（30%）：触发第一目标/移动止损激活
- 回落至120，然后涨到160（60%）：震荡上涨
- 回落至140，然后涨到200（100%）：继续震荡上涨
#### 策略A：单独使用分步止盈
**执行**：
- 130时：平掉50%仓位，锁定30%盈利（15 USDT）
- 剩余50%仓位止损移至成本价（保本）
- 160时：未触发第二目标
- 200时：触发第二目标，平掉剩余50%仓位，获得60%盈利（30 USDT）
**总收益**：15 + 30 = 45 USDT ✅
---
#### 策略B：单独使用移动止损
**执行**：
- 130时：移动止损激活，止损移至成本价（保本）
- 120时：价格回落，但未触发止损（止损在成本价）
- 160时：移动止损更新，保护15%利润（止损价 = 145）
- 140时：价格回落，触发止损，全部平仓，获得15%盈利（15 USDT）
**总收益**：15 USDT ⚠️（如果价格回落触发止损）
**如果价格不回落到145**：
- 继续持有，200时可能获得更高收益
- 但如果价格回落，可能在15%利润处平仓
---
#### 策略C：分步止盈 + 移动止损
**执行**：
- 130时：分步止盈第一目标触发，平掉50%仓位，锁定30%盈利（15 USDT）
- 剩余50%仓位止损移至成本价（保本），移动止损不再更新
- 140时：价格回落，但未触发止损（止损在成本价）
- 200时：触发第二目标，平掉剩余50%仓位，获得60%盈利（30 USDT）
**总收益**：15 + 30 = 45 USDT ✅
**优势**：
- 第一目标触发前，移动止损保护利润
- 第一目标触发后，分步止盈锁定30%盈利，剩余50%追求更高收益
- 即使价格震荡，也能获得更高收益
---
## 🎯 山寨币交易适用性评估
### 单独使用分步止盈
**优势**：
- ✅ **明确的目标**：30%和4.0:1盈亏比，目标清晰
- ✅ **锁定部分利润**：50%仓位锁定30%盈利，不会全部回吐
- ✅ **追求更高收益**：剩余50%仓位追求大赢家，不错过更大行情
- ✅ **适合强势上涨**：如果市场强势上涨，可以获得更高收益
**劣势**：
- ❌ **无法动态调整**：止损价固定在成本价，无法跟随价格上涨
- ❌ **可能错过保护**：如果价格快速上涨后快速回落，可能无法及时保护利润
**适用场景**：
- ✅ 强势上涨行情
- ✅ 趋势明确的行情
- ✅ 流动性较好的山寨币
---
### 单独使用移动止损
**优势**：
- ✅ **动态保护**：止损价跟随价格上涨，始终保护15%利润
- ✅ **及时保护**：如果价格快速上涨后回落，可以及时保护利润
- ✅ **适合震荡行情**：如果价格震荡上涨，可以保护利润
**劣势**：
- ❌ **可能过早平仓**：如果价格快速上涨后回落，可能在15%利润处平仓
- ❌ **无法锁定更高收益**：如果价格继续上涨，无法获得更高收益
- ❌ **目标不明确**：没有明确的止盈目标，可能错过更大行情
**适用场景**：
- ✅ 震荡上涨行情
- ✅ 波动较大的行情
- ✅ 需要及时保护利润的行情
---
### 分步止盈 + 移动止损（结合使用）
**优势**：
- ✅ **结合两者优势**：既有明确目标，又有动态保护
- ✅ **锁定部分利润**：50%仓位锁定30%盈利
- ✅ **追求更高收益**：剩余50%仓位追求大赢家
- ✅ **动态保护**：第一目标触发前，移动止损保护利润
- ✅ **适合各种行情**：强势上涨、震荡上涨、快速回落都能应对
**劣势**：
- ⚠️ **复杂度稍高**：需要管理两个策略
- ⚠️ **可能过度保护**：第一目标触发前，移动止损可能过早保护利润
**适用场景**：
- ✅ **所有行情**：强势上涨、震荡上涨、快速回落
- ✅ **最适合山寨币**：结合了锁定利润和追求更高收益的优势
---
## 📊 收益率对比
### 假设场景：入场100 USDT，价格涨到200（100%）
| 策略 | 第一目标收益 | 第二目标收益 | 总收益 | 评价 |
|------|------------|------------|--------|------|
| **分步止盈** | 15 USDT（50%仓位×30%） | 30 USDT（50%仓位×60%） | **45 USDT** | ✅ 最优 |
| **移动止损** | 15 USDT（全部仓位×15%） | - | **15 USDT** | ⚠️ 较低 |
| **分步止盈+移动止损** | 15 USDT（50%仓位×30%） | 30 USDT（50%仓位×60%） | **45 USDT** | ✅ 最优 |
---
### 假设场景：入场100 USDT，价格涨到130后回落至100
| 策略 | 第一目标收益 | 第二目标收益 | 总收益 | 评价 |
|------|------------|------------|--------|------|
| **分步止盈** | 15 USDT（50%仓位×30%） | 0 USDT（剩余50%保本） | **15 USDT** | ✅ 最优 |
| **移动止损** | 0 USDT（全部保本） | - | **0 USDT** | ❌ 最差 |
| **分步止盈+移动止损** | 15 USDT（50%仓位×30%） | 0 USDT（剩余50%保本） | **15 USDT** | ✅ 最优 |
---
### 假设场景：入场100 USDT，价格涨到130后回落至115
| 策略 | 第一目标收益 | 第二目标收益 | 总收益 | 评价 |
|------|------------|------------|--------|------|
| **分步止盈** | 15 USDT（50%仓位×30%） | 0 USDT（剩余50%保本） | **15 USDT** | ✅ 最优 |
| **移动止损** | 15 USDT（全部仓位×15%） | - | **15 USDT** | ✅ 相同 |
| **分步止盈+移动止损** | 15 USDT（50%仓位×30%） | 0 USDT（剩余50%保本） | **15 USDT** | ✅ 最优 |
---
## 🎯 最终结论
### 针对山寨币交易
**推荐策略**：✅ **分步止盈 + 移动止损（结合使用）**
**理由**：
1. **锁定部分利润**：分步止盈第一目标锁定30%盈利，不会全部回吐
2. **追求更高收益**：剩余50%仓位追求大赢家，不错过更大行情
3. **动态保护**：第一目标触发前，移动止损保护利润
4. **适合各种行情**：强势上涨、震荡上涨、快速回落都能应对
**单独使用分步止盈**：
- ✅ 适合强势上涨行情
- ⚠️ 如果价格快速回落，可能无法及时保护利润
**单独使用移动止损**：
- ✅ 适合震荡上涨行情
- ❌ 如果价格继续上涨，无法获得更高收益
- ❌ 如果价格快速回落，可能过早平仓
---
### 收益率对比
**强势上涨行情**：
- 分步止盈：45 USDT ✅
- 移动止损：15 USDT ⚠️
- 分步止盈+移动止损：45 USDT ✅
**快速回落行情**：
- 分步止盈：15 USDT ✅
- 移动止损：0-15 USDT ⚠️
- 分步止盈+移动止损：15 USDT ✅
**震荡上涨行情**：
- 分步止盈：45 USDT ✅
- 移动止损：15 USDT ⚠️
- 分步止盈+移动止损：45 USDT ✅
---
## ✅ 最终建议
### 针对山寨币交易
**推荐**：✅ **分步止盈 + 移动止损（结合使用）**
**原因**：
1. **收益率最高**：在强势上涨行情中，可以获得45 USDT收益
2. **风险可控**：在快速回落行情中，可以锁定15 USDT收益
3. **适合各种行情**：强势上涨、震荡上涨、快速回落都能应对
4. **最适合山寨币**：结合了锁定利润和追求更高收益的优势
**单独使用分步止盈**：
- ⚠️ 适合强势上涨行情，但可能无法及时保护利润
**单独使用移动止损**：
- ❌ 收益率较低，无法获得更高收益
---
## 📝 总结
### 收益率排名
1. **分步止盈 + 移动止损**：✅ **最优**（45 USDT）
2. **单独使用分步止盈**：✅ **次优**（45 USDT，但可能无法及时保护利润）
3. **单独使用移动止损**：⚠️ **较低**（15 USDT）
### 山寨币交易适用性排名
1. **分步止盈 + 移动止损**：✅ **最适合**（结合两者优势）
2. **单独使用分步止盈**：✅ **适合**（强势上涨行情）
3. **单独使用移动止损**：⚠️ **一般**（收益率较低）
### 最终建议
**针对山寨币交易，推荐使用分步止盈 + 移动止损（结合使用）**，因为：
- ✅ 收益率最高（45 USDT vs 15 USDT）
- ✅ 风险可控（锁定30%盈利）
- ✅ 适合各种行情（强势上涨、震荡上涨、快速回落）
- ✅ 最适合山寨币高波动特点

255
docs/分步止盈与移动止损兼容性分析.md Normal file
View File

@ -0,0 +1,255 @@
# 分步止盈与移动止损兼容性分析
## 📊 策略概述
### 分步止盈策略
**第一目标**：30%固定止盈（基于保证金）
- 触发条件：盈利达到30%
- 执行动作：平掉50%仓位，锁定30%盈利
- 后续处理：剩余50%仓位止损移至成本价（保本）
**第二目标**：追求更高收益（4.0:1盈亏比）
- 触发条件：剩余50%仓位盈利达到4.0:1盈亏比
- 执行动作：平掉剩余50%仓位
### 移动止损策略
**激活条件**：盈利30%后激活
- 触发条件：盈利达到30%
- 执行动作：止损移至成本价（保本）
**保护利润**：保护15%利润
- 触发条件：移动止损激活后，价格继续上涨
- 执行动作：止损价跟随价格上涨，保护15%利润
---
## 🔍 兼容性分析
### 执行顺序
**代码执行顺序**（`trading_system/position_manager.py:_check_single_position`）：
1. **移动止损检查**（2693-2757行）
- 先检查移动止损是否激活
- 如果盈利30%，激活移动止损，止损移至成本价
2. **止损检查**（2759-2828行）
- 检查是否触发止损
- 如果触发，立即平仓
3. **分步止盈检查**（2830-2894行）
- 检查第一目标（30%止盈）
- 如果触发，平掉50%仓位
- 检查第二目标（4.0:1盈亏比）
### 兼容性场景分析
#### 场景1：盈利达到30%
**移动止损**：
- 盈利30% → 移动止损激活
- 止损移至成本价（保本）
**分步止盈**：
- 盈利30% → 第一目标触发
- 平掉50%仓位，锁定30%盈利
- 剩余50%仓位止损移至成本价（保本）
**兼容性**：✅ **完全兼容**
- 移动止损激活后，止损移至成本价
- 分步止盈第一目标触发后，平掉50%仓位，剩余50%仓位止损也移至成本价
- 两者不冲突，可以同时生效
---
#### 场景2：盈利30%后继续上涨
**移动止损**：
- 盈利30% → 移动止损激活，止损移至成本价
- 盈利继续上涨 → 止损价跟随上涨，保护15%利润
**分步止盈**：
- 盈利30% → 第一目标触发，平掉50%仓位
- 剩余50%仓位止损移至成本价（保本）
- 盈利继续上涨 → 等待第二目标（4.0:1盈亏比）
**兼容性**：⚠️ **潜在冲突**
**问题**：
- 移动止损会持续更新止损价，保护15%利润
- 但分步止盈第一目标触发后，剩余50%仓位止损已移至成本价
- 如果移动止损继续更新，可能会覆盖分步止盈设置的止损价
**解决方案**：
- 如果分步止盈第一目标已触发，移动止损应该只作用于剩余50%仓位
- 或者，分步止盈第一目标触发后，禁用移动止损对剩余仓位的更新
---
#### 场景3：盈利30%后回落
**移动止损**：
- 盈利30% → 移动止损激活，止损移至成本价
- 价格回落至成本价 → 触发止损，全部平仓
**分步止盈**：
- 盈利30% → 第一目标触发，平掉50%仓位
- 剩余50%仓位止损移至成本价（保本）
- 价格回落至成本价 → 触发止损，剩余50%仓位平仓
**兼容性**：✅ **完全兼容**
- 两种策略都会在成本价触发止损
- 分步止盈已经锁定了50%仓位的30%盈利
- 移动止损保护剩余50%仓位不亏损
---
## 🎯 实际执行逻辑
### 当前代码逻辑
**移动止损**（2715-2757行）：
```python
if use_trailing:
if not position_info.get('trailingStopActivated', False):
# 盈利30%后激活
if pnl_percent_margin > trailing_activation * 100:
position_info['trailingStopActivated'] = True
position_info['stopLoss'] = entry_price # 止损移至成本价
else:
# 移动止损更新，保护15%利润
new_stop_loss = entry_price + (pnl_amount - protect_amount) / quantity
if new_stop_loss > position_info['stopLoss']:
position_info['stopLoss'] = new_stop_loss
```
**分步止盈**（2842-2864行）：
```python
# 第一目标：30%固定止盈
if not partial_profit_taken and take_profit_1 is not None:
if pnl_percent_margin >= take_profit_1_pct_margin:
# 平掉50%仓位
partial_quantity = quantity * 0.5
# ... 部分平仓逻辑 ...
position_info['partialProfitTaken'] = True
position_info['remainingQuantity'] = remaining_quantity - partial_quantity
# 剩余仓位止损移至成本价（保本）
position_info['stopLoss'] = entry_price
```
### 潜在问题
**问题1**：移动止损和分步止盈同时触发30%
**当前行为**：
- 移动止损：盈利30% → 止损移至成本价
- 分步止盈：盈利30% → 平掉50%仓位，剩余50%仓位止损移至成本价
**结果**：
- 如果移动止损先执行，止损移至成本价
- 然后分步止盈执行，平掉50%仓位，剩余50%仓位止损也移至成本价
- ✅ **不冲突**，但可能重复设置止损价
**问题2**：分步止盈第一目标触发后，移动止损继续更新
**当前行为**：
- 分步止盈第一目标触发后，剩余50%仓位止损移至成本价
- 移动止损继续运行，可能会更新止损价（保护15%利润）
**结果**：
- 如果价格继续上涨，移动止损会更新止损价
- 但分步止盈已经将止损移至成本价
- ⚠️ **可能冲突**：移动止损可能会覆盖分步止盈设置的止损价
---
## ✅ 兼容性结论
### 总体兼容性：✅ **基本兼容，但需要优化**
**兼容的方面**：
1. ✅ 两个策略的目标一致：保护利润
2. ✅ 分步止盈第一目标触发后，剩余50%仓位止损移至成本价，与移动止损的保本目标一致
3. ✅ 两个策略可以同时生效，不会导致逻辑错误
**需要优化的方面**：
1. ⚠️ 分步止盈第一目标触发后，移动止损应该只作用于剩余50%仓位
2. ⚠️ 或者，分步止盈第一目标触发后，禁用移动止损对剩余仓位的更新
3. ⚠️ 需要明确执行优先级：分步止盈优先，还是移动止损优先
---
## 🔧 优化建议
### 方案1：分步止盈优先（推荐）
**逻辑**：
- 如果分步止盈第一目标已触发，移动止损不再更新剩余仓位的止损价
- 剩余50%仓位止损保持在成本价（保本），等待第二目标
**代码修改**：
```python
# 移动止损逻辑
if use_trailing:
# 如果分步止盈第一目标已触发，不再更新移动止损
if position_info.get('partialProfitTaken', False):
# 分步止盈已触发，移动止损不再更新
pass
else:
# 正常的移动止损逻辑
# ...
```
### 方案2：移动止损作用于剩余仓位
**逻辑**：
- 分步止盈第一目标触发后，移动止损继续作用于剩余50%仓位
- 但需要基于剩余仓位的保证金和数量计算
**代码修改**：
```python
# 移动止损逻辑
if use_trailing:
if position_info.get('partialProfitTaken', False):
# 分步止盈已触发，使用剩余仓位计算移动止损
remaining_quantity = position_info.get('remainingQuantity', quantity)
remaining_margin = (entry_price * remaining_quantity) / leverage
# 基于剩余仓位计算移动止损
# ...
else:
# 正常的移动止损逻辑
# ...
```
---
## 📝 总结
### 分步止盈策略收益分析文档
**文档仍然有用**：✅
**原因**：
1. 文档分析了分步止盈策略的数学期望和实际效果
2. 文档提供了不同市场场景下的收益对比
3. 文档的建议仍然适用
**需要更新**：
- 添加移动止损与分步止盈的兼容性说明
- 更新实际执行逻辑的描述
### 移动止损与分步止盈
**兼容性**：✅ **基本兼容，但需要优化**
**建议**：
1. 保持两个策略同时启用
2. 优化执行逻辑，确保分步止盈第一目标触发后，移动止损不再更新剩余仓位的止损价
3. 或者，让移动止损作用于剩余50%仓位，但需要基于剩余仓位计算
**最终效果**：
- 第一目标：30%止盈，平掉50%仓位，锁定30%盈利 ✅
- 剩余50%仓位：止损移至成本价（保本），等待第二目标 ✅
- 移动止损：在分步止盈第一目标触发前，保护利润 ✅

184
docs/分步止盈优化_30%固定止盈.md Normal file
View File

@ -0,0 +1,184 @@
# 分步止盈优化：30%固定止盈策略
## 📊 优化目标
**问题**：
- 止盈目标30%虽然更容易触发，但可能会错过更多收益
- 用户希望：保证拿到30%盈利，然后留一部分去追求更高利润
**解决方案**：
- 第一目标：30%固定止盈（基于保证金），平掉50%仓位，**保证拿到30%盈利**
- 第二目标：追求更高收益（4.0:1盈亏比或更高），平掉剩余50%仓位
---
## 🔧 修改内容
### 1. 开仓时计算分步止盈目标
**文件**：`trading_system/position_manager.py`
**修改前**：
```python
# 分步止盈（基于"实际成交价 + 已计算的止损/止盈"）
if side == 'BUY':
take_profit_1 = entry_price + (entry_price - stop_loss_price) # 盈亏比1:1
else:
take_profit_1 = entry_price - (stop_loss_price - entry_price) # 盈亏比1:1
take_profit_2 = take_profit_price
```
**修改后**：
```python
# 分步止盈策略：
# 第一目标：30%固定止盈（基于保证金），平掉50%仓位，保证拿到30%盈利
# 第二目标：追求更高收益（4.0:1盈亏比或更高），平掉剩余50%仓位
take_profit_1_pct_margin = config.TRADING_CONFIG.get('TAKE_PROFIT_PERCENT', 0.30) # 30%固定止盈
take_profit_1 = self.risk_manager.get_take_profit_price(
entry_price, side, quantity, leverage,
take_profit_pct=take_profit_1_pct_margin,
atr=atr,
stop_distance=stop_distance_for_tp
)
take_profit_2 = take_profit_price # 第二目标：追求更高收益（4.0:1盈亏比或更高）
```
**改进**：
- ✅ 第一目标从"盈亏比1:1"改为"30%固定止盈"
- ✅ 保证拿到30%盈利，然后留一部分去追求更高利润
- ✅ 使用 `TAKE_PROFIT_PERCENT` 配置项（30%）
---
### 2. 实时监控中的第一目标触发逻辑
**文件**：`trading_system/position_manager.py`
**修改前**：
```python
logger.info(
f"{symbol} [实时监控] 触发第一目标止盈（盈亏比1:1，基于保证金）: "
f"当前盈亏={pnl_percent_margin:.2f}% of margin >= 目标={take_profit_1_pct_margin:.2f}% of margin | "
f"当前价={current_price_float:.4f}, 目标价={take_profit_1:.4f}"
)
```
**修改后**：
```python
logger.info(
f"{symbol} [实时监控] 触发第一目标止盈（30%固定止盈，基于保证金）: "
f"当前盈亏={pnl_percent_margin:.2f}% of margin >= 目标={take_profit_1_pct_margin:.2f}% of margin | "
f"当前价={current_price_float:.4f}, 目标价={take_profit_1:.4f} | "
f"将平掉50%仓位，锁定30%盈利，剩余50%追求更高收益"
)
```
**改进**：
- ✅ 日志更清晰地说明第一目标是"30%固定止盈"
- ✅ 说明将平掉50%仓位，锁定30%盈利，剩余50%追求更高收益
---
### 3. 推荐系统中的第一目标计算
**文件**：`trading_system/trade_recommender.py`
**修改前**：
```python
# 第一目标：盈亏比1:1（快速锁定利润，设置保本损）
take_profit_1_pct_margin = stop_loss_pct_margin * 1.0
take_profit_1 = self.risk_manager.get_take_profit_price(
entry_price, direction, estimated_quantity, leverage,
take_profit_pct=take_profit_1_pct_margin
)
```
**修改后**：
```python
# 第一目标：30%固定止盈（基于保证金），保证拿到30%盈利，然后留一部分去追求更高利润
take_profit_1_pct_margin = config.TRADING_CONFIG.get('TAKE_PROFIT_PERCENT', 0.30) # 30%固定止盈
take_profit_1 = self.risk_manager.get_take_profit_price(
entry_price, direction, estimated_quantity, leverage,
take_profit_pct=take_profit_1_pct_margin
)
```
**改进**：
- ✅ 推荐系统中的第一目标也改为"30%固定止盈"
- ✅ 与交易系统保持一致
---
## 📈 策略效果
### 修改前
**第一目标**：盈亏比1:1
- 如果止损是15%，第一目标是15%
- 平掉50%仓位，锁定15%盈利
- 剩余50%追求4.0:1盈亏比（60%）
**问题**：
- 第一目标15%可能不够，用户希望保证拿到30%盈利
### 修改后
**第一目标**：30%固定止盈
- 第一目标是30%（基于保证金）
- 平掉50%仓位，**保证拿到30%盈利**
- 剩余50%追求更高收益（4.0:1盈亏比或更高）
**优势**：
- ✅ 保证拿到30%盈利，不会错过收益
- ✅ 剩余50%仓位追求更高收益，不错过更大行情
- ✅ 分步止盈策略更合理
---
## 🎯 示例计算
### 示例：AXSUSDT BUY
**假设**：
- 入场价：2.033
- 保证金：2.54125 USDT
- 杠杆：8倍
- 数量：10
- 止损：15%（基于保证金）
**第一目标（30%固定止盈）**：
- 止盈金额 = `2.54125 × 0.30 = 0.762375 USDT`
- 止盈距离 = `0.762375 / 10 = 0.0762375 USDT`
- 止盈价 = `2.033 + 0.0762375 = 2.1092375 USDT`
- 价格涨幅 = `0.0762375 / 2.033 = 3.75%`
**第二目标（4.0:1盈亏比）**：
- 止损距离 = `2.033 × 0.01875 = 0.03811875 USDT`（15% / 8 = 1.875%）
- 止盈距离 = `0.03811875 × 4.0 = 0.152475 USDT`
- 止盈价 = `2.033 + 0.152475 = 2.185475 USDT`
- 价格涨幅 = `0.152475 / 2.033 = 7.5%`
**执行流程**：
1. 价格涨到2.109（3.75%），触发第一目标
2. 平掉50%仓位（5个），锁定30%盈利
3. 剩余50%仓位（5个）止损移至成本价（保本）
4. 价格继续涨到2.185（7.5%），触发第二目标
5. 平掉剩余50%仓位（5个），获得4.0:1盈亏比
**总收益**：
- 第一目标：`5 × 0.762375 = 3.811875 USDT`（30%盈利）
- 第二目标：`5 × 0.152475 = 0.762375 USDT`（4.0:1盈亏比）
- 总盈利：`3.811875 + 0.762375 = 4.57425 USDT`（约180%基于保证金）
---
## ✅ 修改完成
**修改文件**：
1. `trading_system/position_manager.py`：开仓时计算分步止盈目标，实时监控中的第一目标触发逻辑
2. `trading_system/trade_recommender.py`：推荐系统中的第一目标计算
**下一步**：
1. 重启交易进程，让修改生效
2. 观察后续交易，确认分步止盈是否按预期执行
3. 验证第一目标是否为30%固定止盈，第二目标是否为更高收益

287
docs/分步止盈策略收益分析.md Normal file
View File

@ -0,0 +1,287 @@
# 分步止盈策略收益分析
> **注意**：本文档分析分步止盈策略的收益情况。分步止盈与移动止损可以同时使用，两者基本兼容。详细兼容性分析请参考：[分步止盈与移动止损兼容性分析.md](./分步止盈与移动止损兼容性分析.md)
## 📊 策略对比
### 策略A：一次性30%止盈（当前策略）
**执行方式**：
- 价格达到30%盈利时，全部平仓
**收益计算**：
- 假设保证金：100 USDT
- 盈利：100 × 30% = 30 USDT
- **总收益：30 USDT**
---
### 策略B：分步止盈（30% + 更高收益）
**执行方式**：
- 第一目标：30%盈利时，平掉50%仓位
- 第二目标：剩余50%仓位追求更高收益（4.0:1盈亏比，约60%盈利）
**收益计算**：
- 假设保证金：100 USDT
- 第一目标（50%仓位）：50 × 30% = 15 USDT ✅ **已锁定**
- 第二目标（50%仓位）：50 × 60% = 30 USDT（如果达到）
- **总收益：15 + 30 = 45 USDT**（如果第二目标达到）
---
## 🔍 数学期望分析
### 场景1：价格达到30%后继续上涨
**策略A（一次性30%止盈）**：
- 收益：30 USDT
- 错过后续上涨：❌ 无法获得更高收益
**策略B（分步止盈）**：
- 第一目标收益：15 USDT ✅ **已锁定**
- 第二目标收益：30 USDT（如果达到）
- **总收益：45 USDT** ✅ **比策略A多50%**
**结论**：✅ **策略B更优**
---
### 场景2：价格达到30%后回落
**策略A（一次性30%止盈）**：
- 收益：30 USDT ✅ **已锁定**
**策略B（分步止盈）**：
- 第一目标收益：15 USDT ✅ **已锁定**
- 第二目标：未达到，剩余50%仓位可能：
- 如果止损移至成本价（保本）：剩余50%不亏不赚
- 如果价格回落但未触发止损：可能亏损
- **总收益：15 USDT**（如果剩余50%保本）
**结论**：⚠️ **策略B收益可能低于策略A，但风险可控**
---
### 场景3：价格未达到30%就回落
**策略A（一次性30%止盈）**：
- 收益：0 USDT（未触发止盈）
**策略B（分步止盈）**：
- 收益：0 USDT（未触发第一目标）
**结论**：⚖️ **两种策略相同**
---
## 📈 概率分析
### 假设市场行为概率
基于历史数据和市场经验，假设：
1. **价格达到30%后继续上涨的概率**：40%
2. **价格达到30%后回落的概率**：60%
### 策略A的期望收益
**场景**：
- 达到30%的概率：假设50%
- 未达到30%的概率：50%
**期望收益**：
```
E(A) = 0.5 × 30 + 0.5 × 0 = 15 USDT
```
---
### 策略B的期望收益
**场景1：价格达到30%后继续上涨（40%概率）**：
- 第一目标收益：15 USDT
- 第二目标收益：30 USDT（假设100%达到）
- 总收益：45 USDT
**场景2：价格达到30%后回落（60%概率）**：
- 第一目标收益：15 USDT
- 第二目标：未达到，剩余50%保本（止损移至成本价）
- 总收益：15 USDT
**期望收益**：
```
E(B) = 0.5 × (0.4 × 45 + 0.6 × 15) + 0.5 × 0
= 0.5 × (18 + 9)
= 13.5 USDT
```
**但这是保守估计**，如果第二目标达到概率更高，期望收益会更高。
---
## 🎯 实际效果评估
### 优势 ✅
1. **锁定部分利润**：
- 第一目标30%时，平掉50%仓位，锁定15%盈利
- 即使后续价格回落，也能保证15%盈利
2. **追求更高收益**：
- 剩余50%仓位追求更高收益（4.0:1盈亏比，约60%）
- 如果市场继续上涨，可以获得更高收益
3. **风险可控**：
- 第一目标触发后，剩余50%仓位止损移至成本价（保本）
- 即使价格回落，剩余50%也不会亏损
4. **心理优势**：
- 第一目标触发后，已经锁定部分利润，心理压力更小
- 剩余50%仓位可以更从容地追求更高收益
---
### 劣势 ⚠️
1. **可能错过部分收益**：
- 如果价格达到30%后立即回落，策略B只能获得15%盈利
- 而策略A可以获得30%盈利
2. **复杂度增加**：
- 需要管理两个止盈目标
- 需要处理部分平仓逻辑
3. **市场波动风险**：
- 如果价格快速波动，可能影响第二目标的触发
---
## 📊 实际交易场景分析
### 场景1：强势上涨行情（最佳情况）
**价格走势**：
- 入场价：100
- 涨到130（30%）：触发第一目标，平掉50%仓位 ✅
- 继续涨到160（60%）：触发第二目标，平掉剩余50%仓位 ✅
**策略A收益**：30 USDT（在130时全部平仓）
**策略B收益**：45 USDT（15 + 30）
**优势**：✅ **策略B多获得50%收益**
---
### 场景2：震荡上涨行情（常见情况）
**价格走势**：
- 入场价：100
- 涨到130（30%）：触发第一目标，平掉50%仓位 ✅
- 回落至120，然后涨到160（60%）：触发第二目标，平掉剩余50%仓位 ✅
**策略A收益**：30 USDT（在130时全部平仓）
**策略B收益**：45 USDT（15 + 30）
**优势**：✅ **策略B多获得50%收益，且剩余50%有保本保护**
---
### 场景3：快速回落行情（风险情况）
**价格走势**：
- 入场价：100
- 涨到130（30%）：触发第一目标，平掉50%仓位 ✅
- 快速回落至100（成本价）：剩余50%保本平仓
**策略A收益**：30 USDT（在130时全部平仓）
**策略B收益**：15 USDT（15 + 0）
**劣势**：⚠️ **策略B收益低于策略A，但风险可控（剩余50%保本）**
---
## 🎯 综合评估
### 数学期望对比
**策略A（一次性30%止盈）**：
- 期望收益：15 USDT（假设50%概率达到30%）
- 风险：如果价格回落，可能无法获得30%收益
**策略B（分步止盈）**：
- 期望收益：13.5-18 USDT（取决于第二目标达到概率）
- 风险：如果价格快速回落，可能只能获得15%收益
**结论**：⚖️ **期望收益相近，但策略B在强势行情中可以获得更高收益**
---
### 实际效果预测
**基于山寨币交易特点**：
1. **高波动性**：
- 山寨币波动大，价格可能快速上涨或回落
- 分步止盈可以锁定部分利润，同时保留追求更高收益的机会
2. **趋势性**：
- 如果市场处于强势上涨趋势，分步止盈可以获得更高收益
- 如果市场震荡，分步止盈可以锁定部分利润
3. **风险控制**：
- 第一目标触发后，剩余50%仓位止损移至成本价（保本）
- 即使价格回落，也不会亏损
---
## ✅ 最终结论
### 是否会提升整体收益？
**答案：取决于市场行情** ✅
**优势情况**（强势上涨行情）：
- ✅ **会显著提升收益**：策略B可以获得45 USDT，比策略A多50%
**劣势情况**（快速回落行情）：
- ⚠️ **可能降低收益**：策略B只能获得15 USDT，比策略A少50%
**平衡情况**（震荡行情）：
- ⚖️ **收益相近**：两种策略收益相近，但策略B风险更可控
---
### 建议
1. **适合使用分步止盈的情况**：
- ✅ 市场处于强势上涨趋势
- ✅ 交易对波动性较大
- ✅ 信号强度较高（9-10分）
2. **不适合使用分步止盈的情况**：
- ⚠️ 市场处于震荡行情
- ⚠️ 交易对波动性较小
- ⚠️ 信号强度较低（5-6分）
3. **优化建议**：
- 可以根据市场状态动态调整分步止盈策略
- 强势行情：使用分步止盈
- 震荡行情：使用一次性止盈
---
## 📊 数据验证建议
**建议通过实际交易数据验证**：
1. **记录两种策略的收益对比**
2. **分析不同市场状态下的表现**
3. **根据实际数据调整策略参数**
**关键指标**：
- 平均盈利
- 平均亏损
- 胜率
- 盈亏比
- 最大回撤

234
docs/单量少和盈利不平仓问题分析.md Normal file
View File

@ -0,0 +1,234 @@
# 单量少和盈利不平仓问题分析
## 问题描述
1. **单量很少**：交易数量明显偏少
2. **仪表板显示盈利**：持仓整体盈利，但无法平仓
3. **不平仓**：盈利单无法触发止盈
4. **单子很少**：交易频率低
---
## 🔍 问题分析
### 问题1：止盈目标设置过高
**当前配置**：
- `TAKE_PROFIT_PERCENT`: 0.60 (60%)
- `ATR_TAKE_PROFIT_MULTIPLIER`: 8.0
- `RISK_REWARD_RATIO`: 4.0
**问题**：
- 止盈目标60%太高，需要盈利60%才能平仓
- ATR止盈倍数8.0太高，如果ATR很小，止盈价会非常远
- 盈亏比4.0:1，意味着止盈距离是止损距离的4倍
**止盈价计算逻辑**：
1. 优先使用ATR方法：`止盈距离 = 止损距离 × RISK_REWARD_RATIO (4.0)`
2. 其次使用保证金方法：`止盈价 = 入场价 ± (保证金 × 60% / 数量)`
3. 最后使用价格百分比方法：`止盈价 = 入场价 × (1 ± 2%)`
4. **取最宽松的（最远的）**
**影响**：
- 如果ATR很小，ATR方法可能计算出很远的止盈价
- 保证金方法（60%）也很高
- 取最宽松的，所以止盈价可能非常远
- **导致盈利单无法达到止盈目标，无法平仓**
---
### 问题2：扫描间隔太长
**当前配置**：
- `SCAN_INTERVAL`: 3600秒（1小时）
**问题**：
- 扫描间隔1小时太长，可能错过交易机会
- 如果市场在扫描间隔内出现机会，需要等待1小时才能发现
**影响**：
- 交易数量减少
- 错过最佳入场时机
---
### 问题3：信号强度要求太高
**当前配置**：
- `MIN_SIGNAL_STRENGTH`: 7
**问题**：
- 信号强度要求7太高，可能过滤掉太多交易对
- 只有信号强度≥7的交易对才会被考虑
**影响**：
- 符合条件的交易对减少
- 交易数量减少
---
### 问题4：每日交易次数限制
**当前配置**：
- `MAX_DAILY_ENTRIES`: 5
**问题**：
- 每日最多5笔，限制了交易数量
- 如果已经达到5笔，当天不会再开新仓
**影响**：
- 交易数量减少
- 错过后续交易机会
---
## 📊 配置对比
### 当前配置（问题配置）
| 参数 | 当前值 | 问题 |
|------|--------|------|
| `TAKE_PROFIT_PERCENT` | 0.60 (60%) | ❌ **太高**，盈利单无法平仓 |
| `ATR_TAKE_PROFIT_MULTIPLIER` | 8.0 | ❌ **太高**，止盈价太远 |
| `RISK_REWARD_RATIO` | 4.0 | ⚠️ 合理，但配合60%太高 |
| `SCAN_INTERVAL` | 3600秒（1小时） | ❌ **太长**，错过机会 |
| `MIN_SIGNAL_STRENGTH` | 7 | ❌ **太高**，过滤太多 |
| `MAX_DAILY_ENTRIES` | 5 | ⚠️ 可能偏少 |
### 建议配置（优化后）
| 参数 | 建议值 | 说明 |
|------|--------|------|
| `TAKE_PROFIT_PERCENT` | 0.30 (30%) | ✅ 降低到30%，更容易触发 |
| `ATR_TAKE_PROFIT_MULTIPLIER` | 4.0 | ✅ 降低到4.0，配合RISK_REWARD_RATIO |
| `RISK_REWARD_RATIO` | 4.0 | ✅ 保持4.0，但配合30%止盈 |
| `SCAN_INTERVAL` | 1800秒（30分钟） | ✅ 缩短到30分钟，增加机会 |
| `MIN_SIGNAL_STRENGTH` | 5 | ✅ 降低到5，增加交易对 |
| `MAX_DAILY_ENTRIES` | 8 | ✅ 增加到8，增加交易数量 |
---
## 🚀 解决方案
### 方案1：降低止盈目标（立即执行）
**修改参数**：
- `TAKE_PROFIT_PERCENT`: 0.60 → **0.30** (30%)
- `ATR_TAKE_PROFIT_MULTIPLIER`: 8.0 → **4.0**
**理由**：
- 30%止盈目标更容易触发，盈利单可以及时平仓
- 4.0倍ATR配合4.0:1盈亏比，止盈距离 = 止损距离 × 4.0
- 仍然保持4:1盈亏比，但更容易达到
**效果**：
- 盈利单可以及时平仓
- 锁定利润，避免利润回吐
---
### 方案2：缩短扫描间隔
**修改参数**：
- `SCAN_INTERVAL`: 3600秒 → **1800秒** (30分钟)
**理由**：
- 30分钟扫描间隔，增加发现交易机会的频率
- 不会太频繁，避免过度交易
**效果**：
- 交易数量增加
- 不错过交易机会
---
### 方案3：降低信号强度要求
**修改参数**：
- `MIN_SIGNAL_STRENGTH`: 7 → **5**
**理由**：
- 信号强度5已经足够（MACD金叉/死叉 + 其他指标）
- 降低门槛，增加符合条件的交易对
**效果**：
- 符合条件的交易对增加
- 交易数量增加
---
### 方案4：增加每日交易次数
**修改参数**：
- `MAX_DAILY_ENTRIES`: 5 → **8**
**理由**：
- 增加每日交易次数，提高交易频率
- 仍然有上限，避免过度交易
**效果**：
- 交易数量增加
- 不错过后续交易机会
---
## 📈 预期效果
### 优化前
- 止盈目标：60%（很难达到）
- 扫描间隔：1小时（错过机会）
- 信号强度：7（过滤太多）
- 每日交易：5笔（限制交易）
### 优化后
- 止盈目标：30%（更容易达到）✅
- 扫描间隔：30分钟（增加机会）✅
- 信号强度：5（增加交易对）✅
- 每日交易：8笔（增加交易）✅
### 预期改善
1. **盈利单可以及时平仓**：30%止盈目标更容易触发
2. **交易数量增加**：扫描间隔缩短、信号强度降低、每日交易增加
3. **不错过交易机会**：更频繁的扫描和更低的门槛
---
## ✅ 立即行动
### 1. 降低止盈目标（最重要）
**修改文件**：
- `trading_system/config.py`
- `backend/config_manager.py`
- `frontend/src/components/GlobalConfig.jsx`
- `frontend/src/components/ConfigPanel.jsx`
**修改内容**：
- `TAKE_PROFIT_PERCENT`: 0.60 → **0.30**
- `ATR_TAKE_PROFIT_MULTIPLIER`: 8.0 → **4.0**
### 2. 缩短扫描间隔
**修改内容**：
- `SCAN_INTERVAL`: 3600 → **1800**
### 3. 降低信号强度要求
**修改内容**：
- `MIN_SIGNAL_STRENGTH`: 7 → **5**
### 4. 增加每日交易次数
**修改内容**：
- `MAX_DAILY_ENTRIES`: 5 → **8**
---
## 📝 备注
- 本分析基于当前配置和用户反馈
- 建议先降低止盈目标，这是最紧急的问题
- 其他优化可以逐步实施

282
docs/山寨币策略配置优化方案_2026-01-27.md Normal file
View File

@ -0,0 +1,282 @@
# 山寨币策略配置优化方案（2026-01-27）
## 📊 当前问题分析
### 统计数据
- **总交易数**：30
- **胜率**：36.36%（偏低）
- **总盈亏**：-8.29 USDT
- **平均盈亏**：-0.38 USDT
- **平均持仓时长**：270分钟（4.5小时）
- **平仓原因**：止损 7 / 止盈 2 / 移动止损 3 / 同步 10
- **平均盈利 / 平均亏损**：0.39 : 1（期望 3:1，严重失衡）
### 核心问题
1. **止盈单极少**（仅2单，6.67%）
- 止盈目标过高（30%），难以触发
- 导致盈利单无法及时止盈，最终回吐利润
2. **止损单亏损过大**
- SELL单止损价格计算错误（已修复）
- 止损可能过宽，导致亏损幅度大
3. **盈亏比严重失衡**（0.39:1 vs 期望3:1）
- 平均盈利远小于平均亏损
- 说明止盈过紧，止损过宽
---
## 🎯 山寨币策略特点
### 市场特征
- **高波动性**：价格波动大，容易出现大幅涨跌
- **流动性相对较低**：容易出现滑点
- **趋势性强**：一旦形成趋势，可能持续较长时间
- **风险高**：容易出现大幅亏损
### 策略要求
- **快速止盈**：及时锁定利润，避免回吐
- **合理止损**：不能太紧（容易被震荡止损），也不能太宽（亏损过大）
- **高盈亏比**：追求大赢家，但也要保证胜率
- **移动止损**：盈利后保护利润
---
## ✅ 优化方案
### 1. 止盈策略优化
#### 当前配置（问题）
- `TAKE_PROFIT_PERCENT`: 0.30（30%，过高）
- `ATR_TAKE_PROFIT_MULTIPLIER`: 4.0（过高）
- `RISK_REWARD_RATIO`: 4.0（过高）
#### 优化配置（建议）
- `TAKE_PROFIT_PERCENT`: **0.20**（20%，更容易触发）
- `ATR_TAKE_PROFIT_MULTIPLIER`: **3.0**（降低，更容易触发）
- `RISK_REWARD_RATIO`: **3.0**（降低，更容易触发）
**理由**：
- 20%的止盈目标对于山寨币来说更容易达到
- 降低盈亏比到3:1，既能追求大赢家，又能保证胜率
- 更容易触发止盈，提升止盈单比例
---
### 2. 止损策略优化
#### 当前配置
- `STOP_LOSS_PERCENT`: 0.15（15%）
- `ATR_STOP_LOSS_MULTIPLIER`: 2.0
- `MIN_STOP_LOSS_PRICE_PCT`: 0.02（2%）
#### 优化配置（建议）
- `STOP_LOSS_PERCENT`: **0.12**（12%，收紧止损）
- `ATR_STOP_LOSS_MULTIPLIER`: **2.0**（保持）
- `MIN_STOP_LOSS_PRICE_PCT`: **0.02**（2%，保持）
**理由**：
- 收紧止损到12%，减少单笔亏损
- 配合20%止盈，形成1.67:1的盈亏比（更现实）
- 对于山寨币的高波动性，12%的止损既能容忍波动，又能控制风险
---
### 3. 移动止损优化
#### 当前配置
- `USE_TRAILING_STOP`: false（未启用）
- `TRAILING_STOP_ACTIVATION`: 0.30（30%）
- `TRAILING_STOP_PROTECT`: 0.15（15%）
#### 优化配置（建议）
- `USE_TRAILING_STOP`: **true**（启用移动止损）
- `TRAILING_STOP_ACTIVATION`: **0.20**（20%，盈利20%后激活）
- `TRAILING_STOP_PROTECT`: **0.10**（10%，保护10%利润）
**理由**：
- 启用移动止损，保护利润
- 20%激活，与第一目标止盈一致
- 10%保护，给回撤足够空间
---
### 4. 分步止盈策略
#### 当前配置
- 第一目标：30%固定止盈（50%仓位）
- 第二目标：4.0:1盈亏比（剩余50%仓位）
#### 优化配置（建议）
- 第一目标：**20%固定止盈**（50%仓位）
- 第二目标：**3.0:1盈亏比**（剩余50%仓位）
**理由**：
- 降低第一目标到20%，更容易触发
- 降低第二目标到3.0:1，更容易触发
- 保证拿到20%盈利，然后追求更高利润
---
### 5. 仓位控制优化
#### 当前配置
- `MAX_POSITION_PERCENT`: 0.015（1.5%）
- `MAX_TOTAL_POSITION_PERCENT`: 0.12（12%）
- `FIXED_RISK_PERCENT`: 0.01（1%）
#### 优化配置（建议）
- `MAX_POSITION_PERCENT`: **0.015**（1.5%，保持）
- `MAX_TOTAL_POSITION_PERCENT`: **0.12**（12%，保持）
- `FIXED_RISK_PERCENT`: **0.01**（1%，保持）
**理由**：
- 仓位控制已经比较合理，保持现状
---
### 6. 市场扫描优化
#### 当前配置
- `MAX_SCAN_SYMBOLS`: 250
- `TOP_N_SYMBOLS`: 8
- `MIN_SIGNAL_STRENGTH`: 5
- `MIN_VOLATILITY`: 0.03（3%）
#### 优化配置（建议）
- `MAX_SCAN_SYMBOLS`: **250**（保持）
- `TOP_N_SYMBOLS`: **8**（保持）
- `MIN_SIGNAL_STRENGTH`: **5**（保持）
- `MIN_VOLATILITY`: **0.03**（3%，保持）
**理由**：
- 市场扫描参数已经比较合理，保持现状
---
## 📊 优化后的预期效果
### 止盈单比例
- **当前**：6.67%（2/30）
- **预期**：25%+（8+/30）
### 盈亏比
- **当前**：0.39:1
- **预期**：1.5:1 - 2.0:1
### 胜率
- **当前**：36.36%
- **预期**：40% - 50%
### 平均盈利/平均亏损
- **当前**：0.39:1
- **预期**：1.5:1 - 2.0:1
---
## 🔧 配置调整清单
### 必须调整（紧急）
1. **止盈目标**
- `TAKE_PROFIT_PERCENT`: 0.30 → **0.20**
- `ATR_TAKE_PROFIT_MULTIPLIER`: 4.0 → **3.0**
- `RISK_REWARD_RATIO`: 4.0 → **3.0**
2. **止损收紧**
- `STOP_LOSS_PERCENT`: 0.15 → **0.12**
3. **移动止损**
- `USE_TRAILING_STOP`: false → **true**
- `TRAILING_STOP_ACTIVATION`: 0.30 → **0.20**
- `TRAILING_STOP_PROTECT`: 0.15 → **0.10**
### 保持现状
- `MAX_POSITION_PERCENT`: 0.015
- `MAX_TOTAL_POSITION_PERCENT`: 0.12
- `FIXED_RISK_PERCENT`: 0.01
- `ATR_STOP_LOSS_MULTIPLIER`: 2.0
- `MIN_STOP_LOSS_PRICE_PCT`: 0.02
- `MIN_VOLATILITY`: 0.03
- `MIN_SIGNAL_STRENGTH`: 5
---
## 📝 实施步骤
### 步骤1：更新全局配置
在全局配置页面更新以下配置项：
- `TAKE_PROFIT_PERCENT`: 0.20
- `ATR_TAKE_PROFIT_MULTIPLIER`: 3.0
- `RISK_REWARD_RATIO`: 3.0
- `STOP_LOSS_PERCENT`: 0.12
- `USE_TRAILING_STOP`: true
- `TRAILING_STOP_ACTIVATION`: 0.20
- `TRAILING_STOP_PROTECT`: 0.10
### 步骤2：清除Redis缓存
```bash
redis-cli DEL "global_strategy_config"
redis-cli DEL "config:trading_config:*"
```
### 步骤3：重启交易进程
```bash
supervisorctl restart auto_sys_acc1 auto_sys_acc2 auto_sys_acc3 auto_sys_acc4
```
### 步骤4：监控效果
- 监控止盈单比例（预期提升到25%+）
- 监控盈亏比（预期提升到1.5:1+）
- 监控胜率（预期提升到40%+）
---
## ⚠️ 注意事项
1. **逐步调整**：不要一次性调整所有参数，可以先调整止盈目标，观察效果
2. **监控数据**：调整后密切监控交易数据，确认效果
3. **及时调整**：如果效果不理想，可以进一步微调参数
4. **保持一致性**：确保所有账号使用相同的配置
---
## 🎯 长期优化方向
1. **动态调整**：根据市场情况动态调整止盈止损参数
2. **信号强度**：根据信号强度调整仓位和止盈目标
3. **市场状态**：根据市场状态（趋势/震荡）调整策略参数
4. **回测验证**：定期回测验证策略参数的有效性
---
## 📊 配置对比表
| 配置项 | 当前值 | 优化值 | 变化 | 理由 |
|--------|--------|--------|------|------|
| `TAKE_PROFIT_PERCENT` | 0.30 | **0.20** | ↓ | 更容易触发，提升止盈单比例 |
| `ATR_TAKE_PROFIT_MULTIPLIER` | 4.0 | **3.0** | ↓ | 降低止盈目标，更容易触发 |
| `RISK_REWARD_RATIO` | 4.0 | **3.0** | ↓ | 降低盈亏比，更容易触发 |
| `STOP_LOSS_PERCENT` | 0.15 | **0.12** | ↓ | 收紧止损，减少单笔亏损 |
| `USE_TRAILING_STOP` | false | **true** | ↑ | 启用移动止损，保护利润 |
| `TRAILING_STOP_ACTIVATION` | 0.30 | **0.20** | ↓ | 与第一目标止盈一致 |
| `TRAILING_STOP_PROTECT` | 0.15 | **0.10** | ↓ | 给回撤足够空间 |
---
## ✅ 总结
通过以上优化，预期能够：
- ✅ 提升止盈单比例（从6.67%提升到25%+）
- ✅ 改善盈亏比（从0.39:1提升到1.5:1+）
- ✅ 提升胜率（从36.36%提升到40%+）
- ✅ 减少单笔亏损（收紧止损到12%）
- ✅ 保护利润（启用移动止损）
这些调整基于山寨币策略的特点，旨在让收益率真实，胜率正常化。

276
docs/推荐系统日志和运行状态检查.md Normal file
View File

@ -0,0 +1,276 @@
# 推荐系统日志和运行状态检查
## 问题描述
1. **感觉没有推荐了**：推荐系统可能没有正常运行
2. **recommendations_bot.log 是不是没用了**：需要确认日志文件位置
3. **推荐系统输出的日志在哪**：需要确认日志路径
4. **recommendations-viewer 需要调整吗**：需要检查前端是否需要调整
---
## 推荐系统日志配置
### 1. 日志文件位置
**代码位置**：`trading_system/recommendations_main.py`
**日志文件**：
- 默认：`recommendations_bot.log`（项目根目录）
- 可通过环境变量 `RECOMMEND_LOG_FILE` 覆盖
**日志输出**：
1. **文件日志**：`recommendations_bot.log`（项目根目录）
2. **控制台输出**：stdout（如果通过supervisor运行，会被supervisor捕获）
3. **Redis日志**：写入Redis（用于前端日志监控，service="recommendations"）
### 2. Supervisor配置
**当前情况**：
- `supervisor_account.py` 只处理交易账户的配置（`auto_sys_acc1`, `auto_sys_acc2`等）
- **推荐服务没有自动生成supervisor配置**
**推荐服务可能的运行方式**：
1. **手动运行**：`python -m trading_system.recommendations_main`
2. **Supervisor手动配置**：需要手动创建supervisor配置文件
3. **未运行**：推荐服务可能没有启动
---
## 检查推荐系统运行状态
### 1. 检查进程
```bash
# 检查推荐服务进程
ps aux | grep recommendations_main
# 检查supervisor管理的推荐服务
supervisorctl status | grep recommend
```
### 2. 检查日志文件
```bash
# 检查项目根目录的日志文件
ls -lh /www/wwwroot/autosys_new/recommendations_bot.log
# 查看日志内容
tail -f /www/wwwroot/autosys_new/recommendations_bot.log
# 检查supervisor日志（如果通过supervisor运行）
# 需要找到推荐服务的supervisor配置，查看stdout_logfile和stderr_logfile
```
### 3. 检查Redis中的推荐数据
```bash
# 检查Redis中的推荐数据
redis-cli
> KEYS recommendations:*
> GET recommendations:snapshot
> HGETALL recommendations:realtime
```
### 4. 检查API接口
```bash
# 检查推荐API是否返回数据
curl http://asapi.deepx1.com/api/recommendations?type=realtime
```
---
## 推荐系统配置
### 1. 环境变量
推荐系统支持以下环境变量：
- `RECOMMEND_SCAN_INTERVAL_SEC`：扫描间隔（默认60秒）
- `RECOMMEND_MIN_SIGNAL_STRENGTH`：最小信号强度（默认5）
- `RECOMMEND_MAX_RECOMMENDATIONS`：最大推荐数量（默认60）
- `RECOMMEND_MIN_QUALITY_SCORE`：最小质量分数（默认0.0）
- `RECOMMEND_SCAN_CACHE_NAMESPACE`：缓存命名空间（默认"recommend"）
- `RECOMMEND_LOG_FILE`：日志文件路径（默认"recommendations_bot.log"）
### 2. Supervisor配置（如果需要）
如果需要通过supervisor管理推荐服务，需要手动创建配置文件：
```ini
[program:auto_recommend]
directory=/www/wwwroot/autosys_new
command=/www/wwwroot/autosys_new/trading_system/.venv/bin/python -m trading_system.recommendations_main
autostart=true
autorestart=unexpected
exitcodes=0,2
startsecs=0
stopasgroup=true
killasgroup=true
stopsignal=TERM
environment=PYTHONUNBUFFERED="1",PYTHONPATH="/www/wwwroot/autosys_new"
stdout_logfile=/www/wwwroot/autosys_new/logs/recommendations.out.log
stderr_logfile=/www/wwwroot/autosys_new/logs/recommendations.err.log
stdout_logfile_maxbytes=20MB
stdout_logfile_backups=5
stderr_logfile_maxbytes=20MB
stderr_logfile_backups=5
```
---
## recommendations-viewer 检查
### 1. API接口
**文件**：`recommendations-viewer/src/services/api.js`
**接口**：`/api/recommendations?type=realtime`
**检查**：
- API接口是否正确
- 是否返回数据
- 前端是否能正常显示
### 2. 是否需要调整
**当前实现**：
- 每10秒静默更新价格
- 使用实时推荐（type=realtime）
- 从Redis读取推荐数据
**如果推荐系统没有运行**：
- 前端会显示"没有推荐"或"加载失败"
- 需要确保推荐服务正常运行
---
## 解决方案
### 方案1：检查推荐服务是否运行
```bash
# 1. 检查进程
ps aux | grep recommendations_main
# 2. 如果没有运行，手动启动
cd /www/wwwroot/autosys_new
source trading_system/.venv/bin/activate
python -m trading_system.recommendations_main
# 3. 或者通过supervisor启动（如果已配置）
supervisorctl start auto_recommend
```
### 方案2：检查日志文件
```bash
# 1. 检查日志文件是否存在
ls -lh /www/wwwroot/autosys_new/recommendations_bot.log
# 2. 查看日志内容
tail -f /www/wwwroot/autosys_new/recommendations_bot.log
# 3. 如果日志文件不存在，可能是：
# - 推荐服务没有运行
# - 日志文件路径配置错误
# - 权限问题
```
### 方案3：检查Redis数据
```bash
# 1. 连接Redis
redis-cli
# 2. 检查推荐数据
KEYS recommendations:*
GET recommendations:snapshot
HGETALL recommendations:realtime
# 3. 如果没有数据，说明推荐服务没有生成推荐
```
### 方案4：检查API接口
```bash
# 1. 检查API是否返回数据
curl http://asapi.deepx1.com/api/recommendations?type=realtime
# 2. 如果返回空数组，说明：
# - 推荐服务没有运行
# - 推荐服务运行但没有生成推荐
# - Redis中没有推荐数据
```
---
## 推荐系统日志位置总结
### 1. 文件日志
- **位置**：`/www/wwwroot/autosys_new/recommendations_bot.log`
- **说明**：如果推荐服务运行，日志会写入这个文件
### 2. Supervisor日志（如果通过supervisor运行）
- **位置**：根据supervisor配置的 `stdout_logfile` 和 `stderr_logfile`
- **说明**：如果推荐服务通过supervisor运行，日志会写入supervisor配置的日志文件
### 3. Redis日志
- **位置**：Redis（service="recommendations"）
- **说明**：用于前端日志监控
---
## 下一步操作
1. **检查推荐服务是否运行**：
```bash
ps aux | grep recommendations_main
```
2. **检查日志文件**：
```bash
tail -f /www/wwwroot/autosys_new/recommendations_bot.log
```
3. **检查Redis数据**：
```bash
redis-cli
> KEYS recommendations:*
```
4. **检查API接口**：
```bash
curl http://asapi.deepx1.com/api/recommendations?type=realtime
```
5. **如果推荐服务没有运行，启动它**：
```bash
# 手动启动
python -m trading_system.recommendations_main
# 或通过supervisor启动（如果已配置）
supervisorctl start auto_recommend
```
---
## recommendations-viewer 是否需要调整
**当前情况**：
- 前端代码看起来正常
- 如果推荐系统正常运行，前端应该能正常显示推荐
**如果需要调整**：
- 检查API接口是否正确
- 检查前端是否能正常获取数据
- 检查前端显示逻辑是否正确
**建议**：
- 先确保推荐服务正常运行
- 然后检查前端是否能正常显示推荐
- 如果前端有问题，再进行调整

277
docs/推荐系统超时问题和交易数据分析_2026-01-26.md Normal file
View File

@ -0,0 +1,277 @@
# 推荐系统超时问题和交易数据分析 - 2026-01-26
## 问题1：推荐系统TimeoutError
### 错误信息
```
2026-01-25 17:19:07 - recommendations - ERROR - 推荐生成循环异常: TimeoutError
Traceback (most recent call last):
File "/www/wwwroot/autosys/trading_system/recommendations_main.py", line 145, in main
recos = await recommender.generate_recommendations(...)
File "/www/wwwroot/autosys/trading_system/trade_recommender.py", line 118, in generate_recommendations
top_symbols = await self.scanner.scan_market(...)
File "/www/wwwroot/autosys/trading_system/market_scanner.py", line 60, in scan_market
all_symbols = await self.client.get_all_usdt_pairs()
File "/www/wwwroot/autosys/trading_system/binance_client.py", line 333, in get_all_usdt_pairs
exchange_info = await self.client.futures_exchange_info()
...
File "/www/wwwroot/autosys_new/trading_system/.venv/lib/python3.12/site-packages/aiohttp/helpers.py", line 735, in __exit__
raise asyncio.TimeoutError from None
TimeoutError
```
### 问题分析
**根本原因**：
- `get_all_usdt_pairs()` 方法直接调用 `self.client.futures_exchange_info()`
- **没有使用 `_rate_limited_request`**，缺少重试机制
- **没有超时处理**，网络请求超时直接抛出异常
- **没有异常捕获**，导致推荐服务循环中断
**影响**：
- 推荐服务在遇到网络超时时会中断
- 虽然外层有 `try-except`，但异常被记录后继续循环，可能导致推荐生成失败
### 解决方案 ✅ 已实施
**修改文件**：`trading_system/binance_client.py`
**修改内容**：
1. ✅ 使用 `_rate_limited_request` 包装请求，添加速率限制
2. ✅ 使用 `asyncio.wait_for` 添加超时处理（默认30秒）
3. ✅ 添加重试机制（默认3次，递增等待时间）
4. ✅ 添加异常捕获，返回空列表而不是抛出异常
5. ✅ 添加详细日志，记录重试过程
**修改后的方法签名**：
```python
async def get_all_usdt_pairs(self, max_retries: int = 3, timeout: int = 30) -> List[str]:
```
**重试策略**：
- 最大重试次数：3次
- 超时时间：30秒/次
- 等待时间：递增（2秒、4秒、6秒）
- 失败时返回空列表，不会中断推荐服务循环
---
## 问题2：交易数据异常分析
### 统计数据
| 指标 | 数值 | 评价 |
|------|------|------|
| **总交易数** | 5 | ❌ **过少** |
| **胜率** | 0% | ❌ **全部亏损** |
| **总盈亏** | -4.42 USDT | ❌ **亏损** |
| **平均盈亏** | -2.21 USDT/笔 | ❌ **严重亏损** |
| **平均持仓时长** | 306分钟（5小时） | ⚠️ **较长** |
| **平仓原因** | 止损 2 / 持仓中 3 | ⚠️ **无止盈** |
| **平均盈利/平均亏损** | 0.00:1 | ❌ **无盈利** |
| **总交易量** | 132.97 USDT | ⚠️ **较少** |
### 交易详情
#### 已平仓交易（2笔）
1. **#1653 JTOUSDT SELL: -85.93%**
- 入场价：0.3063
- 出场价：0.3392
- 价格涨幅：**10.7%**（做空方向，价格上涨导致亏损）
- 盈亏比例：**-85.93%**（相对于保证金）
- 杠杆：8x
- 持仓时长：约3.6小时
- 平仓类型：自动平仓（止损）
- **问题**：止损没有及时执行，导致极端亏损
2. **#1648 TIAUSDT SELL: -45.55%**
- 入场价：0.418
- 出场价：0.4418
- 价格涨幅：**5.7%**（做空方向，价格上涨导致亏损）
- 盈亏比例：**-45.55%**（相对于保证金）
- 杠杆：8x
- 持仓时长：约6.8小时
- 平仓类型：自动平仓（止损）
- **问题**：止损没有及时执行，导致大额亏损
#### 持仓中交易（3笔）
1. **#1655 DASHUSDT SELL** - 持仓中
2. **#1651 AUCTIONUSDT BUY** - 持仓中
3. **#1644 SANDUSDT SELL** - 持仓中
---
## 🔍 问题分析
### 问题1：交易数量过少（5笔）
**可能原因**：
1. **扫描间隔太长**：`SCAN_INTERVAL = 3600秒`（1小时），可能错过机会
2. **信号筛选太严格**：`MIN_SIGNAL_STRENGTH = 5`，可能过滤掉太多交易对
3. **市场条件不佳**：可能市场波动较小，没有符合条件的交易对
4. **配置问题**：可能某些配置项限制了交易数量
**建议**：
- ✅ 检查扫描间隔是否合理
- ✅ 检查信号筛选条件是否太严格
- ✅ 检查市场扫描日志，确认是否找到交易对
### 问题2：胜率0%，全部亏损
**可能原因**：
1. **止损失效**：2笔已平仓交易都是极端亏损（-85.93%, -45.55%），说明止损没有及时执行
2. **做空方向问题**：2笔亏损都是做空（SELL），可能市场整体上涨
3. **入场时机不佳**：可能入场时机选择不当
**建议**：
- ✅ **立即修复止损失效问题**
- ✅ 检查做空方向的止损逻辑
- ✅ 检查入场信号质量
### 问题3：极端亏损（-85.93%, -45.55%）
**问题分析**：
1. **JTOUSDT #1653**：
- 价格涨幅10.7%，但盈亏比例-85.93%
- 说明止损距离过宽或止损没有及时执行
- 持仓时长3.6小时，止损应该在更早触发
2. **TIAUSDT #1648**：
- 价格涨幅5.7%，但盈亏比例-45.55%
- 说明止损距离过宽或止损没有及时执行
- 持仓时长6.8小时，止损应该在更早触发
**可能原因**：
1. **止损单没有正确挂到交易所**
2. **止损价格计算错误**（特别是做空方向）
3. **WebSocket监控断线**，没有及时触发止损
4. **价格跳空**，导致止损失效
**建议**：
- ✅ **立即修复止损失效问题**
- ✅ 检查做空方向的止损价格计算
- ✅ 检查WebSocket监控是否正常
- ✅ 添加止损失效告警
### 问题4：平均持仓时长较长（306分钟）
**问题分析**：
- 平均持仓306分钟（5小时），说明持仓时间较长
- 2笔已平仓交易持仓时长分别为3.6小时和6.8小时
- 3笔持仓中交易可能持仓更长时间
**可能原因**：
1. **止盈目标设置太高**：可能止盈目标难以达到
2. **止损没有及时触发**：导致持仓时间过长
3. **市场波动较小**：价格没有达到止盈或止损目标
**建议**：
- ✅ 检查止盈目标是否设置太高
- ✅ 检查止损是否及时触发
- ✅ 检查市场波动情况
---
## 🚀 解决方案
### 1. 修复推荐系统TimeoutError
**修改文件**：`trading_system/binance_client.py`
**修改内容**：
- 使用 `_rate_limited_request` 包装 `futures_exchange_info()` 请求
- 添加超时处理和重试机制
- 添加异常捕获，返回空列表而不是抛出异常
### 2. 修复止损失效问题
**立即执行**：
1. ✅ 检查止损单是否正确挂到交易所
2. ✅ 检查止损价格计算是否正确（特别是做空方向）
3. ✅ 检查WebSocket监控是否正常
4. ✅ 添加止损失效告警
### 3. 优化交易数量
**检查项**：
1. ✅ 检查扫描间隔是否合理
2. ✅ 检查信号筛选条件是否太严格
3. ✅ 检查市场扫描日志，确认是否找到交易对
### 4. 优化持仓时长
**检查项**：
1. ✅ 检查止盈目标是否设置太高
2. ✅ 检查止损是否及时触发
3. ✅ 检查市场波动情况
---
## 📊 与正常情况对比
### 正常情况（参考2026-01-25）
| 指标 | 正常值 | 当前值 | 评价 |
|------|--------|--------|------|
| **总交易数** | 81 | 5 | ❌ **过少** |
| **胜率** | 42.67% | 0% | ❌ **严重异常** |
| **总盈亏** | +7.37 USDT | -4.42 USDT | ❌ **亏损** |
| **平均持仓时长** | 80分钟 | 306分钟 | ⚠️ **较长** |
| **极端亏损** | 8笔>50% | 2笔>45% | ⚠️ **仍有问题** |
### 异常情况分析
1. **交易数量过少**：5笔 vs 正常81笔，说明可能：
- 扫描间隔太长
- 信号筛选太严格
- 市场条件不佳
- 配置问题
2. **胜率0%**：全部亏损，说明：
- 止损失效导致极端亏损
- 入场时机可能不佳
- 做空方向可能有问题
3. **极端亏损**：2笔极端亏损（-85.93%, -45.55%），说明：
- 止损没有及时执行
- 需要立即修复止损失效问题
---
## ✅ 总结
### 推荐系统问题
1. ❌ **TimeoutError**：`get_all_usdt_pairs()` 缺少超时处理和重试机制
2. ✅ **解决方案**：使用 `_rate_limited_request` 包装请求，添加超时处理和重试机制
### 交易数据问题
1. ❌ **交易数量过少**：5笔 vs 正常81笔
2. ❌ **胜率0%**：全部亏损
3. ❌ **极端亏损**：2笔极端亏损（-85.93%, -45.55%）
4. ⚠️ **持仓时长较长**：306分钟（5小时）
### 关键问题
1. **止损失效**：2笔极端亏损说明止损没有及时执行
2. **交易数量过少**：可能扫描间隔太长或信号筛选太严格
3. **做空方向问题**：2笔亏损都是做空，可能止损逻辑有问题
### 立即行动
1. ✅ **修复推荐系统TimeoutError**
2. ✅ **修复止损失效问题**
3. ✅ **检查交易数量过少的原因**
4. ✅ **检查做空方向的止损逻辑**
---
## 📝 备注
- 本报告基于2026-01-26的交易数据
- 数据来源：`trading_system/交易记录_2026-01-26T06-17-06.json`
- 分析时间：2026-01-26

175
docs/数据迁移执行指南.md Normal file
View File

@ -0,0 +1,175 @@
# 数据迁移执行指南
## ⚠️ 重要提示
日志中显示格式转换警告，说明数据库中还有旧数据（百分比形式，如30表示30%）。需要执行数据迁移脚本，将数据统一转换为比例形式（0.30表示30%）。
---
## 🔧 执行步骤
### 步骤1：备份数据库（强烈推荐）
```bash
# 备份数据库
mysqldump -u username -p database_name > backup_$(date +%Y%m%d_%H%M%S).sql
```
---
### 步骤2：执行数据迁移脚本
```bash
# 执行SQL迁移脚本
mysql -u username -p database_name < backend/database/migrate_percent_configs_to_ratio.sql
```
**或者直接在MySQL客户端执行**：
```sql
-- 1. 备份表
CREATE TABLE IF NOT EXISTS trading_config_backup_20260126 AS
SELECT * FROM trading_config;
CREATE TABLE IF NOT EXISTS global_strategy_config_backup_20260126 AS
SELECT * FROM global_strategy_config;
-- 2. 迁移 trading_config 表
UPDATE trading_config
SET config_value = CAST(config_value AS DECIMAL(10, 4)) / 100.0
WHERE config_key IN (
'TRAILING_STOP_ACTIVATION',
'TRAILING_STOP_PROTECT',
'MIN_VOLATILITY',
'TAKE_PROFIT_PERCENT',
'STOP_LOSS_PERCENT',
'MIN_STOP_LOSS_PRICE_PCT',
'MIN_TAKE_PROFIT_PRICE_PCT',
'FIXED_RISK_PERCENT',
'MAX_POSITION_PERCENT',
'MAX_TOTAL_POSITION_PERCENT',
'MIN_POSITION_PERCENT'
)
AND config_type = 'number'
AND CAST(config_value AS DECIMAL(10, 4)) > 1;
-- 3. 迁移 global_strategy_config 表
UPDATE global_strategy_config
SET config_value = CAST(config_value AS DECIMAL(10, 4)) / 100.0
WHERE config_key IN (
'TRAILING_STOP_ACTIVATION',
'TRAILING_STOP_PROTECT',
'MIN_VOLATILITY',
'TAKE_PROFIT_PERCENT',
'STOP_LOSS_PERCENT',
'MIN_STOP_LOSS_PRICE_PCT',
'MIN_TAKE_PROFIT_PRICE_PCT',
'FIXED_RISK_PERCENT',
'MAX_POSITION_PERCENT',
'MAX_TOTAL_POSITION_PERCENT',
'MIN_POSITION_PERCENT'
)
AND config_type = 'number'
AND CAST(config_value AS DECIMAL(10, 4)) > 1;
```
---
### 步骤3：验证迁移结果
```sql
-- 检查是否还有>1的百分比配置项（应该返回0行）
SELECT 'trading_config' as table_name, config_key, config_value, account_id
FROM trading_config
WHERE config_key IN (
'TRAILING_STOP_ACTIVATION',
'TRAILING_STOP_PROTECT',
'MIN_VOLATILITY',
'TAKE_PROFIT_PERCENT',
'STOP_LOSS_PERCENT'
)
AND config_type = 'number'
AND CAST(config_value AS DECIMAL(10, 4)) > 1
UNION ALL
SELECT 'global_strategy_config' as table_name, config_key, config_value, NULL as account_id
FROM global_strategy_config
WHERE config_key IN (
'TRAILING_STOP_ACTIVATION',
'TRAILING_STOP_PROTECT',
'MIN_VOLATILITY',
'TAKE_PROFIT_PERCENT',
'STOP_LOSS_PERCENT'
)
AND config_type = 'number'
AND CAST(config_value AS DECIMAL(10, 4)) > 1;
```
**预期结果**：应该返回0行（没有>1的值）
---
### 步骤4：清除Redis缓存
```bash
# 清除Redis缓存，让系统重新加载配置
redis-cli DEL "config:trading_config:*"
redis-cli DEL "config:global_strategy_config:*"
```
---
### 步骤5：重启服务
```bash
# 重启后端服务
supervisorctl restart backend
# 重启交易进程
supervisorctl restart auto_sys_acc1 auto_sys_acc2 auto_sys_acc3 auto_sys_acc4
```
---
## ✅ 验证
### 检查日志
迁移完成后，日志中不应该再出现格式转换警告：
```bash
# 查看日志，确认没有格式转换警告
tail -f /www/wwwroot/autosys_new/logs/trading_*.log | grep "配置值格式转换"
```
**预期结果**：不应该再看到格式转换警告
---
### 检查配置值
**迁移前**：
- `TRAILING_STOP_ACTIVATION`: 30（百分比形式）
- `TRAILING_STOP_PROTECT`: 15（百分比形式）
- `MIN_VOLATILITY`: 3（百分比形式）
**迁移后**：
- `TRAILING_STOP_ACTIVATION`: 0.30（比例形式）
- `TRAILING_STOP_PROTECT`: 0.15（比例形式）
- `MIN_VOLATILITY`: 0.03（比例形式）
---
## 📝 注意事项
1. **备份数据库**：执行迁移前一定要备份数据库
2. **验证结果**：迁移后验证是否还有>1的值
3. **清除缓存**：迁移后清除Redis缓存
4. **重启服务**：迁移后重启服务，让新配置生效
---
## 🎯 迁移后的效果
- ✅ 数据库中统一存储比例形式（0.30）
- ✅ 前端直接显示小数（0.30），不带%符号
- ✅ 后端直接使用（0.30），不需要转换
- ✅ 日志中不再出现格式转换警告

203
docs/止损失效问题修复_2026-01-26.md Normal file
View File

@ -0,0 +1,203 @@
# 止损失效问题修复（2026-01-26）
## 🚨 问题总结
今天几笔单子都亏损了**100%以上**才止损，这是非常严重的问题！
### 问题交易记录
| 交易ID | 交易对 | 方向 | 入场价 | 出场价 | 亏损比例 | 问题 |
|--------|--------|------|--------|--------|----------|------|
| 1658 | AXSUSDT | SELL | 2.033 | 2.305 | **-107.03%** | ❌ 超过100%！ |
| 1652 | JTOUSDT | SELL | 0.3072 | 0.3397 | **-84.64%** | ❌ 远超15%止损 |
| 1645 | TIAUSDT | SELL | 0.418 | 0.4418 | **-45.55%** | ❌ 远超15%止损 |
### 问题分析
**止损应该是什么**：
- 止损百分比：15%（基于保证金）
- 杠杆：8倍
- 价格变动触发止损：15% / 8 = **1.875%**
**实际发生了什么**：
- 交易ID 1658：价格涨了13.38%，亏损107%
- 交易ID 1652：价格涨了10.58%，亏损84.64%
- **止损完全没有生效！**
---
## 🔧 修复方案
### 修复1：止损单挂单失败后立即检查并平仓 ✅ 已修复
**问题**：
- 止损单挂单失败后，系统依赖WebSocket监控
- 但如果当前价格已经触发止损，应该立即平仓，而不是等待WebSocket监控
**修复**：
- 在`trading_system/position_manager.py`的`_ensure_exchange_sltp_orders()`方法中
- 止损单挂单失败后，立即检查当前价格是否已触发止损
- 如果已触发，立即执行市价平仓
**代码位置**：`trading_system/position_manager.py:1270-1305`
**修复逻辑**：
```python
if sl_order:
# 止损单挂单成功
logger.info(f"{symbol} ✓ 止损单已成功挂到交易所")
else:
# 止损单挂单失败
logger.error(f"{symbol} ❌ 止损单挂单失败！")
# ⚠️ 关键修复：立即检查当前价格是否已触发止损
if current_price and stop_loss:
if side == "BUY" and current_price_val <= stop_loss_val:
# 做多：当前价 <= 止损价，立即平仓
await self.close_position(symbol, reason='stop_loss')
elif side == "SELL" and current_price_val >= stop_loss_val:
# 做空：当前价 >= 止损价，立即平仓
await self.close_position(symbol, reason='stop_loss')
```
---
## 📊 止损价格验证
### SELL方向止损价计算验证
**交易ID 1658 (AXSUSDT SELL)**：
- 入场价：2.033
- 保证金：2.54125 USDT
- 杠杆：8倍
- 止损百分比：15%
**计算**：
1. 止损金额 = `2.54125 × 0.15 = 0.3811875 USDT`
2. 数量：10
3. 止损距离 = `0.3811875 / 10 = 0.03811875 USDT`
4. 止损价 = `2.033 + 0.03811875 = 2.07111875` ✅
**但实际价格涨到了2.305才平仓！**
**问题**：
- 止损价应该是2.071，但价格涨到了2.305
- 说明止损单根本没有生效，或者止损价计算错误
---
## 🔍 可能的原因
### 原因1：止损单挂单失败 ❌ 最可能
**症状**：
- 日志显示"止损单挂单失败！将依赖WebSocket监控"
- 止损单被币安拒绝（错误码-2021: Order would immediately trigger）
**问题**：
- 如果止损单挂单失败，系统依赖WebSocket监控
- 但WebSocket监控可能：
1. 没有及时触发
2. 监控间隔太长
3. 网络延迟导致价格已经大幅偏离
**修复**：✅ 已修复
- 止损单挂单失败后，立即检查当前价格是否已触发止损
- 如果已触发，立即执行市价平仓
### 原因2：止损价格计算错误 ❌ 可能
**问题**：
- 止损价格计算错误，导致止损价设置得太远
- 特别是SELL方向的止损价计算
**验证**：
- 止损价计算逻辑看起来是正确的
- 但需要检查实际计算出的止损价是否合理
### 原因3：WebSocket监控延迟 ❌ 可能
**问题**：
- WebSocket监控是实时的，每次收到价格更新就会立即检查
- 但如果止损单挂单失败，可能价格已经大幅偏离
**修复**：✅ 已修复
- 止损单挂单失败后，立即检查当前价格是否已触发止损
---
## 🎯 修复效果
### 修复前
**问题**：
- 止损单挂单失败后，系统依赖WebSocket监控
- 如果价格已经触发止损，需要等待WebSocket监控才能平仓
- 导致价格已经大幅偏离止损价，才触发平仓
**结果**：
- 交易ID 1658：价格涨了13.38%，亏损107%
- 交易ID 1652：价格涨了10.58%，亏损84.64%
### 修复后
**改进**：
- 止损单挂单失败后，立即检查当前价格是否已触发止损
- 如果已触发，立即执行市价平仓
- 避免价格大幅偏离止损价
**预期效果**：
- 止损单挂单失败后，如果价格已触发止损，立即平仓
- 避免亏损扩大
- 止损更及时
---
## 📝 后续建议
### 1. 检查日志
**建议**：
- 查看这些交易的开仓日志，确认止损单是否成功挂单
- 如果止损单挂单失败，查看失败原因（错误码、错误信息）
**命令**：
```bash
# 查看止损单挂单失败的日志
grep "止损单挂单失败" /www/wwwroot/autosys_new/logs/trading_*.log
# 查看止损单挂单失败后的处理日志
grep "止损单挂单失败，但当前价格已触发止损" /www/wwwroot/autosys_new/logs/trading_*.log
```
### 2. 验证止损价格
**建议**：
- 检查止损价格计算是否正确
- 特别是SELL方向的止损价计算
**验证方法**：
- 查看开仓日志中的止损价格
- 对比计算出的止损价格和实际止损价格
### 3. 增强监控
**建议**：
- 如果止损单挂单失败，增加WebSocket监控频率
- 缩短监控间隔，确保及时触发止损
---
## ✅ 修复完成
**修复文件**：
- `trading_system/position_manager.py`
**修复内容**：
- 止损单挂单失败后，立即检查当前价格是否已触发止损
- 如果已触发，立即执行市价平仓
**下一步**：
1. 重启交易进程，让修复生效
2. 观察后续交易，确认止损是否及时触发
3. 如果仍有问题，检查日志并进一步排查

295
docs/止损失效问题分析_2026-01-26.md Normal file
View File

@ -0,0 +1,295 @@
# 止损失效问题分析（2026-01-26）
## 🚨 问题描述
今天几笔单子都亏损了**100%以上**才止损，这是非常严重的问题！
### 问题交易记录
| 交易ID | 交易对 | 方向 | 入场价 | 出场价 | 亏损比例 | 问题 |
|--------|--------|------|--------|--------|----------|------|
| 1658 | AXSUSDT | SELL | 2.033 | 2.305 | **-107.03%** | ❌ 超过100%！ |
| 1652 | JTOUSDT | SELL | 0.3072 | 0.3397 | **-84.64%** | ❌ 远超15%止损 |
| 1645 | TIAUSDT | SELL | 0.418 | 0.4418 | **-45.55%** | ❌ 远超15%止损 |
| 1643 | SANDUSDT | SELL | 0.13212 | 0.13484 | **-16.47%** | ⚠️ 略超15%止损 |
---
## 🔍 问题分析
### 1. 止损应该是什么？
**当前配置**：
- `STOP_LOSS_PERCENT`: 15%（基于保证金）
- `LEVERAGE`: 8倍
- `ATR_STOP_LOSS_MULTIPLIER`: 2.0
**止损触发条件**（基于保证金15%）：
- 价格变动 = 15% / 8 = **1.875%**
- 做多（BUY）：价格下跌1.875%触发止损
- 做空（SELL）：价格上涨1.875%触发止损
### 2. 实际发生了什么？
**交易ID 1658 (AXSUSDT SELL)**：
- 入场价：2.033
- 出场价：2.305
- 价格涨幅：`(2.305 - 2.033) / 2.033 = 13.38%`
- 8倍杠杆下亏损：`13.38% × 8 = 107.04%` ✅ 符合计算
**止损价应该是**：
- 做空止损价 = `2.033 × (1 + 0.01875) = 2.071`
- 但实际价格涨到了**2.305**才平仓！
- **价格已经涨了13.38%，止损完全没有生效！**
**交易ID 1652 (JTOUSDT SELL)**：
- 入场价：0.3072
- 出场价：0.3397
- 价格涨幅：`(0.3397 - 0.3072) / 0.3072 = 10.58%`
- 8倍杠杆下亏损：`10.58% × 8 = 84.64%` ✅ 符合计算
**止损价应该是**：
- 做空止损价 = `0.3072 × (1 + 0.01875) = 0.31296`
- 但实际价格涨到了**0.3397**才平仓！
- **价格已经涨了10.58%，止损完全没有生效！**
---
## 🔎 可能的原因
### 原因1：止损单挂单失败 ❌ 最可能
**症状**：
- 日志显示"止损单挂单失败！将依赖WebSocket监控"
- 止损单被币安拒绝（错误码-2021: Order would immediately trigger）
**问题**：
- 如果止损单挂单失败，系统依赖WebSocket监控
- 但WebSocket监控可能：
1. 没有及时触发
2. 监控间隔太长
3. 网络延迟导致价格已经大幅偏离
**代码位置**：
- `trading_system/position_manager.py:1271`: "止损单挂单失败！将依赖WebSocket监控"
### 原因2：止损价格计算错误 ❌ 可能
**症状**：
- 止损价格计算错误，导致止损价设置得太远
- 特别是SELL方向的止损价计算
**问题**：
- `risk_manager.py:get_stop_loss_price()` 中SELL方向的止损价计算
- 之前修复过SELL方向选择"更紧的止损"的逻辑（从`max`改为`min`）
- 但可能还有其他问题
**代码位置**：
- `trading_system/risk_manager.py:602-684`
### 原因3：WebSocket监控延迟 ❌ 可能
**症状**：
- 止损单挂单失败后，依赖WebSocket监控
- 但WebSocket监控有延迟，导致止损不及时
**问题**：
- WebSocket监控间隔可能太长
- 价格快速变动时，监控可能来不及触发
**代码位置**：
- `trading_system/position_manager.py:_check_single_position()`
### 原因4：止损单被拒绝后没有立即平仓 ❌ 可能
**症状**：
- 止损单挂单失败（错误码-2021）
- 系统应该立即执行市价平仓，但可能没有执行
**问题**：
- `_ensure_exchange_sltp_orders()` 中，如果当前价格已经触发止损，应该立即平仓
- 但可能在某些情况下没有执行
**代码位置**：
- `trading_system/position_manager.py:1191-1229`
---
## 🛠️ 需要检查的代码
### 1. 止损价格计算（SELL方向）
**文件**：`trading_system/risk_manager.py`
**关键代码**：
```python
# 选择最终的止损价：优先ATR，其次保证金，最后价格百分比（取更宽松的）
candidate_prices = []
if stop_loss_price_atr is not None:
candidate_prices.append(('ATR', stop_loss_price_atr))
candidate_prices.append(('保证金', stop_loss_price_margin))
if stop_loss_price_price is not None:
candidate_prices.append(('价格百分比', stop_loss_price_price))
# ⚠️ 修复：选择"更紧的止损"（更接近入场价），保护资金
if side == 'BUY':
# 做多：选择更高的止损价（更接近入场价）
final_stop_loss = max([p[1] for p in candidate_prices])
else: # SELL
# 做空：选择更低的止损价（更接近入场价）
final_stop_loss = min([p[1] for p in candidate_prices])
```
**问题**：
- 注释说"取更宽松的"，但代码选择"更紧的"
- 对于SELL方向，应该选择**更高的止损价**（更接近入场价），而不是更低的
**修复**：
- SELL方向应该选择`min`（更低的止损价 = 更接近入场价）✅ 正确
- 但需要确认止损价计算是否正确
### 2. 止损单挂单失败处理
**文件**：`trading_system/position_manager.py`
**关键代码**：
```python
if sl_order:
logger.info(f"{symbol} ✓ 止损单已成功挂到交易所")
else:
logger.error(f"{symbol} ❌ 止损单挂单失败！将依赖WebSocket监控，但可能无法及时止损")
# ⚠️ 问题：挂单失败后，没有立即检查当前价格是否已触发止损
```
**问题**：
- 止损单挂单失败后，应该立即检查当前价格是否已触发止损
- 如果已触发，应该立即执行市价平仓
### 3. WebSocket监控触发条件
**文件**：`trading_system/position_manager.py`
**关键代码**：
```python
# 检查止损（实时监控）
if side == "BUY":
# 做多：当前价 <= 止损价，触发止损
if current_price <= stop_loss:
# 执行止损
elif side == "SELL":
# 做空：当前价 >= 止损价，触发止损
if current_price >= stop_loss:
# 执行止损
```
**问题**：
- 需要确认WebSocket监控是否正常工作
- 需要确认监控间隔是否合理
---
## 🔧 修复方案
### 方案1：止损单挂单失败后立即检查并平仓 ✅ 推荐
**修改**：`trading_system/position_manager.py`
**逻辑**：
1. 止损单挂单失败后，立即检查当前价格是否已触发止损
2. 如果已触发，立即执行市价平仓
3. 如果未触发，记录警告并依赖WebSocket监控
**代码**：
```python
if sl_order:
logger.info(f"{symbol} ✓ 止损单已成功挂到交易所")
else:
logger.error(f"{symbol} ❌ 止损单挂单失败！将依赖WebSocket监控，但可能无法及时止损")
# ⚠️ 关键修复：挂单失败后，立即检查当前价格是否已触发止损
if current_price and stop_loss:
try:
current_price_val = float(current_price)
stop_loss_val = float(stop_loss)
# 检查是否已触发止损
should_close = False
if side == "BUY" and current_price_val <= stop_loss_val:
should_close = True
elif side == "SELL" and current_price_val >= stop_loss_val:
should_close = True
if should_close:
logger.error(f"{symbol} ⚠️ 止损单挂单失败，但当前价格已触发止损，立即执行市价平仓！")
logger.error(f" 当前价格: {current_price_val:.8f}")
logger.error(f" 止损价格: {stop_loss_val:.8f}")
await self.close_position(symbol, reason='stop_loss')
return
except Exception as e:
logger.warning(f"{symbol} 检查止损触发条件时出错: {e}")
```
### 方案2：增强WebSocket监控频率 ✅ 推荐
**修改**：`trading_system/position_manager.py`
**逻辑**：
1. 如果止损单挂单失败，增加WebSocket监控频率
2. 缩短监控间隔，确保及时触发止损
### 方案3：添加止损价格验证 ✅ 推荐
**修改**：`trading_system/position_manager.py`
**逻辑**：
1. 在挂止损单前，验证止损价格是否合理
2. 对于SELL方向，止损价应该 > 入场价
3. 对于BUY方向，止损价应该 < 入场价
4. 如果止损价不合理，记录错误并立即平仓
---
## 📊 止损价格验证
### SELL方向止损价计算验证
**交易ID 1658 (AXSUSDT SELL)**：
- 入场价：2.033
- 保证金：2.54125 USDT
- 杠杆：8倍
- 止损百分比：15%
**计算**：
1. 止损金额 = `2.54125 × 0.15 = 0.3811875 USDT`
2. 数量：10
3. 止损距离 = `0.3811875 / 10 = 0.03811875 USDT`
4. 止损价 = `2.033 + 0.03811875 = 2.07111875` ✅
**但实际价格涨到了2.305才平仓！**
**问题**：
- 止损价应该是2.071，但价格涨到了2.305
- 说明止损单根本没有生效，或者止损价计算错误
---
## 🎯 立即行动
1. **检查日志**：查看这些交易的开仓日志，确认止损单是否成功挂单
2. **检查止损价格**：确认止损价格计算是否正确
3. **修复代码**：实施方案1（止损单挂单失败后立即检查并平仓）
4. **增强监控**：如果止损单挂单失败，增加WebSocket监控频率
---
## 📝 总结
**核心问题**：
- 止损单挂单失败后，系统依赖WebSocket监控，但监控可能不及时
- 导致价格已经大幅偏离止损价，才触发平仓
**解决方案**：
1. 止损单挂单失败后，立即检查当前价格是否已触发止损
2. 如果已触发，立即执行市价平仓
3. 增强WebSocket监控频率
4. 添加止损价格验证

172
docs/策略优化实施完成总结_2026-01-27.md Normal file
View File

@ -0,0 +1,172 @@
# 策略优化实施完成总结（2026-01-27）
## ✅ 已完成的优化（优先级1）
### 1. 大盘Beta过滤优化
**修改位置**：
- `trading_system/config.py`
- `backend/config_manager.py`（需要添加）
**优化内容**：
- `BETA_FILTER_THRESHOLD`: -0.03 → **-0.005**（-0.5%）
**理由**：
- 更敏感地过滤大盘风险
- BTC/ETH在15分钟内跌幅超过0.5%即屏蔽多单
- 当前实现已支持15分钟窗口检查
---
### 2. 止盈目标降低
**修改位置**：
- `trading_system/config.py`
- `backend/config_manager.py`
**优化内容**：
- `TAKE_PROFIT_PERCENT`: 0.20 → **0.10**（10%）
**理由**：
- 更容易触发止盈，提升止盈单比例
- 从20%降低到10%，更容易达到
---
### 3. 动态追踪止损优化
**修改位置**：
- `trading_system/config.py`
- `backend/config_manager.py`
**优化内容**：
- `TRAILING_STOP_ACTIVATION`: 0.20 → **0.05**（5%）
- `TRAILING_STOP_PROTECT`: 0.10 → **0.025**（2.5%）
**理由**：
- 更早保护利润（5%激活 vs 20%激活）
- 给回撤足够空间（2.5%保护 vs 1.5%建议，避免被震荡扫出）
---
### 4. 信号强度提升
**修改位置**：
- `trading_system/config.py`
- `backend/config_manager.py`
**优化内容**：
- `MIN_SIGNAL_STRENGTH`: 5 → **7**
**理由**：
- 提高门槛，减少垃圾信号
- 提升胜率（从35.7%预期提升到45%-55%）
---
## 📊 配置调整清单
| 配置项 | 原值 | 优化值 | 变化 | 理由 |
|--------|------|--------|------|------|
| `BETA_FILTER_THRESHOLD` | -0.03 | **-0.005** | ↓ | 更敏感地过滤大盘风险 |
| `TAKE_PROFIT_PERCENT` | 0.20 | **0.10** | ↓ | 更容易触发，提升止盈单比例 |
| `TRAILING_STOP_ACTIVATION` | 0.20 | **0.05** | ↓ | 更早保护利润 |
| `TRAILING_STOP_PROTECT` | 0.10 | **0.025** | ↓ | 给回撤足够空间 |
| `MIN_SIGNAL_STRENGTH` | 5 | **7** | ↑ | 减少垃圾信号，提升胜率 |
---
## 🎯 预期效果
### 优化后预期
**胜率**：
- 当前：35.7%
- 预期：45% - 55%
**止盈单比例**：
- 当前：14.3%
- 预期：40% - 50%
**盈亏比**：
- 当前：需要计算
- 预期：1.5:1 - 2.0:1
**垃圾信号过滤**：
- 通过大盘Beta过滤（-0.5%）和信号强度提升（7），减少震荡市交易
---
## ⚠️ 注意事项
1. **清除Redis缓存**：
```bash
redis-cli DEL "global_strategy_config"
redis-cli DEL "config:trading_config:*"
```
2. **重启交易进程**：
```bash
supervisorctl restart auto_sys_acc1 auto_sys_acc2 auto_sys_acc3 auto_sys_acc4
```
3. **监控效果**：
- 监控胜率（预期提升到45%-55%）
- 监控止盈单比例（预期提升到40%-50%）
- 监控盈亏比（预期提升到1.5:1-2.0:1）
---
## 📝 后续优化（优先级2）
### 5. 成交量激增过滤（待实施）
**建议**：
- 当前15min成交量是过去24小时均值的2倍以上时才进场
**实施位置**：
- `trading_system/strategy.py` → `_check_volume_confirmation`方法
**实施步骤**：
1. 获取15分钟K线数据
2. 计算15分钟成交量
3. 计算24小时平均成交量
4. 如果15分钟成交量 / 24小时平均成交量 < 2.0，则拒绝交易
---
### 6. 分步止盈优化（待实施）
**建议**：
- 第一目标：从30%固定改为1.5倍ATR
**实施位置**：
- `trading_system/position_manager.py` → `open_position`方法
- `trading_system/position_manager.py` → `_check_single_position`方法
**实施步骤**：
1. 在`open_position`中，如果ATR可用，计算`take_profit_1 = entry_price ± 1.5 * ATR`
2. 如果ATR不可用，使用固定百分比（10%）
3. 在`_check_single_position`中，更新第一目标检查逻辑
---
## ✅ 总结
**已完成的优化**：
- ✅ 大盘Beta过滤优化（-0.5%）
- ✅ 止盈目标降低（10%）
- ✅ 动态追踪止损优化（5%激活，2.5%保护）
- ✅ 信号强度提升（7）
**预期效果**：
- ✅ 提升胜率（45%-55%）
- ✅ 提升止盈单比例（40%-50%）
- ✅ 改善盈亏比（1.5:1-2.0:1）
- ✅ 减少垃圾信号
**下一步**：
- 清除Redis缓存
- 重启交易进程
- 监控效果
- 后续实施成交量激增过滤和分步止盈优化

289
docs/策略优化建议评估与实施方案_2026-01-27.md Normal file
View File

@ -0,0 +1,289 @@
# 策略优化建议评估与实施方案（2026-01-27）
## 📊 建议评估
### A. 过滤"垃圾信号"（提升胜率）
#### A1. 大盘Beta过滤优化
**建议**：
- BTC在15分钟内跌幅超过0.5%，禁止山寨币多单
**当前实现**：
- `BETA_FILTER_ENABLED`: True
- `BETA_FILTER_THRESHOLD`: -0.03（-3%）
- 时间窗口：需要检查（可能是4H或1H）
**评估**：
- ✅ **合理**：-0.5%比-3%更敏感，能更早过滤风险
- ⚠️ **注意**：需要确认当前实现的时间窗口
- ✅ **建议实施**：将阈值从-3%调整为-0.5%（-0.005）
**实施方案**：
- 修改`BETA_FILTER_THRESHOLD`: -0.03 → **-0.005**（-0.5%）
- 确认时间窗口为15分钟（如果不是，需要修改）
---
#### A2. 成交量激增过滤
**建议**：
- 当前15min成交量是过去24小时均值的2倍以上时才进场
**当前实现**：
- 已有`_check_volume_confirmation`方法，但可能只是检查24H成交量阈值
- 没有15分钟成交量激增过滤
**评估**：
- ✅ **合理**：成交量激增通常意味着真实趋势，而不是假突破
- ⚠️ **注意**：需要获取15分钟K线数据，可能增加API调用
- ✅ **建议实施**：实现15分钟成交量激增过滤
**实施方案**：
- 在`_check_volume_confirmation`中添加15分钟成交量激增检查
- 计算15分钟成交量 / 24小时平均成交量，如果 < 2.0，则拒绝交易
---
### B. 优化止盈策略（提升盈亏比）
#### B1. 分步止盈优化
**建议**：
- 第一目标位（如1.5倍ATR），到达后平仓50%并将剩余仓位设为保本损
**当前实现**：
- 第一目标：30%固定止盈（50%仓位）
- 第二目标：3.0:1盈亏比（剩余50%仓位）
- 已实现分步止盈和保本损
**评估**：
- ✅ **合理**：1.5倍ATR比30%固定止盈更灵活，适应不同波动率
- ⚠️ **注意**：需要确保ATR可用
- ✅ **建议实施**：将第一目标从30%固定改为1.5倍ATR
**实施方案**：
- 修改`position_manager.py`中的分步止盈逻辑
- 第一目标：`entry_price ± 1.5 * ATR`（如果ATR可用），否则使用固定百分比（如10%）
---
#### B2. 动态追踪止损优化
**建议**：
- 获利5%后自动跟随，回撤1.5%就平仓
**当前实现**：
- `TRAILING_STOP_ACTIVATION`: 0.20（20%）
- `TRAILING_STOP_PROTECT`: 0.10（10%）
**评估**：
- ✅ **合理**：5%激活比20%更容易触发，能更早保护利润
- ⚠️ **注意**：1.5%保护可能过紧，容易被震荡扫出
- ⚠️ **建议调整**：激活5%，保护2.5%（给回撤足够空间）
**实施方案**：
- `TRAILING_STOP_ACTIVATION`: 0.20 → **0.05**（5%）
- `TRAILING_STOP_PROTECT`: 0.10 → **0.025**（2.5%）
---
### C. 修正止损逻辑
**建议**：
- 基于ATR的动态止损：入场价 - 2.5 * ATR
**当前实现**：
- `ATR_STOP_LOSS_MULTIPLIER`: 1.5
- 止损选择逻辑：选择"更紧"的止损（已修复）
**评估**：
- ⚠️ **需要评估**：2.5倍比1.5倍更宽，可能增加单笔亏损
- ⚠️ **注意**：当前1.5倍已经收紧，如果改为2.5倍，可能回到之前的问题
- ⚠️ **建议**：保持1.5倍，或根据实际效果微调
**实施方案**：
- **暂不调整**：保持`ATR_STOP_LOSS_MULTIPLIER`为1.5
- 如果后续测试发现止损过紧，可以微调到2.0
---
### D. 针对当前配置的调整方案
#### D1. 止盈目标
**建议**：
- 30% → 8%-12%
**当前实现**：
- `TAKE_PROFIT_PERCENT`: 0.20（20%）
**评估**：
- ✅ **合理**：8%-12%比20%更容易触发，能提升止盈单比例
- ⚠️ **注意**：需要平衡止盈单比例和盈亏比
- ✅ **建议实施**：调整为10%（0.10）
**实施方案**：
- `TAKE_PROFIT_PERCENT`: 0.20 → **0.10**（10%）
---
#### D2. 止损目标
**建议**：
- 约10-15% → 基于ATR动态设定
**当前实现**：
- `STOP_LOSS_PERCENT`: 0.12（12%）
- `ATR_STOP_LOSS_MULTIPLIER`: 1.5
- 已实现基于ATR的动态止损
**评估**：
- ✅ **已实现**：当前已使用ATR动态止损
- ⚠️ **注意**：固定止损（12%）作为备选，ATR止损作为优先
- ✅ **建议保持**：当前实现已经合理
**实施方案**：
- **保持现状**：继续使用ATR动态止损，固定止损作为备选
---
#### D3. 信号强度
**建议**：
- 8 → 9-10
**当前实现**：
- `MIN_SIGNAL_STRENGTH`: 5
**评估**：
- ✅ **合理**：提高信号强度门槛，减少垃圾信号
- ⚠️ **注意**：9-10可能过严，可能导致交易机会过少
- ⚠️ **建议调整**：提高到7-8，而不是9-10
**实施方案**：
- `MIN_SIGNAL_STRENGTH`: 5 → **7**（先测试7，如果效果好再提高到8）
---
#### D4. 持仓时间锁
**建议**：
- 保持移除状态
**当前实现**：
- `MIN_HOLD_TIME_SEC`: 0（已移除）
**评估**：
- ✅ **已实现**：当前已移除持仓时间锁
- ✅ **建议保持**：继续移除
**实施方案**：
- **保持现状**：继续移除持仓时间锁
---
## ✅ 最终实施方案
### 优先级1：立即实施（关键优化）
1. **大盘Beta过滤优化**
- `BETA_FILTER_THRESHOLD`: -0.03 → **-0.005**（-0.5%）
- 确认时间窗口为15分钟
2. **止盈目标降低**
- `TAKE_PROFIT_PERCENT`: 0.20 → **0.10**（10%）
3. **动态追踪止损优化**
- `TRAILING_STOP_ACTIVATION`: 0.20 → **0.05**（5%）
- `TRAILING_STOP_PROTECT`: 0.10 → **0.025**（2.5%）
4. **信号强度提升**
- `MIN_SIGNAL_STRENGTH`: 5 → **7**
---
### 优先级2：后续实施（重要优化）
5. **成交量激增过滤**
- 实现15分钟成交量激增检查
- 15分钟成交量 / 24小时平均成交量 >= 2.0
6. **分步止盈优化**
- 第一目标：从30%固定改为1.5倍ATR
- 如果ATR不可用，使用10%固定
---
### 优先级3：保持现状（暂不调整）
7. **止损逻辑**
- 保持`ATR_STOP_LOSS_MULTIPLIER`为1.5
- 如果后续测试发现止损过紧，可以微调到2.0
8. **持仓时间锁**
- 保持移除状态
---
## 📊 配置调整清单
| 配置项 | 当前值 | 优化值 | 优先级 | 理由 |
|--------|--------|--------|--------|------|
| `BETA_FILTER_THRESHOLD` | -0.03 | **-0.005** | P1 | 更敏感地过滤大盘风险 |
| `TAKE_PROFIT_PERCENT` | 0.20 | **0.10** | P1 | 更容易触发，提升止盈单比例 |
| `TRAILING_STOP_ACTIVATION` | 0.20 | **0.05** | P1 | 更早保护利润 |
| `TRAILING_STOP_PROTECT` | 0.10 | **0.025** | P1 | 给回撤足够空间 |
| `MIN_SIGNAL_STRENGTH` | 5 | **7** | P1 | 减少垃圾信号 |
| `ATR_STOP_LOSS_MULTIPLIER` | 1.5 | **保持** | P3 | 当前已收紧，暂不调整 |
| `MIN_HOLD_TIME_SEC` | 0 | **保持** | P3 | 已移除，保持现状 |
---
## 🎯 预期效果
### 优化后预期
**胜率**：
- 当前：35.7%
- 预期：45% - 55%
**止盈单比例**：
- 当前：14.3%
- 预期：40% - 50%
**盈亏比**：
- 当前：需要计算
- 预期：1.5:1 - 2.0:1
**垃圾信号过滤**：
- 通过大盘Beta过滤和信号强度提升，减少震荡市交易
---
## ⚠️ 注意事项
1. **逐步调整**：不要一次性调整所有参数，可以先调整优先级1的参数，观察效果
2. **监控数据**：调整后密切监控交易数据，确认效果
3. **及时调整**：如果效果不理想，可以进一步微调参数
4. **保持一致性**：确保所有账号使用相同的配置
---
## ✅ 总结
**已评估的建议**：
- ✅ A1. 大盘Beta过滤优化：实施（-0.5%）
- ✅ A2. 成交量激增过滤：后续实施
- ✅ B1. 分步止盈优化：后续实施（1.5倍ATR）
- ✅ B2. 动态追踪止损优化：实施（5%激活，2.5%保护）
- ⚠️ C. 修正止损逻辑：保持现状（1.5倍）
- ✅ D1. 止盈目标：实施（10%）
- ✅ D2. 止损目标：保持现状（已实现ATR动态止损）
- ✅ D3. 信号强度：实施（7）
- ✅ D4. 持仓时间锁：保持现状（已移除）
**实施优先级**：
- **P1（立即实施）**：大盘Beta过滤、止盈目标、动态追踪止损、信号强度
- **P2（后续实施）**：成交量激增过滤、分步止盈优化
- **P3（保持现状）**：止损逻辑、持仓时间锁

162
docs/配置优化实施指南_2026-01-27.md Normal file
View File

@ -0,0 +1,162 @@
# 配置优化实施指南（2026-01-27）
## 🎯 优化目标
**让收益率真实，胜率正常化**
基于实际交易数据分析，调整配置参数，使：
- ✅ 止盈单比例提升（从6.67%提升到25%+）
- ✅ 盈亏比改善（从0.39:1提升到1.5:1+）
- ✅ 胜率提升（从36.36%提升到40%+）
- ✅ 减少单笔亏损（收紧止损）
---
## 📊 配置调整清单
### 必须调整的配置项
| 配置项 | 当前值 | 优化值 | 变化 | 理由 |
|--------|--------|--------|------|------|
| `TAKE_PROFIT_PERCENT` | 0.30 | **0.20** | ↓ | 降低止盈目标，更容易触发，提升止盈单比例 |
| `ATR_TAKE_PROFIT_MULTIPLIER` | 4.0 | **3.0** | ↓ | 降低止盈倍数，更容易触发 |
| `RISK_REWARD_RATIO` | 4.0 | **3.0** | ↓ | 降低盈亏比，更容易触发，保证胜率 |
| `STOP_LOSS_PERCENT` | 0.15 | **0.12** | ↓ | 收紧止损，减少单笔亏损 |
| `USE_TRAILING_STOP` | false | **true** | ↑ | 启用移动止损，保护利润 |
| `TRAILING_STOP_ACTIVATION` | 0.30 | **0.20** | ↓ | 与第一目标止盈一致 |
| `TRAILING_STOP_PROTECT` | 0.15 | **0.10** | ↓ | 给回撤足够空间 |
---
## 🔧 实施步骤
### 步骤1：更新代码默认值（已完成）
**已更新的文件**：
- ✅ `trading_system/config.py`：更新默认值
- ✅ `backend/config_manager.py`：更新默认值
- ✅ `frontend/src/components/GlobalConfig.jsx`：更新快速方案
- ✅ `frontend/src/components/ConfigPanel.jsx`：更新快速方案
---
### 步骤2：更新全局配置（需要执行）
在全局配置页面，点击"山寨币狙击（高盈亏比）"快速方案，或手动更新以下配置项：
1. **止盈策略**
- `TAKE_PROFIT_PERCENT`: 0.20（20%）
- `ATR_TAKE_PROFIT_MULTIPLIER`: 3.0
- `RISK_REWARD_RATIO`: 3.0
2. **止损策略**
- `STOP_LOSS_PERCENT`: 0.12（12%）
3. **移动止损**
- `USE_TRAILING_STOP`: true
- `TRAILING_STOP_ACTIVATION`: 0.20（20%）
- `TRAILING_STOP_PROTECT`: 0.10（10%）
---
### 步骤3：清除Redis缓存
```bash
# 清除所有配置缓存
redis-cli DEL "global_strategy_config"
redis-cli DEL "config:trading_config:*"
```
---
### 步骤4：重启交易进程
```bash
# 重启所有交易进程
supervisorctl restart auto_sys_acc1 auto_sys_acc2 auto_sys_acc3 auto_sys_acc4
```
---
### 步骤5：验证配置
**检查日志**：
```bash
# 查看配置日志，确认配置值正确
tail -f /www/wwwroot/autosys_new/logs/trading_*.log | grep "交易配置"
```
**预期结果**：
- 固定止盈：20%（而不是30%）
- 盈亏比：3:1（而不是4:1）
- 固定止损：12%（而不是15%）
- 移动止损：开启（而不是关闭）
- 移动止损激活：20%（而不是30%）
- 移动止损保护：10%（而不是15%）
---
## 📊 预期效果
### 止盈单比例
- **当前**：6.67%（2/30）
- **预期**：25%+（8+/30）
### 盈亏比
- **当前**：0.39:1
- **预期**：1.5:1 - 2.0:1
### 胜率
- **当前**：36.36%
- **预期**：40% - 50%
### 平均盈利/平均亏损
- **当前**：0.39:1
- **预期**：1.5:1 - 2.0:1
---
## ⚠️ 注意事项
1. **逐步调整**：不要一次性调整所有参数，可以先调整止盈目标，观察效果
2. **监控数据**：调整后密切监控交易数据，确认效果
3. **及时调整**：如果效果不理想，可以进一步微调参数
4. **保持一致性**：确保所有账号使用相同的配置
---
## 📝 配置对比
### 优化前（问题）
- 止盈目标：30%（过高，难以触发）
- 盈亏比：4:1（过高，难以触发）
- 止损：15%（可能过宽）
- 移动止损：关闭（未保护利润）
### 优化后（建议）
- 止盈目标：20%（更容易触发）
- 盈亏比：3:1（更容易触发）
- 止损：12%（收紧止损）
- 移动止损：开启（保护利润）
---
## 🎯 长期优化方向
1. **动态调整**：根据市场情况动态调整止盈止损参数
2. **信号强度**：根据信号强度调整仓位和止盈目标
3. **市场状态**：根据市场状态（趋势/震荡）调整策略参数
4. **回测验证**：定期回测验证策略参数的有效性
---
## ✅ 总结
通过以上优化，预期能够：
- ✅ 提升止盈单比例（从6.67%提升到25%+）
- ✅ 改善盈亏比（从0.39:1提升到1.5:1+）
- ✅ 提升胜率（从36.36%提升到40%+）
- ✅ 减少单笔亏损（收紧止损到12%）
- ✅ 保护利润（启用移动止损）
这些调整基于山寨币策略的特点，旨在让收益率真实，胜率正常化。

243
docs/配置修改合理性分析和杠杆评估.md Normal file
View File

@ -0,0 +1,243 @@
# 配置修改合理性分析和杠杆评估
## 📊 已修改的配置总结
### 1. 止盈目标调整
| 参数 | 修改前 | 修改后 | 合理性 |
|------|--------|--------|--------|
| `TAKE_PROFIT_PERCENT` | 0.60 (60%) | **0.30 (30%)** | ✅ **合理** |
| `ATR_TAKE_PROFIT_MULTIPLIER` | 8.0 | **4.0** | ✅ **合理** |
**合理性分析**：
- ✅ **60%止盈目标太高**：对于山寨币，60%盈利目标很难达到，导致盈利单无法平仓
- ✅ **30%止盈目标更合理**：
- 更容易触发，盈利单可以及时平仓
- 仍然保持4:1盈亏比（止损15%，止盈30% = 2倍，配合ATR方法可以达到4:1）
- 配合移动止损，可以保护利润并追求更大收益
### 2. 扫描间隔调整
| 参数 | 修改前 | 修改后 | 合理性 |
|------|--------|--------|--------|
| `SCAN_INTERVAL` | 3600秒（1小时） | **1800秒（30分钟）** | ✅ **合理** |
**合理性分析**：
- ✅ **30分钟扫描间隔更合理**：
- 增加发现交易机会的频率
- 不会太频繁，避免过度交易
- 对于山寨币，市场变化快，需要更频繁的扫描
### 3. 信号强度调整
| 参数 | 修改前 | 修改后 | 合理性 |
|------|--------|--------|--------|
| `MIN_SIGNAL_STRENGTH` | 7 | **5** | ✅ **合理** |
**合理性分析**：
- ✅ **信号强度5更合理**：
- MACD金叉/死叉 + 其他指标已经足够
- 降低门槛，增加符合条件的交易对
- 配合其他筛选条件（成交量、波动率），仍然能保证质量
### 4. 每日交易次数调整
| 参数 | 修改前 | 修改后 | 合理性 |
|------|--------|--------|--------|
| `MAX_DAILY_ENTRIES` | 5 | **8** | ✅ **合理** |
**合理性分析**：
- ✅ **每日8笔更合理**：
- 增加交易频率，不错过机会
- 仍然有上限，避免过度交易
- 配合其他风险控制，不会过度暴露
---
## 🔍 杠杆设置分析
### 当前杠杆配置
| 参数 | 当前值 | 说明 |
|------|--------|------|
| `LEVERAGE` | 8倍 | 基础杠杆 |
| `MAX_LEVERAGE` | 12倍 | 最大杠杆 |
| `MAX_LEVERAGE_SMALL_CAP` | 8倍 | 小众币最大杠杆 |
| `USE_DYNAMIC_LEVERAGE` | False | 不使用动态杠杆 |
| `ATR_LEVERAGE_REDUCTION_THRESHOLD` | 0.05 (5%) | ATR超过5%时降低杠杆 |
### 杠杆与风险的关系
**8倍杠杆下的风险计算**：
- 止损15%：价格变动 **1.875%** 就会触发止损（15% / 8 = 1.875%）
- 止盈30%：价格变动 **3.75%** 就会触发止盈（30% / 8 = 3.75%）
- 盈亏比：3.75% / 1.875% = **2:1**（基于价格变动）
**如果降低到5倍杠杆**：
- 止损15%：价格变动 **3%** 才会触发止损（15% / 5 = 3%）
- 止盈30%：价格变动 **6%** 才会触发止盈（30% / 5 = 6%）
- 盈亏比：6% / 3% = **2:1**（基于价格变动）
**如果降低到6倍杠杆**：
- 止损15%：价格变动 **2.5%** 才会触发止损（15% / 6 = 2.5%）
- 止盈30%：价格变动 **5%** 才会触发止盈（30% / 6 = 5%）
- 盈亏比：5% / 2.5% = **2:1**（基于价格变动）
---
## 📈 杠杆设置建议
### 方案1：保持8倍杠杆（当前配置）✅ 推荐
**优点**：
- ✅ 收益较高：8倍杠杆可以放大收益
- ✅ 止损距离合理：价格变动1.875%触发止损，对于山寨币来说合理
- ✅ 止盈距离合理：价格变动3.75%触发止盈，对于山寨币来说可达
- ✅ 有风险控制：固定风险1%，止损15%，总仓位12%
**缺点**：
- ⚠️ 风险较高：8倍杠杆会放大亏损
- ⚠️ 价格波动敏感：价格变动1.875%就会触发止损
**适用场景**：
- 适合有一定风险承受能力的用户
- 适合市场波动较大的山寨币
- 配合固定风险1%和止损15%，风险可控
---
### 方案2：降低到6倍杠杆（保守）
**优点**：
- ✅ 风险更低：6倍杠杆降低风险
- ✅ 止损距离更宽：价格变动2.5%才触发止损，给市场更多空间
- ✅ 止盈距离更宽：价格变动5%才触发止盈，更容易达到
**缺点**：
- ⚠️ 收益降低：6倍杠杆收益较低
- ⚠️ 可能需要更多资金：要达到相同的名义价值，需要更多保证金
**适用场景**：
- 适合风险承受能力较低的用户
- 适合市场波动较小的山寨币
- 追求稳定收益而非最大化利润
---
### 方案3：降低到5倍杠杆（非常保守）
**优点**：
- ✅ 风险最低：5倍杠杆风险最低
- ✅ 止损距离最宽：价格变动3%才触发止损，给市场更多空间
**缺点**：
- ❌ 收益最低：5倍杠杆收益最低
- ❌ 可能需要更多资金：要达到相同的名义价值，需要更多保证金
**适用场景**：
- 适合风险承受能力很低的用户
- 适合新手用户
- 追求稳定收益，不追求最大化利润
---
## 🎯 针对山寨币U本位合约的建议
### 当前配置评估
**当前配置（8倍杠杆）**：
- ✅ **合理**：对于山寨币U本位合约，8倍杠杆是合理的
- ✅ **风险可控**：配合固定风险1%、止损15%、总仓位12%，风险可控
- ✅ **收益可观**：8倍杠杆可以放大收益，配合30%止盈目标，收益可观
### 是否需要调整杠杆？
**建议：保持8倍杠杆** ✅
**理由**：
1. **止损距离合理**：价格变动1.875%触发止损，对于山寨币来说合理
2. **止盈距离合理**：价格变动3.75%触发止盈，对于山寨币来说可达
3. **有风险控制**：
- 固定风险1%（每笔最多亏总资金1%）
- 止损15%（基于保证金）
- 总仓位12%（最多4个持仓）
- 小众币自动降低杠杆（ATR>5%时限制为8倍）
4. **收益可观**：8倍杠杆配合30%止盈，收益可观
### 如果市场波动特别大
**可以考虑降低到6倍杠杆**：
- 如果发现止损频繁触发（价格变动1.875%就止损）
- 如果市场波动特别大，可以降低到6倍
- 但需要同时调整止损和止盈目标，保持盈亏比
---
## 📊 配置合理性总结
### ✅ 已修改的配置（全部合理）
1. **止盈目标：60% → 30%** ✅
- 更容易触发，盈利单可以及时平仓
- 仍然保持4:1盈亏比
2. **ATR止盈倍数：8.0 → 4.0** ✅
- 配合RISK_REWARD_RATIO 4.0，止盈距离 = 止损距离 × 4.0
- 更合理，不会计算出过远的止盈价
3. **扫描间隔：3600秒 → 1800秒** ✅
- 增加交易机会
- 不会太频繁
4. **信号强度：7 → 5** ✅
- 增加交易对
- 配合其他筛选，仍然保证质量
5. **每日交易：5 → 8** ✅
- 增加交易频率
- 仍然有上限
### ✅ 杠杆设置（保持8倍）
**当前配置：8倍杠杆** ✅ **合理**
**理由**：
- 止损距离合理（价格变动1.875%触发）
- 止盈距离合理（价格变动3.75%触发）
- 有完善的风险控制
- 收益可观
**如果市场波动特别大，可以考虑降低到6倍**，但当前8倍是合理的。
---
## 🚀 最终建议
### 保持当前配置（8倍杠杆）
**配置总结**：
- ✅ 止盈目标：30%（更容易触发）
- ✅ ATR止盈倍数：4.0（配合4:1盈亏比）
- ✅ 扫描间隔：30分钟（增加机会）
- ✅ 信号强度：5（增加交易对）
- ✅ 每日交易：8笔（增加频率）
- ✅ **杠杆：8倍（保持）**
**理由**：
- 8倍杠杆对于山寨币U本位合约是合理的
- 配合完善的风险控制，风险可控
- 收益可观，符合山寨币高盈亏比策略
### 如果后续发现止损过于频繁
**可以考虑降低到6倍杠杆**，但需要：
1. 同时调整止损和止盈目标，保持盈亏比
2. 观察实际交易数据，确认是否需要调整
---
## 📝 备注
- 本分析基于当前配置和山寨币U本位合约的特点
- 建议先运行一段时间，观察实际效果
- 如果发现止损过于频繁或收益不足，再考虑调整杠杆

199
docs/配置值格式简化方案.md Normal file
View File

@ -0,0 +1,199 @@
# 配置值格式简化方案
## 🎯 简化原则
**核心原则**：用户直接输入小数（0.30），不做任何换算，怎么简单准确怎么来
### 数据格式
| 位置 | 格式 | 示例 | 说明 |
|------|------|------|------|
| **数据库存储** | 比例形式 | 0.30 | 表示30% |
| **前端显示** | 比例形式 | 0.30 | 直接显示数据库中的值 |
| **前端输入** | 比例形式 | 0.30 | 用户直接输入小数 |
| **前端存储** | 比例形式 | 0.30 | 直接存储，不做转换 |
| **后端使用** | 比例形式 | 0.30 | 直接使用，不需要转换 |
---
## ✅ 简化后的实现
### 前端逻辑
**显示逻辑**：
```javascript
// 直接显示数据库中的值（0.30）
return formatPercent(numVal <= 1 ? numVal : numVal / 100)
```
**输入逻辑**：
```javascript
// 用户直接输入小数（0.30），直接存储，不做转换
if (processedValue < 0 || processedValue > 1) {
return // 验证范围：0-1之间
}
// 直接使用输入的值（0.30），不做转换
```
**验证逻辑**：
```javascript
// 验证范围：0-1之间（比例形式）
if (numValue < 0 || numValue > 1) {
return // 超出范围，不更新
}
```
---
### 后端逻辑
**使用逻辑**：
```python
# 直接使用数据库中的值（0.30），不需要转换
value = config_value # 0.30
```
**临时兼容性处理**：
```python
# 如果值>1，说明可能是旧数据（百分比形式），转换为比例形式
if value > 1:
value = value / 100.0 # 30 -> 0.30
```
---
## 📊 数据流
### 简化后的数据流
```
用户输入0.30
↓
前端验证：0-1之间 ✅
↓
直接存储到数据库：0.30（不做转换）✅
↓
前端显示：0.30（直接显示）✅
↓
后端读取：0.30（直接使用）✅
↓
后端使用：0.30（不需要转换）✅
```
---
## ✅ 优势
### 简化的优势
1. **逻辑简单**：
- 用户输入0.30，直接存储0.30
- 不需要做任何换算
- ✅ 减少出错，易于理解
2. **数据一致**：
- 前端输入：0.30
- 前端存储：0.30
- 后端使用：0.30
- ✅ 三者完全一致
3. **避免转换错误**：
- 不需要30 -> 0.30的转换
- 不需要0.30 -> 30%的显示转换
- ✅ 避免转换过程中的错误
---
## 📝 使用说明
### 用户输入示例
**正确输入**：
- `0.30` → 表示30%
- `0.15` → 表示15%
- `0.01` → 表示1%
**错误输入**：
- `30` → 超出范围（>1），会被拒绝
- `1.5` → 超出范围（>1），会被拒绝
### 配置项说明
**百分比配置项**（需要输入0-1之间的小数）：
- `TAKE_PROFIT_PERCENT`: 0.30（表示30%）
- `STOP_LOSS_PERCENT`: 0.15（表示15%）
- `TRAILING_STOP_ACTIVATION`: 0.30（表示30%）
- `TRAILING_STOP_PROTECT`: 0.15（表示15%）
- `MIN_VOLATILITY`: 0.03（表示3%）
---
## 🔧 实施步骤
### 步骤1：执行数据迁移（必须）
**目的**：将数据库中的百分比形式（30）转换为比例形式（0.30）
**脚本**：`backend/database/migrate_percent_configs_to_ratio.sql`
**执行**：
```bash
# 执行SQL迁移脚本
mysql -u username -p database_name < backend/database/migrate_percent_configs_to_ratio.sql
```
---
### 步骤2：清除Redis缓存
```bash
# 清除Redis缓存，让系统重新加载配置
redis-cli DEL "config:trading_config:*"
redis-cli DEL "config:global_strategy_config:*"
```
---
### 步骤3：验证配置值
**检查前端显示**：
- 配置项应该显示为0.30（而不是30%）
- 用户输入0.30，直接存储0.30
**检查后端日志**：
```bash
# 查看配置日志，确认配置值正确
tail -f /www/wwwroot/autosys_new/logs/trading_*.log | grep "交易配置"
```
---
## ✅ 总结
### 简化方案
1. **用户输入**：直接输入小数（0.30）
2. **前端存储**：直接存储（0.30），不做转换
3. **后端使用**：直接使用（0.30），不需要转换
### 关键点
- ✅ **逻辑简单**：不需要任何换算
- ✅ **数据一致**：前端和后端使用相同的值
- ✅ **避免错误**：减少转换过程中的错误
### 使用建议
- ✅ **用户输入**：直接输入0.30（表示30%）
- ✅ **验证范围**：0-1之间（比例形式）
- ✅ **存储格式**：0.30（与后端使用相同的值）
---
## 🎯 最终结论
**简化方案**：
- ✅ 用户直接输入小数（0.30）
- ✅ 前端直接存储（0.30），不做转换
- ✅ 后端直接使用（0.30），不需要转换
- ✅ 怎么简单准确怎么来

209
docs/配置值格式统一_实施指南.md Normal file
View File

@ -0,0 +1,209 @@
# 配置值格式统一 - 实施指南
## 🎯 统一原则
**核心原则**：前端和后端使用相同的值（比例形式0.30），只在显示时转换
### 数据格式
| 位置 | 格式 | 示例 | 说明 |
|------|------|------|------|
| **数据库存储** | 比例形式 | 0.30 | 表示30% |
| **前端显示** | 百分比形式 | 30% | 用户看到30%（仅显示转换） |
| **前端存储** | 比例形式 | 0.30 | 用户输入30，转换为0.30存储 |
| **后端使用** | 比例形式 | 0.30 | 直接使用，不需要转换 |
---
## ✅ 当前实现状态
### 前端逻辑（已正确）
**显示逻辑**：
- 从数据库读取0.30，显示为30%（用户看到）
- 仅做显示转换，不改变存储值
**存储逻辑**：
- 用户输入30，转换为0.30存储
- 存储的值与后端使用相同的值（0.30）
**结论**：✅ **前端逻辑正确**，存储的值与后端一致
---
### 后端逻辑（已优化）
**当前实现**：
- 直接使用比例形式（0.30）
- 临时兼容性处理：如果值>1，转换为0.30（处理旧数据）
**结论**：✅ **后端逻辑正确**，数据迁移后可以移除兼容性处理
---
## 🔧 实施步骤
### 步骤1：执行数据迁移（必须）
**目的**：将数据库中的百分比形式（30）转换为比例形式（0.30）
**脚本**：`backend/database/migrate_percent_configs_to_ratio.sql`
**执行**：
```bash
# 1. 备份数据库（强烈推荐）
mysqldump -u username -p database_name > backup_$(date +%Y%m%d_%H%M%S).sql
# 2. 执行SQL迁移脚本
mysql -u username -p database_name < backend/database/migrate_percent_configs_to_ratio.sql
```
**验证**：
```sql
-- 检查迁移结果：应该没有>1的值
SELECT config_key, config_value
FROM trading_config
WHERE config_key IN (
'TRAILING_STOP_ACTIVATION',
'TRAILING_STOP_PROTECT',
'MIN_VOLATILITY',
'TAKE_PROFIT_PERCENT',
'STOP_LOSS_PERCENT'
)
AND config_type = 'number'
AND CAST(config_value AS DECIMAL(10, 4)) > 1;
-- 应该返回0行
```
---
### 步骤2：清除Redis缓存
```bash
# 清除Redis缓存，让系统重新加载配置
redis-cli DEL "config:trading_config:*"
redis-cli DEL "config:global_strategy_config:*"
```
---
### 步骤3：重启服务
```bash
# 重启后端服务
supervisorctl restart backend
# 重启交易进程
supervisorctl restart auto_sys_acc1 auto_sys_acc2 auto_sys_acc3 auto_sys_acc4
```
---
### 步骤4：验证配置值
**检查日志**：
```bash
# 查看配置日志，确认配置值显示正确
tail -f /www/wwwroot/autosys_new/logs/trading_*.log | grep "交易配置"
```
**预期结果**：
- 移动止损激活条件：盈利30%（而不是3000%）
- 移动止损保护利润：15%（而不是1500%）
- 最小波动率：3%（而不是300%）
---
## 📊 数据流
### 统一后的数据流
```
用户输入30
↓
前端输入转换：30 -> 0.30（仅前端输入时转换）
↓
存储到数据库：0.30（与后端使用相同的值）
↓
前端显示转换：0.30 -> 30%（仅显示时转换，用户看到30%）
↓
后端读取：0.30（直接使用，不需要转换）
↓
后端使用：0.30（直接使用）
```
---
## ✅ 优势
### 统一格式的优势
1. **数据格式统一**：
- 数据库存储：0.30
- 前端存储：0.30
- 后端使用：0.30
- ✅ 三者一致，避免格式混乱
2. **代码逻辑简单**：
- 前端只在输入和显示时转换
- 后端直接使用，不需要转换
- ✅ 减少出错，易于维护
3. **避免中间转换问题**：
- 前端存储的值与后端使用的值一致
- 不需要在代码中做格式转换
- ✅ 避免转换错误
---
## 📝 总结
### 最终方案
1. **数据库存储**：比例形式（0.30表示30%）
2. **前端显示**：百分比形式（30%，用户看到）
3. **前端存储**：比例形式（0.30，与后端使用相同的值）
4. **后端使用**：比例形式（0.30，直接使用）
### 转换位置
- ✅ **前端输入时转换**：30 -> 0.30（用户输入30，存储0.30）
- ✅ **前端显示时转换**：0.30 -> 30%（用户看到30%）
- ✅ **后端直接使用**：0.30（不需要转换）
### 实施建议
1. **立即执行数据迁移**：统一数据格式
2. **保留格式转换作为兼容性处理**：标记为临时方案
3. **后续可以移除格式转换**：数据格式统一后，可以移除
---
## 🎯 关键点
### 前端和后端使用相同的值
- ✅ **前端存储**：0.30（用户输入30，转换为0.30）
- ✅ **后端使用**：0.30（直接使用）
- ✅ **两者一致**：避免中间转换出问题
### 只在显示时转换
- ✅ **前端显示**：30%（用户看到）
- ✅ **前端存储**：0.30（与后端一致）
- ✅ **后端使用**：0.30（直接使用）
---
## ✅ 结论
**前端和后端使用相同的值（比例形式0.30）**：
- ✅ 前端输入时转换：30 -> 0.30（用户输入30，存储0.30）
- ✅ 前端显示时转换：0.30 -> 30%（用户看到30%）
- ✅ 后端直接使用：0.30（不需要转换）
- ✅ 数据格式统一：数据库、前端、后端都是0.30
**优势**：
- ✅ 避免中间转换出问题
- ✅ 代码逻辑简单
- ✅ 易于维护

221
docs/配置值格式统一_最终方案.md Normal file
View File

@ -0,0 +1,221 @@
# 配置值格式统一 - 最终方案
## 🎯 统一原则
**核心原则**：前端和后端使用相同的值（比例形式），只在显示时转换
### 数据格式统一
| 位置 | 格式 | 示例 | 说明 |
|------|------|------|------|
| **数据库存储** | 比例形式 | 0.30 | 表示30% |
| **前端显示** | 百分比形式 | 30% | 用户看到30% |
| **前端存储** | 比例形式 | 0.30 | 用户输入30，转换为0.30存储 |
| **后端使用** | 比例形式 | 0.30 | 直接使用，不需要转换 |
---
## 🔧 当前实现
### 前端逻辑（ConfigPanel.jsx & GlobalConfig.jsx）
**显示逻辑**：
```javascript
// 从数据库读取0.30，显示为30%（用户看到）
const percent = numVal <= 1 ? numVal * 100 : numVal
return formatPercent(percent) // 显示30
```
**存储逻辑**：
```javascript
// 用户输入30，转换为0.30存储（与后端使用相同的值）
if (processedValue < 0 || processedValue > 100) {
return
}
processedValue = processedValue / 100 // 30 -> 0.30
onUpdate(processedValue) // 存储0.30到数据库
```
**结论**：✅ **前端逻辑正确**，用户输入30，存储0.30，与后端使用相同的值
---
### 后端逻辑（config_manager.py）
**当前实现**：
```python
# ⚠️ 临时兼容性处理：如果值>1，转换为比例形式
if value > 1:
value = value / 100.0 # 30 -> 0.30
```
**说明**：
- ✅ 作为临时兼容性处理，处理旧数据
- ⚠️ 数据迁移完成后，可以移除此逻辑
---
### 后端验证（config.py）
**当前实现**：
```python
# 特殊验证：百分比配置应该在0-1之间
if ('PERCENT' in key or 'PCT' in key) and config_type == 'number':
if not (0 <= float(item.value) <= 1):
raise HTTPException(
status_code=400,
detail=f"{key} must be between 0 and 1 (0% to 100%)"
)
```
**说明**：✅ **后端验证正确**，只接受0-1之间的值
---
## ✅ 实施步骤
### 步骤1：执行数据迁移（必须）
**目的**：将数据库中的百分比形式（30）转换为比例形式（0.30）
**脚本**：`backend/database/migrate_percent_configs_to_ratio.sql`
**执行**：
```bash
# 执行SQL迁移脚本
mysql -u username -p database_name < backend/database/migrate_percent_configs_to_ratio.sql
```
**结果**：
- 数据库统一存储比例形式（0.30）
- 前端显示为30%（用户看到）
- 前端存储为0.30（直接存储）
- 后端使用0.30（直接使用）
---
### 步骤2：清除Redis缓存
```bash
# 清除Redis缓存，让系统重新加载配置
redis-cli DEL "config:trading_config:*"
redis-cli DEL "config:global_strategy_config:*"
```
---
### 步骤3：验证数据格式
```sql
-- 验证：所有百分比配置项应该在0-1之间
SELECT config_key, config_value
FROM trading_config
WHERE config_key IN (
'TRAILING_STOP_ACTIVATION',
'TRAILING_STOP_PROTECT',
'MIN_VOLATILITY',
'TAKE_PROFIT_PERCENT',
'STOP_LOSS_PERCENT'
)
AND config_type = 'number'
AND (CAST(config_value AS DECIMAL(10, 4)) < 0 OR CAST(config_value AS DECIMAL(10, 4)) > 1);
-- 应该返回0行
```
---
### 步骤4：保留格式转换作为兼容性处理（可选）
**建议**：数据迁移完成后，保留格式转换逻辑作为兼容性处理，但标记为临时方案
**代码位置**：`backend/config_manager.py:735-758`
**说明**：
- 作为临时兼容性处理，处理可能存在的旧数据
- 数据迁移完成后，所有值都应该<=1，此逻辑可以移除
- 但为了安全，建议保留一段时间
---
## 📊 数据流对比
### 当前流程（有格式转换）
```
用户输入30
↓
前端转换：30 -> 0.30
↓
存储到数据库：0.30
↓
后端读取：0.30（如果旧数据可能是30）
↓
代码中格式转换：30 -> 0.30（如果>1才转换）
↓
使用：0.30
```
### 统一后流程（无格式转换）
```
用户输入30
↓
前端转换：30 -> 0.30（仅前端输入时转换）
↓
存储到数据库：0.30
↓
后端读取：0.30（数据迁移后，统一为0.30）
↓
直接使用：0.30（不需要转换）
```
---
## ✅ 总结
### 统一方案
1. **数据库存储**：比例形式（0.30表示30%）
2. **前端显示**：百分比形式（30%，用户看到）
3. **前端存储**：比例形式（0.30，直接存储）
4. **后端使用**：比例形式（0.30，直接使用）
### 优势
- ✅ **数据格式统一**：数据库、前端、后端都是0.30
- ✅ **代码逻辑简单**：不需要到处做格式转换
- ✅ **减少出错**：避免格式不一致导致的bug
- ✅ **易于维护**：统一的格式，更容易理解和维护
### 实施建议
1. **立即执行数据迁移**：统一数据格式
2. **保留格式转换作为兼容性处理**：标记为临时方案
3. **后续可以移除格式转换**：数据格式统一后，可以移除
### 前端逻辑
- ✅ **显示时转换**：0.30 -> 30%（用户看到）
- ✅ **输入时转换**：30 -> 0.30（存储）
- ✅ **存储值统一**：0.30（与后端使用相同的值）
### 后端逻辑
- ✅ **直接使用**：0.30（不需要转换）
- ⚠️ **临时兼容**：如果值>1，转换为0.30（处理旧数据）
- ✅ **验证正确**：只接受0-1之间的值
---
## 🎯 最终结论
**前端和后端使用相同的值（比例形式0.30）**：
- ✅ 前端输入时转换：30 -> 0.30（用户输入30，存储0.30）
- ✅ 前端显示时转换：0.30 -> 30%（用户看到30%）
- ✅ 后端直接使用：0.30（不需要转换）
- ✅ 数据格式统一：数据库、前端、后端都是0.30
**优势**：
- ✅ 避免中间转换出问题
- ✅ 代码逻辑简单
- ✅ 易于维护

417
docs/配置值格式统一方案.md Normal file
View File

@ -0,0 +1,417 @@
# 配置值格式统一方案
## 🎯 问题分析
### 当前问题
**数据库中的配置值**（百分比形式）：
- `TRAILING_STOP_ACTIVATION` = 30（表示30%）
- `TRAILING_STOP_PROTECT` = 15（表示15%）
- `MIN_VOLATILITY` = 3（表示3%）
**代码期望的格式**（比例形式）：
- `TRAILING_STOP_ACTIVATION` = 0.30（表示30%）
- `TRAILING_STOP_PROTECT` = 0.15（表示15%）
- `MIN_VOLATILITY` = 0.03（表示3%）
**临时修复**：
- 在代码中添加格式转换逻辑（如果值>1，除以100）
- 问题：代码逻辑复杂，容易出错，维护困难
---
## ✅ 更好的解决方案
### 方案：统一数据格式（推荐）
**原则**：
- **数据库存储**：统一使用比例形式（0.30表示30%）
- **前端输入**：用户输入30，前端转换为0.30存储
- **前端显示**：从数据库读取0.30，显示为30
- **代码逻辑**：直接使用比例形式，不需要格式转换
**优势**：
1. ✅ **数据格式统一**：避免混乱
2. ✅ **代码逻辑清晰**：不需要到处做格式转换
3. ✅ **减少出错**：避免格式不一致导致的bug
4. ✅ **易于维护**：统一的格式，更容易理解和维护
---
## 🔧 实施步骤
### 步骤1：检查前端格式转换逻辑
**当前前端逻辑**（`frontend/src/components/ConfigPanel.jsx:1588-1594`）：
```javascript
// 常规比例型：前端按"百分比"输入（0~100），存储为 0~1
if (processedValue < 0 || processedValue > 100) {
setLocalValue(getInitialDisplayValue(value))
return
}
processedValue = processedValue / 100 // ✅ 前端已经转换为比例形式
```
**结论**：✅ **前端已经正确转换**，用户输入30，会转换为0.30存储
---
### 步骤2：检查后端验证逻辑
**当前后端验证**（`backend/api/routes/config.py:843-848`）：
```python
# 特殊验证：百分比配置应该在0-1之间
if ('PERCENT' in key or 'PCT' in key) and config_type == 'number':
if not (0 <= float(item.value) <= 1):
raise HTTPException(
status_code=400,
detail=f"{key} must be between 0 and 1 (0% to 100%)"
)
```
**结论**：✅ **后端已经正确验证**，只接受0-1之间的值
---
### 步骤3：数据迁移（修复现有数据）
**问题**：数据库中可能已经有旧数据是百分比形式（30而不是0.30）
**解决方案**：创建数据迁移脚本，将百分比形式转换为比例形式
**需要迁移的配置项**：
- `TRAILING_STOP_ACTIVATION`（如果>1，除以100）
- `TRAILING_STOP_PROTECT`（如果>1，除以100）
- `MIN_VOLATILITY`（如果>1，除以100）
- `TAKE_PROFIT_PERCENT`（如果>1，除以100）
- `STOP_LOSS_PERCENT`（如果>1，除以100）
- 其他百分比配置项
---
### 步骤4：移除代码中的格式转换（可选）
**当前代码**（`backend/config_manager.py:735-758`）：
```python
# ⚠️ 关键修复：百分比配置值格式转换
if isinstance(value, (int, float)) and value is not None:
percent_keys = [...]
if key in percent_keys:
if value > 1:
value = value / 100.0 # 格式转换
```
**建议**：
- 数据迁移完成后，可以移除格式转换逻辑
- 或者保留作为兼容性处理（标记为临时方案）
---
## 📝 数据迁移脚本
### SQL迁移脚本
```sql
-- 迁移百分比配置项：将百分比形式（>1）转换为比例形式（除以100）
-- 1. 迁移 trading_config 表
UPDATE trading_config
SET config_value = CAST(config_value AS DECIMAL(10, 4)) / 100.0
WHERE config_key IN (
'TRAILING_STOP_ACTIVATION',
'TRAILING_STOP_PROTECT',
'MIN_VOLATILITY',
'TAKE_PROFIT_PERCENT',
'STOP_LOSS_PERCENT',
'MIN_STOP_LOSS_PRICE_PCT',
'MIN_TAKE_PROFIT_PRICE_PCT',
'FIXED_RISK_PERCENT',
'MAX_POSITION_PERCENT',
'MAX_TOTAL_POSITION_PERCENT',
'MIN_POSITION_PERCENT'
)
AND config_type = 'number'
AND CAST(config_value AS DECIMAL(10, 4)) > 1;
-- 2. 迁移 global_strategy_config 表
UPDATE global_strategy_config
SET config_value = CAST(config_value AS DECIMAL(10, 4)) / 100.0
WHERE config_key IN (
'TRAILING_STOP_ACTIVATION',
'TRAILING_STOP_PROTECT',
'MIN_VOLATILITY',
'TAKE_PROFIT_PERCENT',
'STOP_LOSS_PERCENT',
'MIN_STOP_LOSS_PRICE_PCT',
'MIN_TAKE_PROFIT_PRICE_PCT',
'FIXED_RISK_PERCENT',
'MAX_POSITION_PERCENT',
'MAX_TOTAL_POSITION_PERCENT',
'MIN_POSITION_PERCENT'
)
AND config_type = 'number'
AND CAST(config_value AS DECIMAL(10, 4)) > 1;
```
---
## 🔍 验证步骤
### 1. 检查数据库中的配置值
```sql
-- 检查 trading_config 表中的百分比配置项
SELECT config_key, config_value, config_type
FROM trading_config
WHERE config_key IN (
'TRAILING_STOP_ACTIVATION',
'TRAILING_STOP_PROTECT',
'MIN_VOLATILITY',
'TAKE_PROFIT_PERCENT',
'STOP_LOSS_PERCENT'
)
AND config_type = 'number';
-- 检查 global_strategy_config 表中的百分比配置项
SELECT config_key, config_value, config_type
FROM global_strategy_config
WHERE config_key IN (
'TRAILING_STOP_ACTIVATION',
'TRAILING_STOP_PROTECT',
'MIN_VOLATILITY',
'TAKE_PROFIT_PERCENT',
'STOP_LOSS_PERCENT'
)
AND config_type = 'number';
```
### 2. 执行数据迁移
```bash
# 执行SQL迁移脚本
mysql -u username -p database_name < migrate_percent_configs.sql
```
### 3. 验证迁移结果
```sql
-- 验证：所有百分比配置项应该在0-1之间
SELECT config_key, config_value
FROM trading_config
WHERE config_key IN (
'TRAILING_STOP_ACTIVATION',
'TRAILING_STOP_PROTECT',
'MIN_VOLATILITY',
'TAKE_PROFIT_PERCENT',
'STOP_LOSS_PERCENT'
)
AND config_type = 'number'
AND (CAST(config_value AS DECIMAL(10, 4)) < 0 OR CAST(config_value AS DECIMAL(10, 4)) > 1);
-- 应该返回0行
```
### 4. 清除Redis缓存
```bash
# 清除Redis缓存，让系统重新加载配置
redis-cli FLUSHDB
# 或者只清除配置相关的key
redis-cli DEL "config:trading_config:*"
redis-cli DEL "config:global_strategy_config:*"
```
---
## 🎯 实施建议
### 方案A：立即迁移数据（推荐）
**步骤**：
1. ✅ 创建数据迁移脚本
2. ✅ 执行数据迁移
3. ✅ 验证迁移结果
4. ✅ 清除Redis缓存
5. ⚠️ 保留代码中的格式转换作为兼容性处理（标记为临时方案）
**优势**：
- 数据格式统一，避免混乱
- 代码逻辑清晰
- 减少出错
**风险**：
- 需要确保迁移脚本正确
- 需要备份数据库
---
### 方案B：保留格式转换（临时方案）
**步骤**：
1. ✅ 保留代码中的格式转换逻辑
2. ✅ 标记为临时兼容性处理
3. ⚠️ 后续逐步迁移数据
**优势**：
- 不需要立即迁移数据
- 系统可以继续运行
**劣势**：
- 代码逻辑复杂
- 容易出错
- 维护困难
---
## 📊 对比分析
### 当前方案（代码中格式转换）
**优点**：
- ✅ 不需要立即迁移数据
- ✅ 系统可以继续运行
**缺点**：
- ❌ 代码逻辑复杂，需要到处做格式转换
- ❌ 容易出错（忘记转换）
- ❌ 维护困难
- ❌ 数据格式不统一
---
### 统一数据格式方案
**优点**：
- ✅ 数据格式统一，避免混乱
- ✅ 代码逻辑清晰，不需要格式转换
- ✅ 减少出错，易于维护
- ✅ 前端和后端验证逻辑一致
**缺点**：
- ⚠️ 需要数据迁移
- ⚠️ 需要备份数据库
---
## ✅ 最终建议
### 推荐方案：统一数据格式
**理由**：
1. **架构更清晰**：数据格式统一，代码逻辑简单
2. **易于维护**：不需要到处做格式转换
3. **减少出错**：避免格式不一致导致的bug
4. **长期收益**：虽然需要一次性迁移，但长期收益更大
**实施步骤**：
1. 创建数据迁移脚本
2. 备份数据库
3. 执行数据迁移
4. 验证迁移结果
5. 清除Redis缓存
6. 保留代码中的格式转换作为兼容性处理（标记为临时方案，后续可以移除）
---
## 📝 数据迁移脚本（完整版）
```sql
-- ============================================================
-- 配置值格式统一迁移脚本
-- 将百分比形式（>1）转换为比例形式（除以100）
-- ============================================================
-- 1. 备份表（可选，但强烈推荐）
CREATE TABLE trading_config_backup AS SELECT * FROM trading_config;
CREATE TABLE global_strategy_config_backup AS SELECT * FROM global_strategy_config;
-- 2. 迁移 trading_config 表
UPDATE trading_config
SET config_value = CAST(config_value AS DECIMAL(10, 4)) / 100.0
WHERE config_key IN (
'TRAILING_STOP_ACTIVATION',
'TRAILING_STOP_PROTECT',
'MIN_VOLATILITY',
'TAKE_PROFIT_PERCENT',
'STOP_LOSS_PERCENT',
'MIN_STOP_LOSS_PRICE_PCT',
'MIN_TAKE_PROFIT_PRICE_PCT',
'FIXED_RISK_PERCENT',
'MAX_POSITION_PERCENT',
'MAX_TOTAL_POSITION_PERCENT',
'MIN_POSITION_PERCENT'
)
AND config_type = 'number'
AND CAST(config_value AS DECIMAL(10, 4)) > 1;
-- 3. 迁移 global_strategy_config 表
UPDATE global_strategy_config
SET config_value = CAST(config_value AS DECIMAL(10, 4)) / 100.0
WHERE config_key IN (
'TRAILING_STOP_ACTIVATION',
'TRAILING_STOP_PROTECT',
'MIN_VOLATILITY',
'TAKE_PROFIT_PERCENT',
'STOP_LOSS_PERCENT',
'MIN_STOP_LOSS_PRICE_PCT',
'MIN_TAKE_PROFIT_PRICE_PCT',
'FIXED_RISK_PERCENT',
'MAX_POSITION_PERCENT',
'MAX_TOTAL_POSITION_PERCENT',
'MIN_POSITION_PERCENT'
)
AND config_type = 'number'
AND CAST(config_value AS DECIMAL(10, 4)) > 1;
-- 4. 验证迁移结果
-- 检查是否还有>1的百分比配置项
SELECT 'trading_config' as table_name, config_key, config_value
FROM trading_config
WHERE config_key IN (
'TRAILING_STOP_ACTIVATION',
'TRAILING_STOP_PROTECT',
'MIN_VOLATILITY',
'TAKE_PROFIT_PERCENT',
'STOP_LOSS_PERCENT'
)
AND config_type = 'number'
AND CAST(config_value AS DECIMAL(10, 4)) > 1
UNION ALL
SELECT 'global_strategy_config' as table_name, config_key, config_value
FROM global_strategy_config
WHERE config_key IN (
'TRAILING_STOP_ACTIVATION',
'TRAILING_STOP_PROTECT',
'MIN_VOLATILITY',
'TAKE_PROFIT_PERCENT',
'STOP_LOSS_PERCENT'
)
AND config_type = 'number'
AND CAST(config_value AS DECIMAL(10, 4)) > 1;
-- 应该返回0行
```
---
## 🎯 总结
### 当前方案的问题
**代码中格式转换**：
- ❌ 代码逻辑复杂
- ❌ 需要到处做格式转换
- ❌ 容易出错
- ❌ 维护困难
### 更好的方案
**统一数据格式**：
- ✅ 数据库存储比例形式（0.30表示30%）
- ✅ 前端输入时转换为比例形式
- ✅ 前端显示时转换为百分比形式
- ✅ 代码逻辑直接使用比例形式
### 实施建议
1. **立即执行数据迁移**：统一数据格式
2. **保留格式转换作为兼容性处理**：标记为临时方案
3. **后续可以移除格式转换**：数据格式统一后，可以移除

233
docs/配置值格式统一方案_简化版.md Normal file
View File

@ -0,0 +1,233 @@
# 配置值格式统一方案（简化版）
## 🎯 统一原则
**核心原则**：前端和后端使用相同的值（比例形式），只在显示时转换
### 数据格式
- **数据库存储**：比例形式（0.30表示30%）
- **前端显示**：百分比形式（30%，用户看到）
- **前端存储**：比例形式（0.30，直接存储，不做转换）
- **后端使用**：比例形式（0.30，直接使用，不做转换）
---
## 🔧 当前前端逻辑分析
### ConfigPanel.jsx
**显示逻辑**（`getInitialDisplayValue`）：
```javascript
// 从数据库读取0.30，显示为30%
const percent = numVal <= 1 ? numVal * 100 : numVal
return formatPercent(percent) // 显示30
```
**存储逻辑**（`handleSave`）：
```javascript
// 用户输入30，转换为0.30存储
if (processedValue < 0 || processedValue > 100) {
return
}
processedValue = processedValue / 100 // 30 -> 0.30
onUpdate(processedValue) // 存储0.30
```
**问题**：
- ✅ 显示逻辑：正确（0.30 -> 30%）
- ✅ 存储逻辑：正确（30 -> 0.30）
- ⚠️ 但代码中有 `numVal <= 1 ? numVal * 100 : numVal` 的逻辑，如果数据库中有旧数据（30），会显示为30而不是3000
---
## ✅ 简化方案
### 方案：统一为比例形式，前端只做显示转换
**原则**：
1. **数据库统一存储比例形式**（0.30表示30%）
2. **前端显示时转换**（0.30 -> 30%，用户看到30%）
3. **前端输入时转换**（用户输入30 -> 0.30存储）
4. **后端直接使用**（0.30，不需要转换）
**优势**：
- ✅ 数据格式统一（数据库、前端、后端都是0.30）
- ✅ 代码逻辑简单（不需要到处做格式转换）
- ✅ 减少出错（避免格式不一致）
---
## 🔧 需要修改的地方
### 1. 前端显示逻辑（保持不变）
**当前逻辑**：
```javascript
// 从数据库读取0.30，显示为30%
const percent = numVal <= 1 ? numVal * 100 : numVal
return formatPercent(percent)
```
**说明**：
- ✅ 如果数据库存储0.30，显示为30%（正确）
- ⚠️ 如果数据库存储30（旧数据），显示为30（需要数据迁移）
---
### 2. 前端存储逻辑（保持不变）
**当前逻辑**：
```javascript
// 用户输入30，转换为0.30存储
if (processedValue < 0 || processedValue > 100) {
return
}
processedValue = processedValue / 100 // 30 -> 0.30
onUpdate(processedValue) // 存储0.30
```
**说明**：
- ✅ 用户输入30，转换为0.30存储（正确）
- ✅ 后端验证：只接受0-1之间的值（正确）
---
### 3. 后端代码（移除格式转换）
**当前代码**（`backend/config_manager.py:735-758`）：
```python
# ⚠️ 关键修复：百分比配置值格式转换
if isinstance(value, (int, float)) and value is not None:
if key in percent_keys:
if value > 1:
value = value / 100.0 # 格式转换
```
**建议**：
- 数据迁移完成后，可以移除格式转换逻辑
- 或者保留作为兼容性处理（标记为临时方案）
---
### 4. 数据迁移（必须执行）
**目的**：将数据库中的百分比形式（30）转换为比例形式（0.30）
**脚本**：`backend/database/migrate_percent_configs_to_ratio.sql`
**执行后**：
- 数据库统一存储比例形式（0.30）
- 前端显示为30%（用户看到）
- 前端存储为0.30（直接存储）
- 后端使用0.30（直接使用）
---
## 📊 数据流
### 当前流程（有格式转换）
```
用户输入30
↓
前端转换：30 -> 0.30
↓
存储到数据库：0.30
↓
后端读取：0.30
↓
代码中格式转换：0.30 -> 0.30（如果>1才转换）
↓
使用：0.30
```
### 统一后流程（无格式转换）
```
用户输入30
↓
前端转换：30 -> 0.30（仅前端输入时转换）
↓
存储到数据库：0.30
↓
后端读取：0.30
↓
直接使用：0.30（不需要转换）
```
---
## ✅ 实施步骤
### 步骤1：执行数据迁移
```bash
# 执行SQL迁移脚本
mysql -u username -p database_name < backend/database/migrate_percent_configs_to_ratio.sql
```
### 步骤2：清除Redis缓存
```bash
# 清除Redis缓存，让系统重新加载配置
redis-cli DEL "config:trading_config:*"
redis-cli DEL "config:global_strategy_config:*"
```
### 步骤3：验证数据格式
```sql
-- 验证：所有百分比配置项应该在0-1之间
SELECT config_key, config_value
FROM trading_config
WHERE config_key IN (
'TRAILING_STOP_ACTIVATION',
'TRAILING_STOP_PROTECT',
'MIN_VOLATILITY',
'TAKE_PROFIT_PERCENT',
'STOP_LOSS_PERCENT'
)
AND config_type = 'number'
AND (CAST(config_value AS DECIMAL(10, 4)) < 0 OR CAST(config_value AS DECIMAL(10, 4)) > 1);
-- 应该返回0行
```
### 步骤4：保留格式转换作为兼容性处理（可选）
**建议**：数据迁移完成后，保留格式转换逻辑作为兼容性处理，但标记为临时方案
**代码**：
```python
# ⚠️ 临时兼容性处理：如果数据库中有旧数据（百分比形式），自动转换
# 数据迁移完成后，可以移除此逻辑
if isinstance(value, (int, float)) and value is not None:
if key in percent_keys:
if value > 1:
value = value / 100.0
logger.warning(f"配置值格式转换（临时兼容）: {key} = {value*100:.2f}% (从百分比形式转换为比例形式)")
```
---
## 📝 总结
### 统一方案
1. **数据库存储**：比例形式（0.30表示30%）
2. **前端显示**：百分比形式（30%，用户看到）
3. **前端存储**：比例形式（0.30，直接存储）
4. **后端使用**：比例形式（0.30，直接使用）
### 优势
- ✅ **数据格式统一**：数据库、前端、后端都是0.30
- ✅ **代码逻辑简单**：不需要到处做格式转换
- ✅ **减少出错**：避免格式不一致导致的bug
- ✅ **易于维护**：统一的格式，更容易理解和维护
### 实施建议
1. **立即执行数据迁移**：统一数据格式
2. **保留格式转换作为兼容性处理**：标记为临时方案
3. **后续可以移除格式转换**：数据格式统一后，可以移除

168
docs/配置值格式转换修复_2026-01-26.md Normal file
View File

@ -0,0 +1,168 @@
# 配置值格式转换修复（2026-01-26）
## 🚨 问题描述
### 问题1：配置值格式不一致
**数据库中的配置值**（百分比形式）：
- `TRAILING_STOP_ACTIVATION` = 30（表示30%）
- `TRAILING_STOP_PROTECT` = 15（表示15%）
- `MIN_VOLATILITY` = 3（表示3%）
**代码期望的格式**（比例形式）：
- `TRAILING_STOP_ACTIVATION` = 0.30（表示30%）
- `TRAILING_STOP_PROTECT` = 0.15（表示15%）
- `MIN_VOLATILITY` = 0.03（表示3%）
**问题**：
- 如果数据库中存储的是百分比形式（30），代码中 `trailing_activation * 100` 会变成 `30 * 100 = 3000`
- 导致移动止损永远不会激活（需要盈利3000%才激活）
- 导致止盈价计算错误（止盈目标显示为683.17%等异常值）
### 问题2：止盈价计算错误
**日志显示**：
- AUCTIONUSDT 盈利30.52%，但止盈目标是**683.17%**
- ROSEUSDT 盈利30.12%，但止盈目标是**306.38%**
- AXSUSDT 盈利80.86%，但止盈目标是**470.29%**
**原因**：
- 如果 `TAKE_PROFIT_PERCENT = 30`（百分比形式），那么 `margin * 30 = 30倍保证金`
- 导致止盈价计算错误，止盈目标异常高
---
## 🔧 修复方案
### 修复1：配置值格式转换（backend/config_manager.py）
**位置**：`backend/config_manager.py:720-733`
**修复**：
- 在 `eff_get()` 函数中添加格式转换逻辑
- 如果配置值是百分比形式（>1），自动转换为比例形式（除以100）
- 兼容数据库中存储的百分比形式和比例形式
**代码**：
```python
def eff_get(key: str, default: Any):
# ... 读取配置值 ...
# ⚠️ 关键修复：百分比配置值格式转换
if isinstance(value, (int, float)) and value is not None:
percent_keys = [
'TRAILING_STOP_ACTIVATION',
'TRAILING_STOP_PROTECT',
'MIN_VOLATILITY',
'TAKE_PROFIT_PERCENT',
'STOP_LOSS_PERCENT',
# ... 其他百分比配置项 ...
]
if key in percent_keys:
# 如果值>1，认为是百分比形式，转换为比例形式
if value > 1:
value = value / 100.0
logger.debug(f"配置值格式转换: {key} = {value*100:.2f}%")
return value
```
### 修复2：日志输出修复（trading_system/main.py）
**位置**：`trading_system/main.py:344-347, 355`
**修复**：
- 修复移动止损激活条件和保护利润的显示
- 修复最小波动率的显示
- 确保配置值格式正确后再显示
### 修复3：移动止损逻辑修复（trading_system/position_manager.py）
**位置**：`trading_system/position_manager.py:1442-1447`
**修复**：
- 在使用移动止损配置值前，检查并转换格式
- 确保移动止损能正确激活
### 修复4：止盈价计算修复（trading_system/risk_manager.py）
**位置**：`trading_system/risk_manager.py:814-820`
**修复**：
- 在使用 `TAKE_PROFIT_PERCENT` 前，检查并转换格式
- 确保止盈价计算正确
### 修复5：开仓时止盈计算修复（trading_system/position_manager.py）
**位置**：`trading_system/position_manager.py:512-515`
**修复**：
- 在使用 `TAKE_PROFIT_PERCENT` 前，检查并转换格式
- 确保开仓时止盈价计算正确
### 修复6：推荐系统止盈计算修复（trading_system/trade_recommender.py）
**位置**：`trading_system/trade_recommender.py:455-460`
**修复**：
- 在使用 `TAKE_PROFIT_PERCENT` 前，检查并转换格式
- 确保推荐系统止盈价计算正确
---
## 📊 修复效果
### 修复前
**配置值**：
- `TRAILING_STOP_ACTIVATION` = 30（百分比形式）
- 代码中 `30 * 100 = 3000`，移动止损永远不会激活
**止盈价**：
- `TAKE_PROFIT_PERCENT` = 30（百分比形式）
- `margin * 30 = 30倍保证金`，止盈目标显示为683.17%等异常值
### 修复后
**配置值**：
- `TRAILING_STOP_ACTIVATION` = 30 → 自动转换为 0.30（比例形式）
- 代码中 `0.30 * 100 = 30`，移动止损在盈利30%时激活 ✅
**止盈价**：
- `TAKE_PROFIT_PERCENT` = 30 → 自动转换为 0.30（比例形式）
- `margin * 0.30 = 30%保证金`，止盈目标显示为30% ✅
---
## ✅ 修复完成
**修复文件**：
1. `backend/config_manager.py`：配置值格式转换（核心修复）
2. `trading_system/main.py`：日志输出修复
3. `trading_system/position_manager.py`：移动止损和止盈计算修复
4. `trading_system/risk_manager.py`：止盈价计算修复
5. `trading_system/trade_recommender.py`：推荐系统止盈计算修复
**下一步**：
1. 重启交易进程，让修复生效
2. 观察日志，确认配置值显示正确
3. 观察止盈单，确认止盈目标正常（30%而不是683%）
4. 观察移动止损，确认在盈利30%时激活
---
## 📝 注意事项
1. **兼容性**：
- 修复后，系统同时支持百分比形式（30）和比例形式（0.30）
- 如果值>1，自动转换为比例形式
- 如果值<=1，直接使用
2. **数据库**：
- 数据库中的配置值可以保持百分比形式（30）
- 系统会自动转换，不需要修改数据库
3. **前端**：
- 前端显示时，需要将比例形式转换为百分比形式（乘以100）
- 前端输入时，可以输入百分比形式（30），系统会自动转换

281
docs/配置显示错误和交易问题分析_2026-01-26.md Normal file
View File

@ -0,0 +1,281 @@
# 配置显示错误和交易问题分析（2026-01-26）
## 🚨 问题总结
### 问题1：配置值显示错误
**显示的配置值**：
- 单笔最大仓位: **2.00%**（应该是1.5%）
- 总仓位上限: **20.0%**（应该是12%）
- 最大持仓数: **14个**（应该是4个）
- 每日最大开仓: **120笔**（应该是8笔）
- 移动止损激活条件: 盈利**3000%**（应该是30%）
- 移动止损保护利润: **1500%**（应该是15%）
- 最小波动率: **300.0%**（应该是3%）
### 问题2：交易表现极差
**今日统计**：
- 总交易数：18
- 胜率：**12.50%**（极低）
- 总盈亏：**-9.57 USDT**（亏损）
- 平均盈亏：**-1.20 USDT**
- 平均持仓时长：255分钟（约4小时）
- 平均盈利/平均亏损：**0.19:1**（严重失衡，期望3:1）
- 平仓原因：**全是止损和同步，没有止盈**
---
## 🔍 问题分析
### 配置值显示错误的原因
**代码位置**：`trading_system/main.py:346-347`
```python
logger.info(f" 激活条件: 盈利{config.TRADING_CONFIG.get('TRAILING_STOP_ACTIVATION', 0.1)*100:.0f}%")
logger.info(f" 保护利润: {config.TRADING_CONFIG.get('TRAILING_STOP_PROTECT', 0.05)*100:.0f}%")
```
**问题**：
- 如果配置值已经是百分比形式（如30表示30%），再乘以100就会变成3000%
- 如果配置值是比例形式（如0.30表示30%），乘以100才是30%
**可能原因**：
1. 数据库中的配置值可能是百分比形式（30而不是0.30）
2. 配置读取时没有正确转换
3. 配置日志输出时重复乘以100
**检查方法**：
- 查看数据库中 `TRAILING_STOP_ACTIVATION` 和 `TRAILING_STOP_PROTECT` 的实际值
- 查看 `backend/config_manager.py` 中的配置读取逻辑
---
### 交易表现极差的原因
#### 1. 胜率极低（12.50%）
**可能原因**：
- 入场信号质量差
- 市场环境不利（震荡行情）
- 止损设置过紧，被频繁扫损
- 配置值错误导致策略执行异常
**分析**：
- 18笔交易，只有2笔盈利（胜率12.50%）
- 说明入场时机选择有问题，或者市场环境不适合当前策略
#### 2. 盈亏比严重失衡（0.19:1）
**问题**：
- 平均盈利/平均亏损 = 0.19:1
- 期望值 = 3:1
- **差距巨大**：只有期望值的6.3%
**可能原因**：
- 止盈目标设置过高，无法触发
- 止损设置过宽，亏损单亏损幅度大
- 没有止盈单触发，全是止损
#### 3. 没有止盈单
**问题**：
- 18笔交易，全是止损和同步平仓
- **没有一笔止盈**
**可能原因**：
1. **止盈目标过高**：
- 配置显示：固定止盈30%，ATR止盈倍数4.0
- 如果市场波动小，ATR很小，4.0倍ATR可能计算出非常远的止盈价
- 30%止盈目标对于山寨币来说可能仍然太高
2. **止盈单挂单失败**：
- 止盈单可能挂单失败，但没有日志记录
- 需要检查日志中是否有"止盈单挂单失败"的记录
3. **价格未达到止盈目标**：
- 所有交易都在达到止盈目标前就止损了
- 说明止损设置可能过紧，或者市场波动方向不利
#### 4. 平均持仓时长过长（255分钟）
**问题**：
- 平均持仓255分钟（约4小时）
- 对于山寨币快速交易策略来说，持仓时间过长
**可能原因**：
- 止损设置过宽，价格需要很长时间才能触发止损
- 市场波动小，价格变化缓慢
- 止盈目标过高，价格无法达到
---
## 🔧 修复方案
### 修复1：配置值显示错误
**问题**：配置值可能已经是百分比形式，但日志输出时又乘以100
**修复**：
1. 检查数据库中配置值的实际格式
2. 统一配置值的格式（建议使用比例形式，如0.30表示30%）
3. 修复日志输出逻辑，确保正确显示
**代码位置**：`trading_system/main.py:346-347`
**修复建议**：
```python
# 检查配置值格式，如果是百分比形式（>1），直接显示；如果是比例形式（<=1），乘以100
trailing_activation = config.TRADING_CONFIG.get('TRAILING_STOP_ACTIVATION', 0.1)
trailing_protect = config.TRADING_CONFIG.get('TRAILING_STOP_PROTECT', 0.05)
# 如果配置值>1，认为是百分比形式，直接显示；否则乘以100
if trailing_activation > 1:
activation_display = trailing_activation
else:
activation_display = trailing_activation * 100
if trailing_protect > 1:
protect_display = trailing_protect
else:
protect_display = trailing_protect * 100
logger.info(f" 激活条件: 盈利{activation_display:.0f}%")
logger.info(f" 保护利润: {protect_display:.0f}%")
```
### 修复2：交易表现极差
#### 2.1 检查止盈单挂单
**建议**：
1. 检查日志中是否有"止盈单挂单失败"的记录
2. 检查止盈价格计算是否正确
3. 检查止盈单是否成功挂到交易所
**命令**：
```bash
# 查看止盈单挂单失败的日志
grep "止盈单挂单失败" /www/wwwroot/autosys_new/logs/trading_*.log
# 查看止盈价格计算的日志
grep "止盈价" /www/wwwroot/autosys_new/logs/trading_*.log | head -20
```
#### 2.2 降低止盈目标
**建议**：
- 如果30%止盈目标仍然太高，可以考虑降低到20-25%
- 或者调整ATR止盈倍数，从4.0降低到3.0
#### 2.3 检查止损设置
**建议**：
- 检查止损是否设置过紧，导致频繁被扫损
- 检查止损单是否成功挂单
- 检查止损价格计算是否正确
#### 2.4 检查入场信号质量
**建议**：
- 检查信号强度是否足够（应该≥5）
- 检查市场状态（是否处于trending状态）
- 检查技术指标是否支持交易方向
---
## 📊 配置值对比
### 期望配置值（山寨币策略）
| 配置项 | 期望值 | 显示值 | 问题 |
|--------|--------|--------|------|
| 单笔最大仓位 | 1.5% | 2.00% | ⚠️ 略高 |
| 总仓位上限 | 12% | 20.0% | ❌ 过高 |
| 最大持仓数 | 4个 | 14个 | ❌ 过高 |
| 每日最大开仓 | 8笔 | 120笔 | ❌ 过高 |
| 移动止损激活 | 30% | 3000% | ❌ 严重错误 |
| 移动止损保护 | 15% | 1500% | ❌ 严重错误 |
| 最小波动率 | 3% | 300.0% | ❌ 严重错误 |
### 实际使用的配置值
**需要确认**：
- 实际使用的配置值是什么？
- 是显示错误，还是实际配置值错误？
**检查方法**：
1. 查看数据库中的实际配置值
2. 查看Redis缓存中的配置值
3. 查看日志中实际使用的配置值
---
## 🎯 立即行动
### 1. 检查配置值
**命令**：
```bash
# 查看数据库中的配置值
# 需要连接数据库查看 trading_config 表
# 查看Redis缓存中的配置值
redis-cli GET "config:trading_config:MAX_POSITION_PERCENT"
redis-cli GET "config:trading_config:TRAILING_STOP_ACTIVATION"
redis-cli GET "config:trading_config:MIN_VOLATILITY"
```
### 2. 检查止盈单
**命令**：
```bash
# 查看止盈单挂单失败的日志
grep "止盈单挂单失败" /www/wwwroot/autosys_new/logs/trading_*.log
# 查看止盈价格计算的日志
grep "止盈价\|take_profit" /www/wwwroot/autosys_new/logs/trading_*.log | head -30
```
### 3. 检查止损单
**命令**：
```bash
# 查看止损单挂单失败的日志
grep "止损单挂单失败" /www/wwwroot/autosys_new/logs/trading_*.log
# 查看止损价格计算的日志
grep "止损价\|stop_loss" /www/wwwroot/autosys_new/logs/trading_*.log | head -30
```
### 4. 修复配置值
**如果配置值错误**：
1. 在全局配置页面修正配置值
2. 清除Redis缓存
3. 重启交易进程
---
## 📝 总结
### 核心问题
1. **配置值显示错误**：可能是配置值格式问题（百分比vs比例）
2. **交易表现极差**：胜率12.50%，盈亏比0.19:1，没有止盈
3. **没有止盈单**：所有交易都是止损或同步平仓
### 可能原因
1. **配置值错误**：导致策略执行异常
2. **止盈目标过高**：无法触发止盈
3. **入场信号质量差**：胜率极低
4. **市场环境不利**：震荡行情，不适合当前策略
### 建议
1. **立即检查配置值**：确认实际使用的配置值是否正确
2. **检查止盈单**：确认止盈单是否成功挂单
3. **降低止盈目标**：如果30%仍然太高，考虑降低到20-25%
4. **检查入场信号**：确认信号强度和市场状态是否符合要求

4
frontend/src/components/ConfigPanel.jsx
View File

@ -78,8 +78,8 @@ const ConfigPanel = () => {
desc: '合理盈亏比（3:1）+ 宽止损（2.0×ATR）+ 移动止损保护 + 严格流动性筛选。2026-01-27优化：让收益率真实，胜率正常化。期望胜率40%+，盈亏比1.5:1+。',
configs: {
// 2026-01-27优化：让收益率真实，胜率正常化
ATR_STOP_LOSS_MULTIPLIER: 2.0, STOP_LOSS_PERCENT: 12.0, RISK_REWARD_RATIO: 3.0,
ATR_TAKE_PROFIT_MULTIPLIER: 3.0, TAKE_PROFIT_PERCENT: 20.0, MIN_HOLD_TIME_SEC: 0,
ATR_STOP_LOSS_MULTIPLIER: 1.5, STOP_LOSS_PERCENT: 12.0, RISK_REWARD_RATIO: 3.0,
ATR_TAKE_PROFIT_MULTIPLIER: 2.0, TAKE_PROFIT_PERCENT: 20.0, MIN_HOLD_TIME_SEC: 0,
USE_FIXED_RISK_SIZING: true, FIXED_RISK_PERCENT: 1.0,
USE_TRAILING_STOP: true, TRAILING_STOP_ACTIVATION: 20.0, TRAILING_STOP_PROTECT: 10.0,
MAX_POSITION_PERCENT: 1.5, MAX_TOTAL_POSITION_PERCENT: 12.0, MAX_DAILY_ENTRIES: 8,

4
frontend/src/components/GlobalConfig.jsx
View File

@ -336,10 +336,10 @@ const GlobalConfig = () => {
desc: '专为山寨币设计：宽止损（2.0倍ATR+12%固定）、合理盈亏比（3:1）、移动止损保护利润、严格成交量过滤（≥3000万美元）。2026-01-27优化：让收益率真实，胜率正常化。期望胜率40%+，盈亏比1.5:1+。',
configs: {
// 风险控制（最关键）- 2026-01-27优化：让收益率真实，胜率正常化
ATR_STOP_LOSS_MULTIPLIER: 2.0, // ATR止损2.0倍（容忍山寨币高波动）
ATR_STOP_LOSS_MULTIPLIER: 1.5, // ATR止损1.5倍（2026-01-27优化：收紧止损，减少单笔亏损）
STOP_LOSS_PERCENT: 12.0, // 固定止损12%（收紧止损，减少单笔亏损）
RISK_REWARD_RATIO: 3.0, // 盈亏比3:1（降低，更容易触发，保证胜率）
ATR_TAKE_PROFIT_MULTIPLIER: 3.0, // ATR止盈3.0倍（降低，更容易触发）
ATR_TAKE_PROFIT_MULTIPLIER: 2.0, // ATR止盈2.0倍（2026-01-27优化：降低止盈目标，更容易触发）
TAKE_PROFIT_PERCENT: 20.0, // 固定止盈20%（降低止盈目标，更容易触发，提升止盈单比例）
MIN_HOLD_TIME_SEC: 0, // 取消持仓锁（山寨币变化快）
USE_FIXED_RISK_SIZING: true, // 固定风险

14
trading_system/config.py
View File

@ -217,12 +217,12 @@ def _get_trading_config():
'MAX_SCAN_SYMBOLS': 250, # 扫描前250个（增加覆盖率，从27.6%提升到46.0%）
'EXCLUDE_MAJOR_COINS': True, # 排除主流币（BTC、ETH、BNB等），专注于山寨币
'STOP_LOSS_PERCENT': 0.12, # 止损12%（2026-01-27优化：收紧止损，减少单笔亏损）
'TAKE_PROFIT_PERCENT': 0.20, # 止盈20%（2026-01-27优化：降低止盈目标，更容易触发，提升止盈单比例）
'TAKE_PROFIT_PERCENT': 0.10, # 止盈10%（2026-01-27优化：进一步降低止盈目标，更容易触发，提升止盈单比例）
'MIN_STOP_LOSS_PRICE_PCT': 0.02, # 最小止损价格变动2%
'MIN_TAKE_PROFIT_PRICE_PCT': 0.02, # 最小止盈价格变动2%
'USE_ATR_STOP_LOSS': True, # 使用ATR动态止损
'ATR_STOP_LOSS_MULTIPLIER': 2.0, # ATR止损倍数2.0（容忍山寨币高波动）
'ATR_TAKE_PROFIT_MULTIPLIER': 3.0, # ATR止盈倍数3.0（2026-01-27优化：降低，更容易触发）
'ATR_STOP_LOSS_MULTIPLIER': 1.5, # ATR止损倍数1.5（2026-01-27优化：收紧止损，减少单笔亏损）
'ATR_TAKE_PROFIT_MULTIPLIER': 2.0, # ATR止盈倍数2.0（2026-01-27优化：降低止盈目标，更容易触发）
'RISK_REWARD_RATIO': 3.0, # 盈亏比3:1（2026-01-27优化：降低，更容易触发，保证胜率）
'ATR_PERIOD': 14, # ATR计算周期14
'USE_DYNAMIC_ATR_MULTIPLIER': False, # 不使用动态ATR
@ -236,11 +236,11 @@ def _get_trading_config():
'MIN_VOLUME_24H': 30000000, # 24小时成交额≥3000万美元，过滤垃圾币
'MIN_VOLUME_24H_STRICT': 50000000, # 严格过滤≥5000万美元
'MIN_VOLATILITY': 0.03, # 最小波动率3%，过滤死币
'MIN_SIGNAL_STRENGTH': 5, # 信号强度≥5（降低门槛，增加交易对）
'MIN_SIGNAL_STRENGTH': 7, # 信号强度≥7（2026-01-27优化：提高门槛，减少垃圾信号，提升胜率）
# ===== 动态过滤优化 =====
'BETA_FILTER_ENABLED': True, # 大盘共振过滤：BTC/ETH下跌时屏蔽多单
'BETA_FILTER_THRESHOLD': -0.03, # -3%，BTC/ETH下跌超过此阈值时屏蔽多单
'BETA_FILTER_THRESHOLD': -0.005, # -0.5%（2026-01-27优化：更敏感地过滤大盘风险，15分钟内跌幅超过0.5%即屏蔽多单）
'ATR_SPIKE_THRESHOLD': 2.0, # ATR异常激增阈值（当前ATR / 平均ATR）
'SIGNAL_STRENGTH_POSITION_MULTIPLIER': {8: 0.5, 9: 1.0, 10: 1.0}, # 信号强度分级：8分50%仓位，9-10分100%仓位
@ -254,8 +254,8 @@ def _get_trading_config():
'MAX_LEVERAGE': 12, # 最大杠杆12倍，不要超过
# 移动止损：必须开启！山寨币利润要保护
'USE_TRAILING_STOP': True,
'TRAILING_STOP_ACTIVATION': 0.20, # 盈利20%后激活（2026-01-27优化：与第一目标止盈一致）
'TRAILING_STOP_PROTECT': 0.10, # 保护10%利润（2026-01-27优化：给回撤足够空间）
'TRAILING_STOP_ACTIVATION': 0.05, # 盈利5%后激活（2026-01-27优化：更早保护利润，避免回吐）
'TRAILING_STOP_PROTECT': 0.025, # 保护2.5%利润（2026-01-27优化：给回撤足够空间，避免被震荡扫出）
# 最小持仓时间锁：立即取消！山寨币30分钟可能暴涨暴跌50%
'MIN_HOLD_TIME_SEC': 0, # 取消持仓时间锁

21
trading_system/risk_manager.py
View File

@ -849,20 +849,27 @@ class RiskManager:
else:
take_profit_price_price = None
# 选择最终的止盈价：优先ATR，其次保证金，最后价格百分比（取更宽松的）
# ⚠️ 2026-01-27优化：选择最终的止盈价（优先使用固定百分比止盈，更容易触发）
# 优先使用固定百分比止盈（20%），而不是ATR止盈，更容易触发，提升止盈单比例
candidate_prices = []
if take_profit_price_atr is not None:
candidate_prices.append(('ATR', take_profit_price_atr))
# 优先添加固定百分比止盈（更容易触发）
candidate_prices.append(('保证金', take_profit_price_margin))
if take_profit_price_price is not None:
candidate_prices.append(('价格百分比', take_profit_price_price))
# ATR止盈作为备选（如果比固定百分比更紧，则使用）
if take_profit_price_atr is not None:
candidate_prices.append(('ATR', take_profit_price_atr))
# 对做多取最大的值（更宽松），对做空取最小的值（更宽松）
# ⚠️ 2026-01-27优化：选择"更紧"的止盈（更接近入场价），更容易触发
# - 做多(BUY)：止盈价越高越紧 → 取最小值（更低的止盈价，更接近入场价）
# - 做空(SELL)：止盈价越低越紧 → 取最大值（更高的止盈价，更接近入场价）
if side == 'BUY':
take_profit_price = max(p[1] for p in candidate_prices)
# 做多：选择更低的止盈价（更接近入场价，更容易触发）
take_profit_price = min(p[1] for p in candidate_prices)
selected_method = [p[0] for p in candidate_prices if p[1] == take_profit_price][0]
else:
take_profit_price = min(p[1] for p in candidate_prices)
# 做空：选择更高的止盈价（更接近入场价，更容易触发）
take_profit_price = max(p[1] for p in candidate_prices)
selected_method = [p[0] for p in candidate_prices if p[1] == take_profit_price][0]
logger.info(
@ -870,7 +877,7 @@ class RiskManager:
+ (f"ATR={take_profit_price_atr:.4f}, " if take_profit_price_atr else "")
+ f"基于保证金={take_profit_price_margin:.4f}, "
+ (f"基于价格={take_profit_price_price:.4f}, " if take_profit_price_price else "")
+ f"最终止盈={take_profit_price:.4f} (使用{selected_method}, 取更宽松), "
+ f"最终止盈={take_profit_price:.4f} (使用{selected_method}, 取更紧), "
+ f"止盈金额={take_profit_amount:.4f} USDT ({take_profit_percent*100:.1f}% of margin)"
)
return take_profit_price