每个品种单独一个策略单元，每个策略单元都是相同的公式，同时进行量化交易时怎样互相传递变量的值？他们是否共用账户权益数据？
这就是纯技术讨论了，选择自己觉得合适的技术方法就好
>每个品种单独一个策略单元，每个策略单元都是相同的公式，同时进行量化交易时怎样互相传递变量的值?
那就用PublishEvent发，用SubscribeEvent订阅后到OnEvent里面去收，没办法，跨越不同策略单元就是有点麻烦，交易时不建议用Dic数据来做收发，收盘后可以dic来收发。
>他们是否共用账户权益数据?
你指的用户权益应该是 真实的期货公司或证券公司开户的交易账户的权益数据吧。不存在共不共用之说。交易账户是交易账户，策略单元是策略单元，2个是独立的主体。
假设有【策略单元1】和【策略单元2】，有【真实账户1】和【真实账户2】，如果你在【策略单元1】的【头寸管理器】中把【真实账户1】添加进来了，那么只能说，【策略单元1】可以获取到【真实账户1】的权益数据，如果你在【策略单元1】的【头寸管理器】中又把【真实账户2】添加进来了，那么【策略单元1】可以同时获取到【真实账户1】和【真实账户2】的权益数据。这种以真实账户的权益数据作为交易依据的风险在于，以现有TB的机制下会存在并发风险问题的。这还不算上，你是否有能力掌控管理好，资金和头寸归属哪个真实账户的技术门槛，比如多个策略单元与多个真实账户之间多对多交叉绑定。
交易还是回到TB的每个独立的【策略单元】的【图表系统框架】下，做好图表系统【虚拟账户】初始资金分配，权益数据完全可以作为交易决策使用，剩下的事情就交给TB后台，他会把图表交易信号自动映射到真实账户去报单的，顶多就是上个【交易助手】解决实盘时盘口不成交的问题，加个【头寸监控器】统一汇总后，【虚拟账户】与【真实账户】的品种持仓量差异。再高级一点的可以上个【算法代理】代表性算法有【TB三步检查算法代理】，说不定还能解决【虚拟账户】与【真实账户】的交易滑点问题。
如果你指的用户权益应该是 图表系统的虚拟账户的权益数据，那么答案就是不共用，因为你的条件就是每个策略单元都是独立的，一个策略单元对应一个独立的虚拟账户。话说回来，一个策略单元可以同时包含多个策略，如果多个策略加载到同一个策略单元里面，那么虚拟账号对于不同策略来说权益数据就是共用的。
关于您提到的“他们是否共用账户权益数据”这个问题，您是否也在尝试解决我遇到的类似的问题？ https://bbs.tbquant.net/thread/20250129081833322722
关于怎样跨公式或者跨策略单元传递变量的值这个问题，我搞了几天终于解决了，先简单的说下结论
- 优先推荐非持久化的自定义基础数据Dic变量，对于数据量不大且传递不是非常频繁性能和时效性最好
- 也可以考虑使用自定义事件，SetGlobalVar函数，但是使用都比较麻烦，而且对数据类型有限制
- 如果数据量大，且更新频繁，可以通过减少同步频次和截断数据来避免使用Dic时性能问题
具体还要看您的使用场景，就我个人而言用非持久化的Dic频繁传递数值，字符串数组，二维数组还是很合适的。详细的问题可参看我之前的帖子和老师们的回复:
https://bbs.tbquant.net/thread/20250123165857150341
https://bbs.tbquant.net/thread/20250127111821243097
https://bbs.tbquant.net/thread/20250123165857150341
有个帖子地址贴重复了，漏了一个关于使用Dic时性能问题的帖子
https://bbs.tbquant.net/thread/20250204104147889281
最后发现是因为在每个历史bar上更新变量导致的性能问题（加载了几万个Bar，等于是极短时间内更新几万次). 后来优化了下代码改成部分数据分段更新，最大的一部分数据裁剪后在加载的最后一根历史bar上同步一次，实时数据在onbarclose更新，用Dic性能就几乎没有影响。只要频率不是太过分，Dic就是现成的很好的解决办法
还是不要引导他人在交易的时候 去操作dic数据，如果我们自己都无法保证 很好的掌控好一项技能的风险，驾驭不了他，这个建议还是乱给，比较好。
只是根据经验列了尝试过的三种方法，以及各自的特点，就我个人而言这三种方法我都在用，楼主根据自己的场景选择测试下就好。 我个人使用TB经验尚欠, 也不了解楼主具体要实现的策略，只是分享点信息，不敢也没有能力引导😃