🔴 高优先级（影响整体架构和工期）
1. WebSocket 实时推送的实现方式
现状：现有 WS 框架只有基础的 subscribe/broadcast 机制，没有任何交易数据的实时推送（order/trade/position/account/log 等全没有）。目前只有 tick、orderbook、kline 三个事件的 HTTP 轮询降级。

方案 A：后端实现完整的 WS 推送（网关事件 → push_event → 前端），这是最理想的方案但工作量最大
方案 B：全部用 HTTP 轮询代替 WS（5s 轮询一次），实现简单但实时性差、服务器压力大
方案 C：核心数据（行情/盘口）用 WS，其他（委托/成交/持仓/资金）用 HTTP 轮询，折中方案
你倾向哪种方案？
解：A

2. Phase 4 的可拖拽布局要不要做？
现状：需求文档 Phase 4 有"模块拖拽调整位置 + 布局持久化 + 三套预设布局"，这个功能实现复杂度较高（Grid 拖拽、碰撞检测、状态保存）。

做：按需求文档完整实现
不做：固定布局，用户只能折叠/展开模块，不能拖拽
简化版：只做折叠/展开 + 显示/隐藏（类似快速下单页的下拉复选框），不做拖拽
选哪个？
解：简化版

3. 快捷键功能要不要做？
需求里列了 F1-F3、Enter、Esc、Ctrl+Z、Ctrl+A 等快捷键。在 Web 端实现快捷键容易和浏览器快捷键冲突（如 Ctrl+Z 是撤销输入）。

完整实现
只做几个核心的（如 Esc 关闭弹窗、Enter 提交、F 系列的几个）
暂时不做，后面再加
解：只做核心


4. 前端模块复用策略
现状：现有页面（fw_page_market.js、fw_page_orders.js 等）都是整页渲染的，不能直接作为子模块嵌入交易台。

方案 A：从现有页面抽取核心逻辑，重写为模块化组件（init(container, state) + destroy()），工作量较大但代码质量高
方案 B：iframe 嵌入各页面（最快但体验差，通信复杂）
方案 C：交易台各模块直接新写，参考现有逻辑但独立实现（中等工作量）
你倾向哪种？
解：C，各主要前端功能全放一个文件夹，（全新独立，不依赖现有JS），后期会以当前这个为基准，所以当前这个JS更有价值量。  千万不要用IFRAME（效果太丑了）

🟡 中优先级（影响具体功能）
5. 数据范围和初始状态
默认显示哪个合约？（需求写 BTC-USDT-SWAP，确认一下）
委托历史默认显示多长时间？（今日/最近7天/全部）
成交记录默认显示多少条？（需求写 500 条上限，确认初始拉取 100 条？）
解：OKX，默认 BTC-USDT-SWAP,CTP 默认IMmain,委托默认显示七天，但未成交委托应该显示全部。，成交记录默认30条。

6. 多网关/多交易所支持
第一期只支持 OKX 一个网关，还是要支持多网关切换？
如果支持多网关，是在页面顶部切换还是每个模块可以独立选？
解：先一个网关一个界面，但支持切换网关功能。页面顶部切换，模块不独立，以页面为准（一个网关）

7. 条件单（止盈止损）
需求里下单面板有"条件单"类型，是指 OKX 的条件单（触发价格 + 委托价格），还是简单的止盈止损（TP/SL）？
快速下单页已经实现了 TP/SL 止盈止损，交易台是复用这个逻辑还是做条件单？
解：代码不复用，而是COPY过来，为全新独立代码。先实现简单的止盈止损TP/SL。

8. 系统日志（M9）的数据源
是显示后端服务日志（通过 WS 实时推），还是显示交易相关日志（下单/撤单/成交等操作记录）？
如果是后端日志，日志量很大，要不要做级别过滤和关键词搜索？
解：日志系统主要为交易记录以及其它核心操作记录，或重要的系统日志。考虑到简单困难度，先直接使用后端日志WS推送即可（级别由后端统一控制。比如：D:\Git\github\FwQuant\FWQuant\.fwquant\fw_web_settings.json  "logging": {
    "level": "INFO",

9. 网关连接弹窗（M10）
需求里有完整的网关配置功能（新建/编辑/删除/测试连接），但现有的 gateways.py 路由已经有这些功能了
是在交易台页面弹个轻量弹窗里做（只做连接/断开+状态显示），还是跳转到网关配置页面？
解：可以COPY其逻辑，，JS是必须独立的，

🟢 低优先级（细节问题）
10. 颜色语义方向
需求文档写"绿涨红跌 / 买入绿 / 卖出红"，和国内股票习惯一致
确认一下：OKX 本身是绿跌红涨（国际惯例），交易台用哪种？（我建议按需求文档来：绿涨红跌）
解：绿涨红跌，请新增 交易平台 的设置功能，可以切换

11. 数字滚动动画
盈亏、价格等数字变化要不要做滚动动画？（性能开销，好看但高频更新时可能闪）
解：不需要

12. 页面路由地址
交易台页面用什么地址？/dev/trading_desk 还是 /trading 还是其他？
菜单位置放在哪里？（左侧菜单第几项？）
解：/dev/trading_desk ，菜单位置，你确定即可，确定后告诉我位置，编号等即可

13. 验收标准调整
需求文档工期 12 天，你预期的交付节奏是？
要不要按 Phase 分阶段验收？（Phase 0 验收后再做 Phase 1，以此类推）
解：一口气完成所有功能。

其它功能：
	1、持久保存当前布局，以及 交易平台 设置功能（如：绿涨红跌 切换等）


核心思想：前端的功能基本都独立代码实现，后端可以使用已实现接口，，仅在
后端 实现 与接口：D:\Git\github\FwQuant\FWQuant\fw_core\fuwen_tradingdesk  做统一接口，与新增功能实现。。
后端：仅做 交易平台 路由：D:\Git\github\FwQuant\FWQuant\fw_web\routers\tradingdesk.py
前端：D:\Git\github\FwQuant\FWQuant\fw_web\static\js\page\fw_page_tradingdesk  全新代码，或以多个JS（比如每个模块一个js)方便管理，主界面一个JS

