订单显示 EXPIRED，是没成交，还是已经结束？

看到 EXPIRED，先查累计成交数量，不要立即把整笔重新提交。它说明原订单已经因相应规则结束，但单独这个状态不能证明从未成交，也不表示已经全部成交。状态和数量必须放在一起读。

订单已过期，还要看已经买到多少

“订单现在是否仍然有效”与“此前已经交易了多少”是两个问题。EXPIRED 回答前一个问题的一部分；累计执行数量回答后一个。若原始数量三、累计成交一、终态 EXPIRED，原订单没有两单位继续等待，但已有一单位的成交不会消失。

表中数量为教学设置，不代表所有入口都用相同翻译展示。检查真实订单时，保留原始状态、原始数量与已成交字段，不要只抄一个中文“失败”。若状态与数量看起来矛盾，先检查订单号和查询范围。

它可能很快结束，并不一定挂了很久

这里的过期，不一定意味着等得太久。

某些有效方式要求立即执行，未满足的余量会很快结束。例如允许立即部分完成的指令，可能先交易一部分，然后终止余量。另一些要求立即全部完成的指令，如果数量条件不够，可能以零成交结束。

币安官方现货状态定义把按订单类型规则结束，以及交易所原因导致的结束，列入 EXPIRED 的说明。因此不能从这个单词倒推出唯一原因。订单类型、有效方式与返回的原因信息更能帮助缩小范围。

三单位目标，为什么结束时已经有一单位

假设一张立即尝试成交并结束余量的订单，目标为三单位，当前符合条件的可用数量只有一单位。若实际结果是先完成一单位，再结束另外两单位，那么它离开开放订单列表与已经有一单位成交并不冲突。原始目标、执行结果和未来是否等待，是三个不同字段。

若只因它从列表消失就再次提交三单位，新单全部完成后，累计交易量会达到四单位。想避免这种误差，先把旧结果写成“原始三、成交一、原单终止”，再决定是否仍然要补足旧目标。目标不变时的差额是两，但是否继续交易仍需另作决定。

EXPIRED_IN_MATCH 应当单独核对

不要省略 EXPIRED_IN_MATCH 的后半部分。

这个状态涉及自成交预防机制，不能简单译成网络超时。保留完整原文，再查看同一订单关联的预防信息、交易对、时间与账户范围；有些普通界面不展示所有技术字段，需要官方支持协助解释。

反复提交不会查清这次过期的原因。保留订单号和原始提示，向官方支持查询；相关限制若仍存在，重发还可能遇到相同结果。

例如，同一账户已有卖单，又提交会与它撮合的买单，就可能涉及自成交。是否阻止，以及结束哪边的余量，要看实际 STP 模式。币安的自成交预防说明也涵盖同一交易组的账户。记录中的“预防数量”不是已成交数量，不能加到买入合计里。

网络超时之后查到 EXPIRED，该看哪个结果

请求超时描述你没有按预期收到响应；订单终态描述平台记录中委托的结果。两者可能在同一次操作中先后出现，但不是同义词。如果先看到网络提示，后来查到 EXPIRED，应该分别记录这两件事，不能用网络提示覆盖后来查到的执行数量。

如果目前只知道请求超时，还没有查到订单记录，就不能提前给它写上 EXPIRED。先寻找交易对与订单号对应的记录；必要时扩大日期筛选范围并统一时间区。结果未知是一个需要继续确认的状态，不应被随意改写为零成交。

当前委托找不到了，去订单历史查

开放列表主要显示仍然活跃的委托。

终止订单离开这里很正常。继续查订单历史与成交明细：前者帮助确认原始参数和终态，后者帮助确认实际执行。查不到时先看账户或子账户范围、交易对、时间范围和分页，而不是立刻认定数据丢失。

同一委托可能对应多条成交记录。将属于同一订单的数量合计，再与累计值核对；不要只查看最后一条明细。也不要把名称相似的另一种报价交易对混入，基础资产名称相同并不足以证明是同一市场。

和主动撤单，差别在结束原因

用户主动撤销与按照规则过期，可能都让未成交部分停止等待，但记录原因不同。主动撤单还要确认请求是否成功处理；规则过期则需要结合类型及原因字段。无论哪种终态，已经发生的成交都应单独保留。

如果你正在处理的是点击撤单之后的未知结果，可读撤单请求与最终结果。不要仅凭最终都是“没有开放余量”，就把两条不同的处理路径混成一条，这会在追查异常时丢掉重要信息。

订单号、成交数量和过期原因怎样记

记录结束原因时，留出“尚未确认”这一项。

若导出表格同时包含订单状态与一次事件的类型，也要先读列名。一个事件说明某次更新发生了什么，订单状态说明查询时整张委托处于什么阶段。不要仅因为两列都包含英文单词，就互相替代；保留字段名能帮助官方支持理解你在比较哪两项。

历史数据的日期也应保留。规则说明更新之后，可以据此重新核对解释，但不要把今天阅读文档的日期改写成过去订单的发生日期。原始记录越完整，之后越容易判断是状态理解改变，还是订单本身出现了新结果。

可以照下面的例子记下这笔订单，再将订单号补在自己的私人记录里：

现货某交易对，原始数量三，累计成交一，最终状态 EXPIRED。已检查同一订单明细，未发现继续开放的余量。结束原因待官方核对。

维护、余额不足或流动性不足，都需要另有证据才能写成原因。

随后才决定是否需要新订单。如果当前目标已改变，完全可以只保留已发生的结果。若记录彼此不一致，先保存截图与原文并通过官方支持核实。例如累计显示一单位，但找到的明细只有零点七，就把缺少的零点三及已查日期范围交给支持核对。

关于立即执行要求如何影响余量，可以对照GTC、IOC 与 FOK 的同场景比较。先确认原单采用哪一种安排，再使用相应例子解释结果。

三张订单放在一起，过期差额不算开放委托

假设同一个购买目标下有三张订单。甲原始三单位，成交一，已经过期；乙原始二单位，成交零点五，仍然开放；丙原始一单位，已经完整成交。为了让例子只涉及数量，暂时不考虑费用和其他资产变化，三张订单均使用同一个基础资产单位。

已成交合计为二点五；仍可能通过现有指令继续执行的是一点五；过期差额为两。这三列不能混成一个“还差多少”。尤其不能把甲的两单位差额和乙的一点五开放余量一起写成三点五单位待成交，因为甲的原单已经结束。

反过来也不能把乙的一点五当成已经到手的资产。它只是仍有效的委托，可能继续执行，也可能以后以其他结果终止。只有实际成交会进入已成交合计。这个表格不是完整钱包报表，而是把几张订单各自的执行与存续状态整理清楚。

第二次提交之后，怎样判断是不是重复购买

再构造一个独立例子。

第一张订单请求四单位，最终以成交一点五、过期结束。你没有查明细就又发了四单位，第二张后来完整成交。两张订单的成交合计是五点五。这里需要检查是否存在两个不同订单号，而不是看到相同交易对就把第二张当作第一张的显示副本。

如果两张确实不同，先分别保存其结果。不要删除个人记录中的第一张，也不要把第二张数量改写为“补单差额”，因为它实际请求的是四。准确记录并不改变交易结果，但能帮助你看清误差从哪一步产生，以免第三次继续按原始目标重试。

若两个界面显示的是同一订单号，情况又不同。先比较查询时间、缓存或刷新状态、筛选范围和字段含义。相同记录被两处展示不等于发生两次交易；不同订单恰好价格相同，也不等于只有一次。订单身份是区分两种情况的起点。

一条执行事件，不等于整张订单都完成

一些导出或开发工具会同时显示事件类型和当前状态。假设某个事件对应新增零点三单位成交，它只说明这次更新有多少执行，不一定说明整张订单完成。之后订单可能继续执行，也可能让剩余数量结束。把“发生了一次交易”和“完整交易目标完成”分开，才能读懂一串更新。

普通用户不需要为了排查一张订单学习所有 API 字段。

• 优先使用官方界面的订单详情和累计成交。
• 如果已有导出文件，保留列名与原始值，不要只摘出一个英文单词。
• 如果不同记录无法自行对应，把订单号与相关字段一起交给官方支持。

尤其不要把截图里的最后一条成交数量直接填进累计栏。若此前已经有零点七，本次新增零点三，累计应当结合完整记录核对为一；只保留零点三会丢掉前面的部分。这个例子只是加法关系，真实累计仍应从实际证据确认。

原因还不清楚时，怎样写才有用

“因流动性不足而过期”是一条具体归因，需要对应原因或足够记录。仅仅看到 EXPIRED，还不能自动补上前半句。更准确的初步描述是：“原单已过期，累计成交多少，具体原因尚未确认。”这样既保留已经知道的事实，也标出需要继续核对的部分。

后来确认的原因，作为后续信息补充。

如果官方说明给出了具体原因，保留获知时间。不必把早先未知的状态擦掉，好像自己从一开始就知道。分开记录查询与解释的时间，能让下一次排查知道哪些判断曾依赖不完整信息。

关于错误提示，也尽量保存原文。把多个不同词一律翻成“失败”，会丢掉可能有用的差异；但堆放许多术语又不写所属字段，也无法帮助定位。保留少量准确字段，比复制整个无关页面更便于核对。

提交下一笔之前，检查三个空格

在个人记录里留下三个空格：

1. 旧单终态：没有证据，先继续查询。
2. 旧单最终累计成交：没有证据，不要填成零。
3. 现在仍希望达到的目标：已经改变，就不必机械执行旧目标。

当三个空格都清楚时，你才能描述是否还有需要重新安排的数量。这个过程不要求预测行情，也不保证新交易适合你。原单买到一单位与买到零单位，对下一笔的数量有不同影响；先把这个差别查清。

如果需要把问题转交他人协助，使用已经隐去个人信息的记录副本，原始材料留在自己掌握的位置。核对订单不需要公开身份材料，也不需要让对方替你登录账户；能够复查的字段与时间，才是说明问题所需的内容。