上一篇讲了桥的道理，一个项目都没提。这一篇只说具体：现成的开源项目里，哪两个值得看，各自的优劣是什么。
一THE PITFALL
先说一个我自己踩的坑：搜法不对
我一开始用 miniqmt 这类词泛搜 GitHub，命中近百个仓库，翻了几页发现不对：
这类词命中的是「和这个生态有关」的项目，不是「为解决停用而生」的项目。
里面混着跟迁移毫无关系的东西 —— 行情小工具、策略示例、教程……而且星数混在一起排，完全没有意义。
换成定向词重搜（大 QMT / 桥接 / 迁移 / 换通道）后只剩二十多个，但基本每一个都在正题上（图 ①）。
教训：搜「生态词」得到的是生态，搜「意图词」才能得到答案。
方向定下来，剩下的判断其实很简单。选项目前只要看一件事：它的依赖里有没有「miniQMT / 极简模式 / XtQuantServer」。
跑在 miniQMT 一侧（不管用什么包装）→ ❌ 救不了 —— miniQMT 一停，它跟着停。跑在大 QMT 内置 Python 里 → ✅ 这才是答案。
按这条筛，生态里大致四类（图 ②）—— 只有「执行层桥接」这一类解决停用问题。
关于星数，三件事要说清楚：
① 星数每天都变 —— 所以本文不写精确数字，只写量级；
② 高星 ≠ 成熟 —— 第三类里星数最高的那个是上万星，但它恰恰不解决停用（它的历史使命是「跨平台访问」，不是「通道消失」）；
③ 低星 ≠ 不能用 —— 这批里很多是政策落地后才建的新仓库，也有的是私人自用、没打算推广。
这是按架构口径推出来的，不是实测结论 —— 我没把每个项目都跑一遍。但它不需要实验也能确定：一个「依赖某个服务」的程序，在该服务下线后必然失效。而且：「不解决停用」不等于「没用」 —— 在「miniQMT 还能用」的这几年、以及「跨平台访问」这个老问题上，它们的价值是实的。只是问题变了。
两个项目，本文统一用社区常见简称：xbc（xtquant_big_convert）、cfquant
先说一句实话：这两个项目的公开评价很少。 它们都很新（政策落地之后才起来的），公开渠道上几乎找不到使用者的系统评价。
xbc 的作者自己在 README 里说得很直白：「群里沉淀了不少踩坑讨论，但检索不到」—— 他甚至因此专门要求「提 bug 请走 issue」，好让下一个人能搜到。
自媒体转述里流传较广的一句判断是：「这两个怎么选，区别不大，任意选一个即可。」
这话有它的道理 —— 两者的思路确实一模一样：都在大 QMT 内置 Python 里架一层，对外暴露与 miniQMT 同名的方法。
但「区别不大」是站在「能不能跑通」的角度说的。如果你要长期依赖它，区别落在下面这张表上（图 ③）。
一句话结论：两者不是「谁更好」，是「谁更适合你的环境」。
而这张表里最该看的是「面向受限终端」那一行：
两个项目都为「库白名单受限的终端」做了专门适配。⇒ 说明 「库白名单」不是个别现象，是普遍存在的约束 —— 否则两家不会各自专门为它做一档。⇒ 所以 「能不能用」更真实的分水岭不是星数，是「它有没有为受限环境留后路」。
一个值得单独记的共性：两个项目都把自己的短处写在了明面上。
xbc 明说「RPC 层没有鉴权」；cfquant 的能力表里主动列出三项「不支持」，其中一项写得很直白 —— 回测走桥会慢，因为跨进程调用有开销。
「回测不要走桥」不是我们的猜测，是桥项目自己写下来的限制。这也说明：一个项目怎么讲自己的短板，比它怎么讲长板更能说明问题。
两者都逃不掉的边界（五条）：
① 实际可用性取决于你的终端 —— 都写着「取决于客户端环境是否暴露同名方法」，未在所有券商终端实测；
② 权限裁剪 —— 部分方法需 L2 / 两融权限，普通账户可能拿到空结果；
③ 回测不要走桥 —— 大批量历史数据落本地库，桥只负责实盘交易 + 少量实时查询；
④ 只监听本机 + 客户端常驻 —— 下单接口绝不能暴露公网；客户端重启后必须重跑入口脚本；
⑤ 字段映射与行情来源要自己核 —— 别假设返回字段与 miniQMT 完全一致；桥能给行情的前提是终端允许行情服务启动。
这四项不是「两个项目的特性对比」，而是你自己上手时必须问的问题 —— 不问，就要等出事才知道。
① 下单开关是不是默认关的？ 默认关，说明作者是谨慎的；一装上就能下单的，你要多想一秒。
② 有没有方法级白名单？ 它决定「外部能调多少」，也决定「敞口有多大」。
③ 有没有防重复下单？ 这条是一次真实事故换来的：某个 Redis 客户端库在 8.x 把默认重试次数从 3 次提到 10 次，而它用的写入命令不防重复 —— 于是「服务端收下了、只是应答丢了」的情况下会被重发，一次下单可能派发两次。
教训：出问题的不是项目自己的代码，是它依赖的一个库改了默认值。
④ 依赖有没有写版本上限？ 同上 —— 顺手看一眼，成本很低。
一句实话：这四项里，xbc 的公开文档都能找到明确答案；cfquant 有几项没写。没写不等于没有 —— 但「没写」本身就是你要评估的一部分：你得自己去试，或者去问作者。
最后一条最该先看：通道自己不做鉴权。 xbc 的文档写得很直接，我原文引一句：
「务必设密码、只监听本机——这座桥的 RPC 层没有鉴权。 访问控制只有两层：中间件自己的凭据，和下单开关。能连上它、知道队列名的人就能驱动这座桥，而队列名里带着资金账号。」
所以选桥时该问的第一个问题，不是「它有几个方法」，而是：别人要连上它，得先拿到什么？
五HOW TO CHOOSE
怎么选：三条能立刻用的建议
① 先跑只读自检，顺序别改。 全推行情 → 账户查询 → 持仓查询 → 板块列表。行情排第一（原因 04a 已讲：它是唯一一道改代码改不过去的关）。
② 开下单开关前，必须实测：小额 → 撤单 → 批量 → 多进程并发 → 断线恢复。
③ 自留一条兜底链路。 不要把命门只交给一个第三方项目。
用第三方之前，先记住四项风险：维护中断（多为个人新建仓库，无维护承诺）· 文档缺失（只用有 README + 示例的）· 权限依赖（L2 / 两融权限可能返回空）· 版本漂移（锁定版本，升级前先在模拟环境验证）。
下期预告
桥这条路到这里就讲完了。但它有个绕不开的属性：从头到尾都依赖外部进程和第三方项目 —— 它是一条有期限的路。下一篇换第三条路：把策略真正搬进客户端。那里没有跨进程通道、没有第三方依赖 —— 但也有一整套完全不同的规矩，约束、验证、数据一样都不少。
引用出处
本文数据均来自公开资料（截至 2026-09-23）。
· 仓库扫描与筛选口径：GitHub 公开检索。两次口径不同 —— 泛搜生态词命中近百但混入大量无关项目；定向搜意图词（大 QMT / 桥接 / 迁移）命中二十余个，本文用的是后者。星数与推送时间随时会变
· 两个项目的形态 / 模式 / 能力表 / 安全说明 / 依赖上限：各自公开的仓库文档与官网（采集日 2026-09-23）
· 「防重复」事故的来由：xbc 的 CHANGELOG / issue 记录 + 包索引公开元数据
· 行情服务被拒绝启动的表现：技术社区公开实测记录
三点说明：① 「能不能解决」是按架构口径判断的，不是实测结论 —— 判据是「桥接脚本跑在哪一侧」；我没有把项目逐个跑过。② 涉及开源项目均为技术分析，不构成推荐、背书或合作；接口与延迟会随版本变化，以你 clone / 安装到的那一版为准。③ 本文不引用作者本机环境的实测数据；涉及「我的实盘系统」的过程与踩坑，放在后面的《迁移实录》里讲。
开源项目引用声明
本文涉及的开源项目均为技术分析对象，不构成推荐、背书或合作。所有项目名称、形态、能力与安全说明，均来自其公开仓库 / 官网，采集日 2026-09-23，未做独立复核。正文对项目名做了脱敏（不点名对比），下面这张表是供查证的完整对应关系 —— 既避免「按名字评项目」，也让来源可追溯。
xbc · litaolemo/xtquant_big_convert
本文引用：形态组合 / 受限环境方案 / 安全说明 / 依赖上限 / 防重复事故
cfquant · 95ge/cfquant
本文引用：三档接入模式 / 能力表（含「不支持」三项）/ 部署与运维方式
补充说明：① 「能不能解决」是按架构口径判断的，不是实测结论；「社区可见度」也只反映星数与推送活跃度，不代表项目质量结论。② 开源项目的许可证、维护状态与安全设计请以仓库当前状态为准；尤其下单类接口，请务必自行做安全评估（默认关闭、只监听本机、金额与标的白名单）。③ 本文不引用作者本机环境的实测数据。
本文为个人学习与实践过程中的记录，仅作方法交流，不构成任何投资建议。
我是 VV_Fanss，退役码农转量化，记录量化系统的真实进化史。
这个系列会跟着迁移进度一路更新——关注我，下一篇更新时你能第一时间收到。也欢迎留言说说你在哪个环节卡住过（终端限制 / 权限 / 延迟 / 安全），我会把典型的情况整理进后续文章。
加我微信：VV_Fanss（备注"量化"） · 觉得有收获，欢迎点赞、在看、转发
VV的QMT手记 · 迁移系列 · 04b · 云纹
