股票模拟账户有信号却没成交：检查规则、现金和成交条件
股票规则生成事件，不代表一定产生虚拟成交。账户可能已经持有目标股票、现金不足、没有可用报价，或仍在等待确认。应沿事件经过的关口定位原因，而不是看到零交易就认定规则失败或根本没运行。不同去向必须保留不同含义，才能知道需要补数据、改资金假设还是追查执行。
本指南对固定 A/B 美元篮子中的九个合成事件分别给出明确结论，不调用模型、不观察真实会话，也不联系券商。状态账是外部诊断方法，不证明 CoTrading 或参考影子模块已经暴露全部状态，更不代表已经持续处理真实账户事件。所有报价、费用和确认都是自设输入。
先确认事件是否被观察
明确的 no_signal 应表示机会已经评价，但没有买卖意图。它不同于机会行缺失、进程中断或特征未知。夹具以 side=None 表示已知无意图，不能仅因某天没有交易行，就自动补成这种结果。观察是否完成、条件是否成立、是否产生执行是三个连续但不同的问题。
真实交接应有稳定事件身份、冻结规则版本、篮子引用与观察边界。样例直接提供字段，使用唯一 E1 至 E9 身份，是状态分类演示，不是通用自然语言规则解析、完整调度器或市场日历适配器。上游证据不可得时，应先保持未知，不能凭账户末状态推断某个历史分支一定发生过。
诊断的关键是最后哪一层转移有证据。若已知规则评价过，但不知是否成交，应保留等待确认；若连评价都不知，直接标成执行拒绝会夸大证据。每种状态都应指向对应输入或回执，而不是从空图表编出理由。没有日志记录本身只说明证据缺口，不等于没有信号。
冻结诊断关口顺序
夹具先检查明确无意图、篮子范围、报价可用，再检查已有持仓、可卖股数、现金、待确认、市场拒绝及确认虚拟成交。按声明顺序为每个输入事件产生一个终态。某行也许有其他潜在问题，但主状态是第一个实际到达的关口，读者不应把它误解成所有可能原因的完整清单。
政策故意很窄：买入只在尚未持仓时建立仓位，不允许追加；卖出要求现有数量足够。报价缺失用 None，明确提供的非有限或非正价格则是无效输入，会报错，不把它当作条件未触发。真实系统若采用目标权重或允许加仓，需要另外定义状态，不应静默继承本例限制。
Python Decimal 文档支持有限数检查及十进制运算。每次提交成交收取合成费用一单位，金额表示不能证明任何市场的手数、结算、价格限制、税项或流动性机制。增加这些状态前，应先核实执行来源能实际观察哪些字段，不能仅凭想象列完整券商拒绝原因。
区分范围、数据与账户原因
篮子外请求标 outside_basket，不是规则拒绝；已覆盖但缺必要报价标 quote_unknown。两者都不证明人错过了一笔有效交易，因为流程尚未到能够按提供价格评价有资金执行的阶段。不能复制未来报价越过关口，也不能拿一笔别的股票成交补出当前股票的行情。
already_positioned 表示规则不允许已有持仓后继续买入；insufficient_cash 表示数量乘价加费用超过可用现金；insufficient_shares 对应卖出库存不足。它们与 no_signal 不同，事件确实带有意图，只是账户当前状态阻止了拟议转移。区分后才能解释为何同一规则在不同账户状态下产生不同执行结果。
关口顺序影响解释。例如资金不足但输入同时标待确认的请求，当前先归资金不足，因为可行性检查在确认前。另一设计可保留多个原因字段，但仍需说明主状态。本例不枚举所有同时存在的问题，也不是跨市场统一拒绝分类标准。交付时应保留优先级，让后续汇总能够按同一政策重建。
提交与确认不能混为一谈
pending 映射 fill_unconfirmed，blocked 映射 market_rejected，都不改变现金股数。后者是注入的合成执行结果，不能推断真实交易所停牌或拒绝该证券。只有 filled 分支提交资金可行的虚拟成交，这个词也只属于本地模拟，不是券商权威记录。真实确认与本地模拟不一致时需要另作勾稽。
SEC 费用说明建议检查账户与成交确认以核实成本。真实账户应取得执行证据，不能把已提交委托视为已成交。本文用虚构确认和费用，只展示虚拟账接收不同已声明结果后该如何反应，没有替代任何交易系统的回执。
按当前费用政策，未成交事件不扣费用。真实存在委托相关收费时，需要独立现金事件契约。同样不能在提交卖单时立即释放卖款，再用它资助另一请求。执行不确定性与可用现金是不同字段，只有提交成功的账务转移才改变后续资金条件，不能用后来的确认倒改当时购买力。
逐条看九个事件
初始现金 250、零股。E1 明确无意图，E2 请求篮子外 C，E3 缺 A 报价，E4 请求按 100 买五股加费用一，E5 等待一股买入确认。对应 no_signal、outside_basket、quote_unknown、insufficient_cash、fill_unconfirmed，前五行现金均为 250，持股字典均为空。
E6 得到按 100 买一股 A、费用一的可行确认，现金变为 149，A 为一股。E7 再买 A，被不追加政策标为 already_positioned。E8 试图按 105 卖一股，却得到 blocked，因此是 market_rejected。两行都保留现金 149、一股 A，不能因为已经请求卖出就先把股数清零。
E9 确认按 105 卖出，费用一，现金增加 104 至 253，A 回到零。九个事件终态中只有两次提交成交。三单位账户增长只来自这组合成价格和两次费用，不是历史业绩、未来预期，也不证明由赢家总结的规则有效。没有账户外流，不能将资产变化混成新增投入。
独立验证守恒与未执行
每个非成交状态都断言现金和持股字典与前状态一致。成功成交则按同一执行价计算前后资产，差额只能是费用。这样将记账与价格变动分开，也防止待确认事件先改变库存，再靠之后卖出凑出看似正确的最终余额。只检查终点会漏掉中间错用资金和股数。
不同机制反例中，E4 是没有持仓时资金不足，E7 是现金可买一股但已持仓，E8 是库存存在却确认受阻。额外输入检查拒绝重复身份与 NaN 报价，它们是输入错误，不加入九行正常业务汇总。错误数据不应为了让状态总数漂亮，被强行归入某个有效的无成交原因。
统计时可分别显示全部事件数、产生意图数、通过账户关口数与确认成交数，且每个分母能回到原行。当前例子只断言九条终态与两次成交，没有声称覆盖全部真实流程。若缺少一条源事件，应先解释覆盖缺口，而不是调整分类，使汇总看起来仍然闭合；计数闭合与观察完整是两项不同验收。
运行并更新诊断账
下载完整示例，保存 R644.py，使用 Python 3.12 或更新版本执行 python R644.py。只使用标准库与合成数据，断言核对九个顺序状态、全部非成交资产不变、成交费用守恒、末现金 253、A 为零及九个唯一事件计数勾稽，没有真实市场或账户连接。
交付状态账、关口顺序、原确认输入与最后可信账户状态。错误输入应通过有记录的重放修正，保留先前分类。不能因为之后进程恢复，就把过去未确认事件改成已成交。幂等恢复、部分成交及持久调度需要当前循环之外的机制，单次本地成功不能推称长时间自动处理也可靠。
遇到新状态时应先保留未知及原字段，再核实其含义。若外部来源只说拒绝，没有更细原因，报告也只到可观察的拒绝层，不补写停牌、资金冻结或风控限制。明确证据边界比给每条事件编一个听起来完整的解释更便于修复，也能防止后续汇总把猜测当成来源事实。
已有持仓这一原因还依赖规则本身是否允许加仓。若将来改为允许追加，原 E7 结论也不能直接套用，应以新规则版本从可信初态重新推进，连带重算后续现金和退出数量。只删除旧原因标签而保留旧账户路径，会产生一份状态与资产互不对应的诊断报告。
常见问题
待确认是数量为零的成功成交吗？
不是。它是尚未解决的执行结果，本例不改变现金股数。
市场拒绝是否说明真实交易所的具体原因？
不能。夹具注入 blocked 结果，真实原因需要实际执行来源的可观察证据。