继miniQMT取消后，大QMT 内置策略被封掉文件读写和网络通信功能，现在问得最多的就是"要不要转 PTrade？"下文解释一下PTrade和入金的大QMT的区别。

PTrade 不是"没被限制的 QMT"

PTrade是恒生电子做的量化终端，券商采购回来给用户用，跟 QMT（迅投）是两家公司的两条产品线。

但它俩的关系，不是一个开放一个封闭。恰恰相反——PTrade 出厂那天起，就是监管想要的最终形态：

你的策略跑在券商机房的服务器上，不在你自己电脑里。好处显而易见：你电脑关机、家里断网，策略照样跑。代价呢？策略摸不到你本地的任何文件。注意，不是"被禁止"，是架构上压根就没有这回事——代码在别人机房，怎么读你家硬盘？

网络也一样。策略在券商内网里，连互联网都出不去。微信推送、调外部 API、爬数据？转过去一样干不了。如果你的策略就靠这些外部交互活着，换平台一分钱问题都解决不了。

第三方库是白名单制，还不能自己 pip 装，比 QMT 封得还死。Python 版本更离谱，多数券商还停在 3.5，只有少数升到了 3.11。代码还得上传到券商云端存着，保密性肯定不如在自己本地。

所以你看，10 月 23 日之后，QMT 内置策略其实是一路朝着 PTrade 的形态狂奔：封闭沙箱、标准接口、白名单库。**这俩平台的差别在缩小，不是在拉大。**想靠换平台"逃离监管"，方向就搞反了。

顺便澄清另一个常见误会。QMT 新增"禁止公有云虚拟机"，管的是策略运行环境——怕生成交易指令的地方不可追溯。PTrade 的客户端装在虚拟机里没事，因为那客户端就是个管理界面，真正生成指令的策略在券商机房跑着，本来就在人家眼皮底下，天然可审计。

区别到底有多少

重点关注

一是 API 体系，这是迁移最贵的成本。两套接口完全不兼容，ContextInfo换成 context，handlebar换成 handle_data，下单、查持仓、取行情全都得重写。所谓"迁移"，不是把代码复制过去改改函数名，是整个策略连数据管道重做一遍。

另一个是电脑关机策略照跑。

什么情况下建议转PTrade

先说可以认真考虑的：

做网格、轮动、定投、可转债 T+0 这类中低频策略的，用不到 tick 回测，也不依赖外部数据，迁移损失最小；家里没有（或者不想再伺候）一台 24 小时开机的主机；还有就是想分散一下平台风险的。

再说不建议转的：

策略靠外部数据、消息推送、桥接外部程序活着的，别转了，PTrade 内网隔离，转过去问题原封不动还在那；离不开 tick 级回测、十年以上历史数据、参数寻优的，回测是 PTrade 明显的短板；做期货期权的，PTrade 基本不支持；最后一种——策略本来就是纯内置、无外部交互，在 QMT 上跑得好好的，那换平台就更没有意义。

还有一类人卡在中间：策略确实需要外部交互，但不是不能改。比如推送改成盘后自己看导出文件，外部数据改成内置行情凑合。这类人该做的不是换平台，是先做沙箱化改造，改完再数数需求还剩几个。

低成本的做法

是这样的：先找一家两个平台都支持的券商，很多券商资产达标可以同时开 QMT 和 PTrade 权限，不用销户折腾。然后挑一个最简单的策略迁到 PTrade 仿真环境——千万别拿核心策略练手。迁移的过程会逼你搞清楚一堆事：白名单里到底有哪些库、Python 到底是几点几、数据接口的质量和覆盖怎么样、下单链路有哪些坑。

然后仿真跑满一个月。重点看三件事：策略行为跟预期一不一致、数据有没有坑、你能不能忍它的开发体验。

一个月之后，你手里拿的就是自己环境的实测结论，不是网上抄来抄去的对比表。各家营销文章里关于品种、门槛、行情档位的说法出入很大，只有你开户券商的仿真环境不骗你。

该不该换，取决于你要不要"托管"，而不是要不要"逃"。封的是通道，不是工具本身。先想清楚你的策略到底依赖什么，再决定换不换——这个顺序，别反。

开量化交易软件免费使用主页加联系方式，股票交易费率佣金优惠！