需求：
编写一个策略的过程中会先做历史回测，这时候需要用Buy/Sell这样的图表交易函数才能让TBQ3在回测过程中计算并统计交易数据。
回测通过后如果要转实盘交易时又要用A函数和OnOrder, OnFill, OnPosition等【账户事件】来处理实盘交易， 又要对原来回测的代码进行改动。
注意到放在同一个【策略单元】里包含OnSignal域的公式可以捕捉到同一个单元里其它公式产生的Buy/Sell信号，希望能利用这个机制将用于回测的代码与处理实盘交易的代码分离。理想情况举例：
实现两个公式：
- 【公式A-交易策略】： 包含实际的交易策略实现，通过Buy/Sell函数发出信号。
- 【公式B-实盘交易执行】： 没有交易策略，只是绑定要交易的实盘账户，通过OnSignal捕捉公式A里的信号并完成实盘交易操作。
使用过程：
- 回测时只加载【公式A-交易策略】，完成回测，如果要优化调整策略只需要改动公式A
- 回测通过后，实盘时只需要同时加载【公式A-交易策略】和【公式B-实盘交易执行】
问题：
1. 按照以上思路，如果想使用OnOrder, OnFill, OnPosition等域，是否需要用A_SubscribeTradeByCreateSource来订阅【公式A-交易策略】？ （我理解的是不需要，因为真实的通过A函数发出的委托其实是在【公式B-实盘交易执行】中完成的，与公式A无关）
2. 上述思路是否可行，有没有潜在的问题需要注意？
3. 为了解决描述的需求，是否还有其它的思路？
我不太理解，为啥要分两个公式啊？你直接把b公式的onsignal域 和订单驱动域复制到公式A合并不就好了？反正你公式A 的onsignal和订单驱动域都是i空的
想到一种可能的情况
听蔡老师说 代码的行数是有上限的
如果写不下了， 就可能单独把订单管理拿出来
顺便问一下，如果把订单域驱动代码复制到公式A合并，用历史数据回测的时候应该也会驱动onsignal,但是可以通过检查signal的flag是否是历史信号来过滤？
1. 想着可以先弄一个略粗糙的策略给相关人员回测分析，然后继续开发实盘需要处理的细节
2. 写代码习惯性的想把功能分开，希望实盘下单部分能重用，用的时候直接加载上去就实盘了。
一个文件里代码行数多了确实头疼，翻来翻去让人头大
应该不至于写到那么多
你的这个问题我好像讲onsignal的时候是说过的，signal结构体里是有一个标记信号是历史还是实时的flag的
你如果报单全都是B公式报的，A公式只是出信号不报单，那就不必订阅A函数的操作源
是的，今天实际测试了一下，确实不需要
buy/Sell操作的是虚拟账户
模拟账户、实盘账户 统称为实际账户
虚拟账户与实际账户其实没关系
模拟账户和实际账户其实也是独立的两个账户
buy/Sell操作的是虚拟账户
模拟账户、实盘账户 统称为实际账户
虚拟账户与实际账户其实没关系
模拟账户和实盘账户其实也是独立的两个账户
以前多个帖子回复指出：
除非高频模型
策略应该统筹考虑虚拟账户和实际账户操作
即实现所见即所得
兼容一：
策略驱动图表信号、账户操作
兼容二：
历史回溯、实时行情交易
兼容三：
策略任何时候重启 都应该信号连贯 除非极端情况 不妨碍仓位逻辑