为什么国内的量化平台 比方说掘金 和qmt仅仅都只支持win，而mac和linux不支持

编辑

复制

分享

掘金 QMT 仅支持Windows 原因

国内主流量化平台（如掘金、QMT）之所以“只支持 Windows”，并不是技术做不到，而是多重现实因素叠加后，厂商、券商、交易所三方共同形成的“路径依赖”。把原因拆开看，大致有下面几条：

1. 交易通道只给 Windows 发“身份证”
   券商从迅投、恒生等供应商采购的柜台系统（QMT、Ptrade 核心）本身就是 Windows DLL/EXE 形式封装的行情、交易 API。
   这些 DLL 直接对接交易所 FAST 行情、金证/恒生报单网关，内部用到了大量 Windows 特有机制（COM、命名管道、消息循环、IE 内核界面等）。
   供应商没有编译 Linux/macOS 的 .so/.dylib 版本，券商自然也无法提供第二套接口——于是上层 Python 封装（xtquant、掘金终端）只能跟着 Windows 走。

2. 监管报备“绑定硬件”
   程序化交易在证监局报备时要登记“终端物理特征码”“操作系统版本号”。
   券商为了合规风控，把“Windows + 固定机器码”写进了报备模板，一旦更换 OS 就要重新走审批。
   多平台支持意味着多套报备、多套风控脚本，券商没有动力去额外承担合规风险。

3. 用户画像决定投入
   量化活跃用户里 80% 以上集中在 Windows 7/10/11，真正长期跑实盘的机构也都是租 Windows 云主机（阿里云、腾讯云、华为云均为 Windows Server 镜像）。
   厂商评估 ROI 后，把有限的研发资源优先放在 Windows 稳定性上，对 macOS/Linux 需求“只听见呼声，看不到付费”。

4. 生态碎片化成本高
   Linux 发行版几十种、macOS 又有 Intel/Apple Silicon 两套架构，而量化库底层依赖 C++ 扩展、行情解码驱动、USB 证书驱动等，一旦跨平台就要重新编译、重签驱动、重做安装包。
   供应商宁愿让你“装一台 Windows 虚拟机”也不愿自己长期维护三套二进制。

5. 历史包袱与“能用就行”方案
   早年柜台软件就基于 Visual C++/MFC 开发，十几年迭代下来代码里 Windows 痕迹太重；
   对于会用 Python 的开发者，官方给出的折中方案就是：
   “Windows 上跑 miniQMT/掘金终端 → 用 pyzmq/http 把信号转发到 Linux/Mac 做计算”，既不用改核心，也能让非 Windows 机器参与策略研发。

一句话总结：
不是“不能”，而是“代价太大、收益太小、合规太烦”，于是形成了“Windows 锁定”的纳什均衡。真要在 macOS/Linux 上跑，只能：

• 用虚拟机/云主机装 Windows 跑官方客户端；

• 或者用 Windows 做网关，把行情/交易接口用 ZeroMQ、REST 封装后转给本地 Python。

在可预见的 1–2 年内，国内柜台架构不推倒重来，这种“Windows Only”局面基本不会改变。