币安下单后出现超时，先查原订单，别把同样的数量再提交一次。超时只说明回复没有按时到达，订单仍可能已经被接受。原请求可能没有到达，也可能已经成交但回复没有回来；这两种结果需要不同的下一步。
页面超时了，订单仍可能成交
发出请求、平台处理、结果返回，是三个阶段。
网络在任一阶段出问题，你看到的界面都可能像是没有成功。但界面的等待圈无法告诉你后台停在哪一段。反复点提交并不会补回第一条反馈，只可能再发出新的指令。
币安现货 REST API 的通用说明明确把某类超时的执行结果标为未知，并要求查询状态。它的 API 处理时限不等于网页或 App 必须等待的秒数。对普通用户有用的原则是“核对结果再决定”，而不是拿开发文档中的时间数字给手机倒计时。
若平台明确返回参数错误，且你能核实没有创建订单，才进入修正参数的路径。超时、连接中断和空白响应并不具有同样的确定性。错误文字尽量保留原文，别只凭红色图标统称失败；不同错误的下一步不该被一个颜色决定。
先留下能找到原请求的线索
记下交易对、买卖方向、订单类型、输入数量、限价以及提交的大致时间和时区。如果界面返回了订单号，一并保存。不要在不知道结果时修改笔记中的原始数量；以后补单的目标数量与第一次实际发出的数量是两回事。把它们混成一个数字，会让核对失去起点。
截图保留错误原文、交易对、数量和时间即可。发给支持前，遮掉无关持仓和账户标识；密码、验证码、验证器二维码不要放进截图。
没有订单号，也先保留现有线索。
时间相近、交易对相同和数量相似的记录，可能来自此前另一笔订单；不能只凭这些相似之处就认定是同一张单。若连续点击过几次，应该如实记下点击次数，不要只保存自己希望成功的那一次。
查当前委托，也查历史与实际执行
重新打开官方现货订单页面，确认交易对和筛选日期。先查看当前委托，再看订单历史与成交明细。只查当前委托会漏掉已经完全成交或已结束的单；只看成交明细又可能漏掉尚未执行的挂单。三个入口合起来，才能区分等待、已成交和已经终止。
| 找到的结果 | 能够确认什么 | 下一步 |
|---|---|---|
| 原单仍开放 | 还有继续执行的可能 | 管理原单，避免完整重复提交 |
| 原单完全成交 | 已经产生交易 | 核对数量和结果 |
| 原单终止但部分成交 | 余量结束，已成交仍有效 | 计算已完成的目标 |
| 暂时找不到可信记录 | 订单结果仍未查明 | 继续查询或联系官方支持 |
别跳过表格最后一行。
空白列表也可能来自筛选条件、查询延迟或看错产品入口，所以“现在没找到”与“确定没有接受”不是一回事。若查询本身也在报错，不能用第二次失败的查询证明第一次下单没有成功。
使用 API 的开发者应按官方规则关联订单号或客户端订单标识，并查询状态；本文不提供自动重试脚本。普通用户不需要为了查一张订单创建 API 密钥，更不需要把密钥交给第三方排错工具。能在官方界面找到的记录，先在那里核对。
确认原结果后，重新计算需求
假设原目标买四单位，第一条请求超时后实际成交一点五，余下二点五仍挂着。如果你此时再买四单位，可能同时保留两张继续执行的指令。新单不是“替代”原单，除非原单已经按规则结束，而且这个结果得到确认。
再假设后来确认原单余量已经撤销，累计成交一点五。在你仍然希望达到最初四单位目标的前提下，尚未完成的数量才是二点五。但你也可以重新考虑是否继续，不需要因为最初点过提交就必须追到四单位。价格、预算和意愿都可能已发生变化。
确认需要新单后，还得重新核对参数。
当前价格、参数限制和可用余额都要再看。先前输入通过过检查，不代表现在仍然有效。相反，如果最终确认第一条请求从未创建订单，恢复操作也应从完整核对开始，而不是把按钮当成无限次重发开关。
无法判断时，给支持一份短时间线
时间线写观察，不写未经确认的结论。
- “点击提交四单位”：说明你做了什么。
- “页面出现超时”：说明你收到了什么。
- “查询发现订单号某某、累计成交一点五”：提供一个观察到的订单状态。
把前两行直接翻译成“失败”，就会在最需要核对的地方跳过事实。
同一张超时画面，可能通向三种调查结果：
- 后来查到原订单四单位全部成交。
- 查到一点五已成交、二点五仍开放。
- 经可靠核对确认原请求没有创建订单。
三种场景的开始看起来相同，重新提交四单位的后果却不同。不能仅靠那张画面决定新单数量。
向支持提交时，可以把请求写成一个明确问题：“请协助确认这次提交是否创建订单，以及对应的最终累计执行数量。”如果问题已经变成“这笔部分成交为何如此”，就换成执行明细核对；如果是在确认撤单，就指明撤单请求。不同问题各有需要的记录，不必每次都发送整份账户历史。
若有人私信说能“清除卡单”，不要把密码或实时验证码交给对方。查询需要的是时间、订单号、交易对和错误信息；身份核验应在已确认的官方流程中完成。
一条给客服的说明可以这样写：
某时某分提交某交易对买单，数量四，收到超时。随后查询当前委托无结果；某时某分，历史中出现一笔疑似记录，订单号如下。目前还不能确认是否同一单，请协助核对。
如果期间发过撤单请求，也在时间线上单独记一行。撤单同样需要确认，不应被当作下单超时之后天然成功的保险。原单的最终累计执行数量，才是计算重复风险的重要依据。客服沟通中如果出现新的订单号或状态，回到原笔记更新对应项，别把不同请求串成一张单。
连续点了几次，怎样查有没有重复下单
如果第一次点击之后你又点了两次，应该按找到的不同订单号分别建行。两张单价格和数量一样，也不能把它们当成同一个编号的重复显示。你的原意是只买一次，说明目标是什么；平台实际存在几张指令，则由记录说明。核对时不能为了符合原意而删掉一张不希望出现的真实订单。
若目前只找到一张订单，也别马上推断其他点击都没有被接受。要结合响应、后续查询和官方确认逐个解释。如果确实无法区分哪次点击对应哪条记录，可以把关联关系标为不确定。先保存客观的编号与数量，比在证据不足时硬分配点击顺序更有价值。
余额只能辅助核对。可用余额减少，可能是挂单占用了资金，也可能与成交或其他账户活动有关。先找到对应订单和成交明细，再判断这四单位究竟买到了多少。
最终更新笔记时，可以保留一列“原目标”，另一列“全部已确认成交”。二者之差能帮助理解还有多少没有完成，但它不自动授权你继续买入。再查看是否仍有开放委托，并重新判断自己的需求。即使差额为正，只要还有一张可能继续执行的单，就不能把这部分当成毫无其他影响的新需求。
查到重复订单，先逐张看状态和余量。
已经完成的交易和仍可撤销的指令要分开，不用一笔反向交易把它们笼统“抵消”。反向交易会新增价格结果，可能也有新的执行问题。需要做什么取决于你的真实目标，本文只帮助把现有状态查清。
假如查到两张不同编号的买单，A 已成交 1.5，余量已撤；B 已成交 1，另有 3 仍挂着，那么已经买入 2.5，仍可能再买入 3。即使你最初只想买 4，也不能只算 4 − 2.5 就再补 1.5；还要先处理 B 的挂单余量。
刷新页面或关闭 App，会不会停止订单
不会。刷新或重开 App 可以重新查询，但已经被接受的挂单仍可能成交。等待圈一直转也不能说明订单还没成交。需要停止未成交部分时，要找到原单并请求撤销，再确认撤单结果。
客服还在核查，多久以后可以重试
如果官方支持答复仍在核查，不要自行认定拒单。保存对话参考信息和最新确认状态，等出现新的可靠结果后再更新原表。本文不设置一个“超过若干分钟就可以直接重试”的门槛，因为经过时间并不自动构成失败证据。
查询恢复之后，先确认新显示的记录属于同一个编号，再看更新时间与累计成交。一个新出现的已完成订单可能是原请求，也可能是你之前重复提交的另一条指令。只比较数量四这个数字不够，完整关联仍然需要订单身份。若编号无法取得，就说明你用了哪些较弱线索以及仍有什么疑问。
经过多久，不能独自证明订单失败。
本页没有一个适用于所有故障的等待分钟数。系统公告、官方查询与支持反馈比自设倒计时更能说明状态。故障期间减少新增指令，有助于维持一份能查清的订单账；这不保证价格不变，也不保证能获得原先设想的成交机会。
理解了超时为什么不能直接重试，再看同一订单怎样关联成交记录，把查询结果落到数量上。若原单已经进入撤单阶段，可结合撤单确认说明继续核对，避免把两种尚未确认的请求互相抵消。