v0.3.49

[0.3.49] - 2026-09-18

五条修复：合成回落帧补 suspendFlag 列（#331/#332，@yucejade）、日期窗合成回落裁头部垫行（#335，@yucejade）、方式一多账号在 zmq 下副账号起不来（#334，@simonfantasy）、同机多客户端进程订全推行情互相拆台（sub_id 折进 pid）、归还融资金额放错槽位时报错说清（#330）。

修复

• 合成回落帧缺 suspendFlag 列（#331 / #332，@yucejade）。回落 servant（ContextInfo.get_market_data）
  一混入 suspendFlag 整请求 0 行，所以那条路给不出这列；MiniQMT 全字段有它，下游 df["suspendFlag"]
  KeyError、自己 concat 补出 NaN 再 int() 直接崩。现在只在帧缺列且调用方要了这列（field_list 空或点名）
  时建列填 0，已有列不动，显式清单不多出列——边界与 #318 的 preClose 一致。0 是形状契约默认值，
  不是合成周期的真实停牌标志。

• 同机多个客户端进程订全推行情互相拆台。client_id 默认是每用户一份持久化文件
  （~/.cache/bigqmt/quote_client_id），两个进程共用它，sub_id 又各自从 1 数起——服务端按
  (client_id, sub_id) 计数，把两个进程看成一个订阅者：B 退订或心跳断掉，A 的订阅一起被拆。
  现在 sub_id 折进进程号（仍是 int，MiniQMT 的返回形状不变，unsubscribe_quote 照传），
  同机多进程各算各的；跨机器共用同一份配置时仍建议各设 BIGQMT_QUOTE_CLIENT_ID。README 加
  「多个客户端同时用一座桥」一节，说清三条通道各自的多消费者行为和吞吐共享。

• 方式一多账号在 zmq 下副账号起不来（#334，@simonfantasy）。_build_secondary 只有 redis 一条路：
  zmq 部署下给副账号套了个 redis client 为 None 的 RedisTransport，监听线程死于
  'NoneType' object has no attribute 'pubsub'；能 import redis 的环境则在没人跑的
  127.0.0.1:6379 上空转。现在 zmq 部署给副账号建自己的 zmq 端点：端口按副账号派生——
  和按该账号配置的 zmq 客户端派生连接地址的规则一致，客户端不用改；host 继承主账号
  bind_address 的，不会退回 loopback。pipe / mysql / shm 没有按账号的寻址，副账号拒建并
  记日志，不再建在死 client 上。#320 的副账号回报轮询在 zmq 下改走全推通道发（exec:*
  topic），不再因没有 redis sink 而关掉。

• 归还融资：金额填错槽位时报错说清楚（#330，@fengzhizialex）。调用方把还款金额放在 price、
  order_volume 传了可用资金——passorder 的直接还款金额走 volume 槽（整数元），price 被
  忽略，于是 volume 不到 1 元时报一句干巴巴的 volume must be positive，凑够了又按 volume
  还款。现在 32/45 的这条错误直接写明"金额走 order_volume、price 忽略、你传的是什么"，
  price>0 时服务端记一条日志。行为没变（一直是 volume），只是把规则说到报错里。

• 合成回落的日期窗请求也裁头部垫行（#335，@yucejade）。count=-1 + start_time 早于终端本地
  覆盖时，servant 把未覆盖的月份垫成"四价 = 窗口内第一根真实收盘、量额 0"的行，形态合法、
  消费方无法分辨（601318.SH 1mon 从 20250901 起三根 68.40 垫行）；此前只有 count 请求裁。
  现在日期窗一律裁头部连续垫行，MiniQMT 对未覆盖月份也不返回行。回落 servant 按默认
  skip_paused=True 调，真停牌周期本就不出行，所以这里的平价零量行只能是垫行。

v0.3.48

[0.3.48] - 2026-09-18

可转债：get_full_tick 的 types 认 cbond，转股 / 回售走 passorder 80-83（convert_bond / sell_back_bond，未实盘验证，请先 1 张试）；xtquant.xtdata shim 的 get_full_tick 补转发 types（#327，@karlthas007）。

新增

• 可转债：get_full_tick 市场令牌的 types 认 cbond（用户提议）。convertible（沪深转债）
  早就有，加 cbond / cb / convertible_bond 三个别名指向同一板块。
• 可转债转股 / 回售（用户提议，MiniQMT 没有、大 QMT 有）。xt_trader.convert_bond(account, code, 张数) 和 xt_trader.sell_back_bond(account, code, 张数)，按 account.account_type 选大 QMT 的
  passorder opType：普通户 转股 80 / 回售 81，信用户 82 / 83；返回和 order_stock 一样的 order_id。
  order_stock 直接传 80-83 也认（原样透传，没有买卖方向，价格送 0）。MiniQMT 的
  OPT_CONVERT_BONDS=51 是委托记录里的操作码、在 passorder 编号里是卖出平仓，不当别名收。
  没有转债持仓可实测，且转股不可撤销——请先用 1 张验证。

修复

• xtquant.xtdata shim 的 get_full_tick 不转发 types（#327，@karlthas007）：走 shim 的旧代码
  xtdata.get_full_tick(["SH"], types=[...]) 报 unexpected keyword argument 'types'，收窄能力用不上。
  现在原样转发。

v0.3.47

[0.3.47] - 2026-09-17

三条：方式一多账号副账号的委托/成交回调（#320/#322，按事件账号选频道 + 副账号轮询合成事件，闸门 2 在顶层策略文件要重启）、Redis 后台 BRPOP 存活时 adjust 不再抢 LPOP（#321，@wsmh）、部署脚本 redis zip 校验 + 原子下载（#323，@karlthas007，含两个分支 bug 的跟修）。

修复

• 方式一多账号下副账号的 on_stock_order / on_stock_trade 收不到（#320 @JinHaoran、#322
  @shihaibi——同一件事，#322 把两道闸门都点出来了）。闸门 2：事件按配置的主账号发到
  bigqmt:order_events:<主账号>，副账号客户端订的是自己的频道，主账号客户端也当它是主账号
  的单——现在按回报对象自带的 m_strAccountID 选频道，配置账号只作兜底。闸门 1：大 QMT 的
  order_callback / deal_callback 只回绑定账号的，副账号的委托成交进程里根本看不到，也没有
  MiniQMT 那种 subscribe(account)——新增 secondary_exec_poll：多账号管理器在 adjust 拍上
  对每个副账号轮询 get_trade_detail_data（ORDER / DEAL，主线程才答得出），委托按
  (合同编号, 状态, 成交量) 变化发一次、成交按成交编号发一次，经同一套 normalizer 发到该账号
  自己的频道，废单同样补发 on_order_error。启动后第一次轮询只建基线不发（重启不回放当天）。
  默认每 1 秒一次，rpc.secondary_exec_poll_seconds 可调、0 关；延迟一个轮询间隔，一个间隔内
  连跳多个状态只发最后一个。单账号部署不建轮询器，行为不变。闸门 2 在顶层策略文件里，
  需要重启策略；轮询器在包内。没有双账号终端可实测，请报告者部署后用副账号下一笔验证。

• Redis 后台 BRPOP 存活时，adjust 线程不要再 LPOP 同一条请求队列。rpc_background_threads=True 时 _queue_loop 已经在消费 bigqmt:rpc:queue:*；adjust 上的 drain_request_queue 再用 LPOP 会把 get_market_data_ex 等读请求抢到 QMT 主线程，实测把 100ms 节拍拖到 0.6–1.8s。后台线程活着就跳过 LPOP，线程挂了才回落 LPOP。（#321，@wsmh）

• deploy_qmt_bridge.ps1 第 3 步 redis zip 下载：校验 + 原子改名（#323，@karlthas007）：
  下载中断留下的半截 zip 不再被当成好的——Test-RedisZip 打开归档确认含 redis-server.exe；
  curl 先写到 .download 并带 --retry 3 --max-time 1800，校验通过才改名到位；新增 -RedisUrl
  指定镜像源。合并后修了它的两个分支 bug（Windows PowerShell 5.1 下逐分支跑过）：
  全新机器不传 -RedisZip 时默认路径不存在被当成「文件没找到」直接 throw，下载根本不会
  执行；下载参数里的 (if ($RedisUrl) {...} else {...}) 在 5.1 不是表达式，报
  The term 'if' is not recognized。现在只有显式传的 -RedisZip 缺失/损坏才报错，默认路径
  缺失或损坏一律走下载；源地址先赋变量再进参数数组。

v0.3.46

[0.3.46] - 2026-09-17

四个 issue 一起：江海 QMT get_full_tick 只回答已订阅代码（#310）、归还融资走 MiniQMT 写法被拒（#314）、方式一多账号副账号行情无回调（#315）、278de3f 的 preClose lag 兜底收窄并修回 11 个测试。

修复

• 江海证券大 QMT 2.1.19.0 上 get_full_tick 对任何代码都返回 {}（#310）。该终端的
  ContextInfo.get_full_tick 只回答已订阅的代码：没订阅的代码不报错，直接没有条目，
  单代码和 ["SH"] 整市场都一样；ping / 持仓 / get_market_data_ex 全部正常，看上去像
  桥的回归。报告者实测 subscribe_whole_quote(["600052.SH"]) 后再问就有完整五档。现在
  get_ticks 在原生快照漏掉了请求的代码时，才对漏掉的代码（市场 token 按 token 订，
  不按展开后的股票清单订）做一次 subscribe_whole_quote，然后重读直到出现或等满 2 秒
  （TICK_SUBSCRIBE_WAIT_SECONDS）；同一批代码之后的调用直接读，不再等。已订阅仍然没有
  条目的代码（停牌 / 退市 / 未开盘）按原样返回，不重复订、不重复等。订阅 300 秒没被
  get_full_tick 碰过就 unsubscribe_quote 掉（prune_tick_subscriptions，adjust 循环
  每拍调一次，包内也在下次 get_ticks 时懒回收）。国金的构建会回答未订阅代码，所以
  在那里这条路径从不触发（有测试钉住）。

  未验证：本机是国金 2.1.19.0，原生 get_full_tick 不需要订阅，所以订阅后到快照出现
  的实际延迟、以及 subscribe_whole_quote(["SH"]) 在江海构建上是否足以让整市场快照出现，
  只能由 #310 的报告者在其终端上确认。

• 归还融资走 MiniQMT 写法被拒：order_type 32 has no implicit buy/sell side; pass action explicitly
  （#314，@fengzhizialex）。#103 让 直接还款（32 / 45）必须显式传 action，理由是它没有证券腿、
  猜方向不对。但 MiniQMT 的 order_stock(acc, code, order_type, volume, price_type, price, strategy, remark) 签名里根本没有 action——按官方写法 order_stock(acc, code, CREDIT_DIRECT_CASH_REPAY, 金额, FIX_PRICE, 0, ...) 归还融资，兼容层无处可传，等于这条
  路根本走不通。行权 / 锁定 / 解锁（56-59）同样。

  方向本来只用于记账：送进 passorder 的是原始 opType（32 → 32，45 → 75），和方向无关。
  现在无方向类型不传 action 也接受，记账方向记 SELL；结算回找对这些类型不按方向过滤
  ——终端那一行报成哪边都认，不会再因为记账方向和终端不一致而在 3 秒后报「order not found
  in system」。显式传了 action 仍以传的为准；有方向的类型（融资买入 27、卖券还款 31 等）
  行为不变。

• 方式一多账号（BIGQMT_ACCOUNT_TYPE_MAP 单实例）下，副账号的全推行情「订阅成功但无回调」
  （#315，@JinHaoran）。推送通道按账号命名：服务端只往 bigqmt:quote_push:<主账号>:<topic>
  发，而按副账号配置的客户端订的是 bigqmt:quote_push:<副账号>:<topic>。副账号的
  subscribe_whole_quote 走自己的请求通道落到共用的 handlers、正常返回 seq，所以不报错——
  推送只是发到了没人听的频道。行情不分账号，现在发布端替桥服务的每个账号各发一份
  （redis 每账号一次 publish；zmq 的 PUB socket 多绑一个副账号的地址）。账号列表默认读
  BIGQMT_ACCOUNT_TYPE_MAP，单账号部署形状不变。客户端不用改。

• 278de3f（K线 preClose 行级 lag 兜底）收窄作用范围：第一版对所有帧无条件动作，打红了
  11 个测试，两条是真的语义倒退——(1) 显式 field_list 没点 preClose 也会多出这一列，
  返回形状和 MiniQMT 不一致；(2) 1w 的 preClose 终端恒为 0，#166 按日线取周首日真实前收
  回填，lag 先把 0 盖掉后回填看不到「缺」，除权在周首日的那周就是错价。现在只在调用方要了
  这列（field_list 为空或点了 preClose）时补列；有精确回填来源的周期（1w）不用 lag
  填 0，回填关掉或没有日线时按 #166 的约定留 0。其余周期的 0 行和缺列仍按 278de3f 用前
  一根 close 补。默认下载字段含 preClose（MiniQMT 全字段有它）这一条保留，对应测试更新。

v0.3.45

0.3.45 - 2026-09-16

修复

• bigqmt-init 的单文件部署选项在 pip 安装下必失败（用户实测反馈）：安装包不带 tools/ 生成器，而 init 工具按源码检出布局解析路径，选「单文件（base64 内嵌）」或「单文件（明文代码）」直接报 builder not found: ... (run this from a source checkout)。现在两个 builder 脚本和 no-redis 专用 zmq transport 以包数据形式打进 wheel，bigqmt-init 优先使用源码检出的 tools/、缺失时自动解包内副本；builder 自身也支持双布局寻源（仓库 src/ 优先，pip 安装布局通过 import 定位包与顶层模块）。单文件部署不再要求源码检出，pip install 后即可用。 已在干净 venv 装 wheel 端到端验证（构建成功、配置正确注入）。

说明

• 本版只动客户端安装/配置工具链（init_config 本就不进 QMT 沙箱，单文件嵌入也明确排除它），无服务端行为变化，不需要重启 QMT 策略。

v0.3.44

0.3.44 - 2026-09-15

本版三项改动合并前均过了完整回归（全套件 2148 项），合并后又在国金大 QMT 实盘终端逐项实测通过。

修复

• 高频并发下单（zmq，32 并发、6s 超时）一半超时，超时的单随后仍被下出（#303，@litaolemo）。passorder 在策略线程上串行（~200ms/笔），drain_pending 一拍取 20 笔一口气跑完再结算：首笔 0.2s 完成、回复 4.1s 才发；客户端放弃后桥照样下单。现在：信封带 timeout_seconds，轮到执行已过客户端期限的请求拒绝而不执行（RequestExpired，明确「没下单、可重试」，撤单不拒）；drain_pending 每拍限时（默认一个 adjust 间隔、最少 0.5s，rpc.drain_budget_seconds 可调），批内每 0.25s 结算回复；一次结算遍历按账号共用一份委托快照（N 查→1 查）；新只读方法 get_request_outcome(request_id) 让超时的客户端问清「没下/已下/编号多少」。旧客户端不带字段行为不变。实盘实测：5 并发每笔 0.31s 应答、柜台在途与已答编号精确一致；50ms 超时触发真拒绝且文案明确。探针脚本 _live_test_issue303_burst.py 已入库。

新增

• ETF 期权交易支持（@a180285）：query_stock_positions 改为 MiniQMT 惯例的 list 形状（同合约多空两行持仓都存活，原先 dict 形状会把后一行盖掉）；query_stock_asset 增加 fetch_balance（可取资金，m_dFetchBalance）；新增 xtdata.get_option_detail_data_batch(stockcodes) 一次 RPC 批量取期权合约详情（单只失败返回空字典不中断整批，默认超时 300s）；get_option_list 增加 available 拼写别名。常量映射已按 xtconstant 逐一核对。实盘实测：批量接口取真实 50ETF 合约 30 字段全对，fetch_balance 与可取资金一致。

• 进行中的多日周期 Bar：对账重建与缺行追加（#307 续 #226，@yucejade，实测于终端 2.0.8.300）。整窗读回的当期根在撮合后是 volume=0（救援合成无周期累计）、盘中整根缺失——触发条件从「窗口截断形状」改为「结果对账」：末根进行中即与周期日线累计比对，不符即重建（窗口覆盖不再是豁免）；末根已封但窗口跨当期且当期有日线时追加缺失的进行中根；时段门 09:30→09:15；get_local_data 无缓存 RPC 分支同样挂接。实盘对账数学实证：finalized 两周周线量与日线之和分毫不差。

说明

• 已知限制：#307 的「当期根追加」分支在实盘验证时因当日日线尚未入终端本地库未触发（降级路径保留原答案、不造数，行为正确）；期权账户（类型 6）的下单路径只走了单测与常量核对，无实盘期权账户验证。

v0.3.43

0.3.43 - 2026-09-14

#299 备注复用串号的二次修复（#302）——#300 的守卫有实盘缺口，本次发版的是经实盘验证的版本。

修复

• #300 的守卫不够：同备注同秒串行的下一笔仍拿到上一笔的合同编号（#299 的实盘复测，2026-09-14，工商银行跌停价探针）。#300 要求候选是本单的 stock / 方向 / 且不早于提交时刻，但两个时间戳都不是所有权的证据：第一笔走慢路径结算后，它自己的 order_callback 在下一笔已经开始之后才落到 watch 表，回调的到达时间过了下一笔的 not-before 守卫，于是第一笔已返回过的编号又答了第二笔的结算（实证第二笔 0 毫秒「结算」）。轮询路径同理：两行落在同一秒时，秒级精度的 not-before 守卫放行上一行，取最早一条又正好选中它。

  现在桥侧记一份「该备注下已结算出去的编号」日志（有界 FIFO）：两条查找路径都排除已结算的编号，结算成功时把编号记为已花费。回调到达时间只说明回调什么时候到，不说明它属于哪张单；一个编号返回给调用方之后就是那张单的，永远不再答同备注的后一笔。

  修前实证：两笔同备注串行买单返回同一编号 635099484，第二笔真实编号是 635099485；修后同一探针两笔各归各的编号（两行同在一秒——正是修前失败的场景）。四笔探针单全部撤销，无持仓遗留。

说明

• 0.3.42（#300）当天发版当天被实盘复测抓到缺口；本版是同一 issue 的完整修复。已在国金大 QMT 实盘（Python 3.6.8 沙箱、redis 传输）验证。
• 已知限制：无新增。

0.3.42 — 备注复用不再返回别的单的合同编号

单条修复，但要尽快上：把已成交判成在途，调用方一重试就是重复下单。

备注复用时 order_stock 返回别的单的合同编号（#299 / #300）

由 @pujfei 带 exec 事件流水报告，根因定位到行。

串行脚本用 串行买入600股 这种备注跨票跨批次复用。三笔单全部成交，order_stock 返回的 oid 却分别是 13 分钟前另一批、上一批、本批第一笔的编号——总是「最近一张同备注单」的编号：

submit                      returned   real
600999.SH BUY 600 @17.78    9879       11355
600519.SH BUY 100 @1300.83  9877       11367
600418.SH BUY 600 @19.40    11355      11387

调用方按 MiniQMT 惯例用返回的 oid 关联 on_stock_order，把真事件全过滤掉，三笔已成被判成在途；在那里重试或撤单重挂就是重复下单。

根因：两条查找路径都只认备注。快路径的 watch 表（#164）每个备注一个槽，上一张同备注单的回调写进去的编号，在本单自己的回调落地之前就答了本单的结算，直接返回、慢路径根本没跑。慢路径取 by_remark[0]，是最早那条，没有 stock / 方向 / 时间过滤。整套逻辑建立在「备注唯一」上——自动生成的 bqrpc:<uuid> 是唯一的，调用方自己传的不是。

修法：OrderSettlement 在 passorder 之前记下提交时刻；两条路径都要求候选是本请求的 stock 和方向，且不早于那个时刻——watch 表的条目按学到的时间判，委托行按 order_time（#267 之后是真实秒数）判。同 stock 同备注多条都不早于提交时刻时取最早的一条，网格在本单结算期间又挂的下一格不能顶掉本单。行没带方向或没带时间的不按那一维拒，避免把真行判成「不在系统里」。备注的语义不变，只是不再单独充分。

用报告里那批按真实竞态时序复现：修前三笔全错，修后全对。

没做的：报告人建议的身份键加宽（remember_order_identity）没动，那影响的是 strategy_name 归因，不是编号，可以单开。

升级

pip install --upgrade xtquant_big_convert

服务端改动，部署进 QMT 并重载后生效。实盘验证需要真实下单，建议用报告里那个串行脚本、备注不改、再跑一遍。

完整条目见 CHANGELOG。

0.3.41 — 财务下载探测分开报、双账号文档

一个新功能、一处修复、一节文档重写。

probe_capabilities 把财务下载「接口暴露」和「独立更新可用」分开报（#277 / #295）

#277 的第 2 条：download_financial_data 在 SDK 里有、能 import、调用不报 AttributeError，但真拨过去是「无法连接行情服务」——「暴露了」和「能用」是两回事，能力表原来分不开。

probe_download_channels(dial=True) 真发一次小范围下载（000001.SZ / Capital / 30 天），download_financial_data 和 download_financial_data2 共用这一次拨号。每个函数一个 verdict：update_usable / exposed_but_service_unreachable / not_exposed / exposed_untested / contextinfo_only_untested，SDK 原话保留在 sdk_call.error。已有行的读取单独放 readback_existing_rows，键名就说明读得到 ≠ 能更新。拨号绕开 600 秒失败缓存（探测量的是现在），完了再回写。params["download_probe"]=false 跳过。

模型内实盘验证（国金 2.1.19.0，策略重启后）：

readback_existing_rows   ok=true  rows=21
download_financial_data  exposed_but_service_unreachable
download_financial_data2 exposed_but_service_unreachable
sdk_call                 "无法连接行情服务！"  0.296s
probe_capabilities 整体  2.4s，16 个块齐全

#277 要的区分在同一次探测里同时看到：已有行读回 21 条，下载接口连不上服务。PR 原先标为「没验到」的 readback_existing_rows 和耗时增量，这次都补上了；update_usable 路径要 58610 在线，本机没开，仍未覆盖。

query_credit_account 信封里的 rows 补包成 CompatRow（#297）

#271 把账户这一族改成可属性访问，覆盖的是走 _query_account_list 的方法；query_credit_account（查柜台那条路，#201）直接 client.call 返回 {rows, count, fresh, stale, ...} 信封，漏掉了。信封里的行和 query_credit_detail 是同一种原生信用行，r["rows"][0].m_dAssureAsset 一边能取一边 AttributeError。信封不动，只把 rows 里每一行包成 CompatRow。

README 多账号一节重写（#296）

原文说"当前架构是单账号单实例，推荐跑多个策略实例"，那是 #171 之前的话。现在方式一是单实例双账号（BIGQMT_ACCOUNT_TYPE_MAP），按一份实际跑着的 STOCK + FUTURE 部署整理示例；写明只有这一个键是桥读的、主账号必须是策略在 QMT 里绑定的那个、交易类请求 defer 到主线程。验证状态改为已实盘验证，#171 时写的"本仓库从未实跑过"不再成立。方式二（多策略实例）保留为账号分属不同客户端时的唯一选择。

升级

pip install --upgrade xtquant_big_convert

#295 是服务端改动，部署进 QMT 后生效；#297 是客户端改动，pip 升级即可。

完整条目见 CHANGELOG。

0.3.40 — 客户端配置优先级、POSITION 缺数量字段报错

两处由 @shengyy 带离线复现报告的修复。

BigQmtRpcClient(redis_config=...) 显式传的功能开关被配置模块覆盖（#289）

构造函数开头对 host/port/password 的规则是显式参数覆盖配置模块（merged_redis_config.update(redis_config)），但三个功能段各自违背了它，每个错法不同：

段	错法
local_cache	模块段在前，显式值只当 .get 的兜底
formula_server	or 链——模块里只要有这个段，显式 dict 整个被丢，连合并都没有
full_tick	压根不读 redis_config，没有配置模块时构造开关也不起作用

报告人的复现：模块三个都说 True、构造函数三个都传 False，得到 True True True；没有模块时传 full_tick_cache_enabled=True 得到 False。

现在三个段统一走 _ClientSetting：显式 redis_config > 配置模块 > 环境变量 / 默认。formula_server 改为逐键合并，调用方没提的键保留模块的值。配置模块内部 BIGQMT_REDIS_CONFIG 平铺键与专用段的先后由 load_client_config 决定，本次不动。

客户端改动，pip 升级即可。

POSITION 行缺数量字段时被补成 0（#290）

m_nVolume / m_nCanUseVolume / m_nYesterdayVolume 原来走 int(_attr(row, names, 0) or 0)，缺属性的行序列化出来和终端明确说 0 的行逐字节相同。"不知道持多少"和"持仓为零"在 adapter 这层就混成一个了，走公开 raw RPC 也救不回来。读 0 当"空仓"的策略会重复买入，读 0 当"没有可卖"的策略永远不卖。

三个是大 QMT POSITION 结构里无条件的 int 成员（结构文档没给它们标"股票不适用"，周围期货专属字段是标了的），#81 在 6 只实盘持仓上逐行核对过。缺了就是终端自己的契约没守住。现在 adapter 抛 ValueError 点名代码、账户和字段，经 #229/#230 的路径以 ok=False, error=... 传回。原生明确的 0 仍是 0，原生空结果仍是空结果。

选报错而不是传 None：None 流到客户端 XtPosition.volume 上，官方那是 int，下游 if pos.volume: 一样当 0，静默的问题只是换了地方。

服务端改动，部署进 QMT 后生效。

升级

pip install --upgrade xtquant_big_convert

完整条目见 CHANGELOG。