miniQMT行情能正常获取，下单却失败，说明行情链路和交易链路并不是同一个状态。XtData负责行情，XtTrader负责账户和交易。前者能读取K线或实时价格，只能证明行情模块正常，不能证明交易账户已经登录、订阅和具备委托权限。

排查第一步是账户连接。XtQuantTrader创建后要先start，再调用connect。connect返回成功，只代表程序与客户端建立通信，还要对StockAccount执行subscribe，并检查订阅结果。账户没有订阅成功时，回调和部分交易功能可能无法正常工作。

第二步确认客户端登录。miniQMT必须先启动，交易模块要登录正确资金账号。程序中的userdata_mini路径应指向正在运行的客户端。电脑里若有多个安装目录，行情可能连接一个数据环境，交易程序却指向另一个目录，表现就会很混乱。

第三步查询账户状态和资产。下单前先调用账户状态、资金和持仓查询。若这些数据都为空，不应继续测试委托；若资产正常，说明账户链路基本可用，再检查具体下单参数。

第四步看证券代码。代码应包含正确市场后缀，股票、基金、可转债和其他品种的格式可能不同。行情接口有时对错误代码返回空数据，交易接口则可能直接拒绝。最好从合约信息或客户端复制标准代码。

第五步检查买卖类型和账户类型。普通股票账户、信用账户和其他账户使用的交易常量不同。用普通股票买入类型向不匹配账户报单，或StockAccount类型写错，都可能失败。程序不能只改资金账号，而忽略账户类别。

第六步检查数量和价格。买入数量应满足交易单位，可用资金要足够；卖出数量不能超过可用持仓。限价单还要符合价格精度和市场规则。某些品种价格保留位数不同，直接使用未处理的小数可能造成废单。

第七步确认交易时间和证券状态。非交易时段、停牌、涨跌停限制或账户没有对应品种权限，都可能导致委托失败。行情能显示停牌股票的历史价格，并不代表当前可以交易。

第八步查看返回值和错误回调。下单返回负数时，应停止重试并记录参数；返回订单编号时，还要继续观察on_stock_order和on_order_error。废单原因通常能直接指出是价格、数量、权限还是其他问题。

第九步检查是否存在未完成订单。程序为了防止重复报单，可能在waiting_list或其他状态中主动阻止新订单。日志只显示“下单失败”，实际可能是策略自己提前return。应在每个拦截条件前打印明确原因。

第十步核对普通客户端。在相同时间、相同账户下，普通客户端能否手工提交同类订单，可以帮助分流问题。若手工也失败，更可能是账户或市场规则；若手工正常而接口失败，则重点检查参数、账户类型和接口权限。

排查过程中不要不断修改多项参数。可以先在模拟环境中使用一个常见标的、合法数量和明确限价，完成最小订单测试。成功后再换成策略真实参数。每次只改变一个变量，才能知道问题在哪里。

交易失败还可能来自程序自己的风控。例如单笔金额上限、当日次数限制、持仓比例或等待订单规则主动阻止下单。排查时应区分“接口返回失败”和“策略没有调用接口”。在真正调用前后分别记录日志，才能知道请求是否送出。

若错误回调给出明确原因，应优先按原因处理，不要通过更换价格类型或反复重试碰运气。每次失败都保留参数和账户状态，能快速建立自己的故障知识库。

排查完参数后，还要验证账户是否具备目标品种权限。程序能读取某只证券行情，并不代表账户允许交易该品种。若普通客户端中也无法手工委托，应先处理账户业务权限，而不是继续修改Python。量化接口不会绕过账户适当性和市场规则。

行情正常不代表交易链路正常，账户、权限、参数和市场规则都需要单独验证。若当前正卡在“能看不能下”的阶段，可以按本文顺序整理日志，再结合主页后续内容继续排查。本文仅用于接口学习和风险教育。