429 表示请求触发限速。保留响应中的等待信息并暂停相关重试；同一出口上的其他任务也需要协调。
收到 429，还要不要再点刷新？
不要。同步卡住时，刷新按钮最招人连点。已经收到 429，就先把自动重试和手动触发都停下，记下出错时间，看响应里有没有 Retry-After。
平台当前的阈值不用你去猜。托管工具的界面如果只剩一个转圈图标，直接问提供方两件事：请求停了没有，下一次什么时候发。
工具这一侧，等待提示要回答三个问题：系统是在等，还是已经停了；屏幕上的旧数据是什么时候的；用户现在要不要做什么。给不出可靠的恢复时间，就别挂一个凭空算出来的秒表，照这样写即可：“同步已暂停，当前显示的是上次成功获取的数据；系统会按服务返回的等待时间自动恢复。”
该等多久？429 和其他报错怎么分开处理？
等多久，看这一次的响应。Binance REST 文档写明：429 或 418 响应里的 Retry-After 是需要等待的秒数。这个值每次可能不同，上一次看到的数字、网页教程里的示例，都不能当成你这次的倒计时。工具界面上看不到它，就向维护者要一份脱敏的状态记录，完整的账户请求不用交出去。
时间错误、签名错误、读取权限不足，各有各的原因要修，延迟重试修不好它们；网络中断和服务端错误又是另一类。本页只讲读取与连接任务，交易请求的自动重放不在范围内。
所有失败都记成一个“API 错误”计数，下一步该等、该改配置还是该找支持，就分不出来了。日志里把 HTTP 状态和接口错误类别分开记：限速就按等待信息暂停；时间、签名、权限问题去改对应的配置；网络中断或服务端错误，先查连通性，再找支持。
我很少刷新，为什么也会被限速？
云端工具里，很多用户和后台作业可能共用一个出口。你几分钟才点一次同步，也可能正好撞上别的任务集中发请求。
官方的 REST 请求权重有一部分按 IP 统计，同一个工具换一把密钥，通常解决不了出口上的压力。该问运营方的是：撞上的是哪一类限制，哪一批任务在花额度？
要降频，先把所有会触发读取的入口列出来：页面打开、手动刷新、定时任务、历史补齐、健康检查、重新连接。每一项写上由谁启动、访问哪类接口、能不能合并、失败后会不会重试。最容易漏的是健康检查，页面上没人操作，后台可能一直在探测。
算成本要看接口权重，光数次数不够。两次读取各发一次，消耗的额度可能差很多，适用的限制以当前接口文档和响应信息为准。一张图表背后要调三四个查询，就把这些后台调用都算进这项任务的成本。
历史导入失败了，要从第一段重来吗？
首次连接要补历史记录，适合放进受控队列分段完成；日常更新只取新的范围，能复用的结果就复用。两类任务用同一个高频节奏刷新，历史导入会和正常看板抢额度，所以预算按实际接口成本分开定。
举个例子：一个任务要分十段读取历史，前四段成功，第五段撞上限速。程序保存了最后一次成功的位置，等待结束后从第五段继续；没保存，就每次都从第一段重来，越重来越容易再撞限速。所以先查任务有没有保存进度，调大重试次数排在后面。断点怎么取要看接口的数据模型，重复、重叠、缺失三种情况都要处理。
复用结果能省请求，前提是页面标明数据是什么时候采集的，停止更新时也照实提示。几个页面用同一份账户摘要，可以共享一份已授权的结果；跨用户混用私人数据来省请求，不行。真要开缓存，先定好缓存键怎么算、谁能看到、多久过期。
重试由谁负责？暂停状态怎么传到每个入口？
浏览器、应用服务、任务队列、网络库，可能各带一套重试。每层都觉得自己“只试了三次”，叠起来就是几十次重复请求。先定下由哪一层负责下一次尝试，其他层只接收暂停状态；恢复时把任务的启动时间错开，再给总尝试次数和停止条件各定一个上限。
后台已经决定等待，浏览器新开的标签页也得知道，否则每个页面都可能各自再起一个任务。等待状态是只存在某个进程里，还是同一服务的其他入口都能读到，要看实现。
验收用本地模拟响应就行，不必去真实平台上故意高频触发限速：等待期间再打开同一个页面，看它会不会又发出一组请求。
自己在同一台服务器上部署了几个工具，就把它们的同步计划摆在一起排，单个工具只知道自己的任务。用的是不同公司的托管服务，两边同时失败也不能直接认定是共享出口，得各自拿证据；普通用户记下两边是否同一时间出问题就够了，网络和请求类别交给维护者去查。
等待结束后，怎样恢复才不会马上又被限速？
等待时间到了，先发一次必要的读取确认状态，再逐步放开后台任务。看的是数据新鲜度、待处理数量和限速类别，页面能打开不算数。
刚恢复又撞上同一类限制，就停下循环，重新算共享出口的预算。官方文档提示，持续违反限速可能升级为 IP 封禁（418）。我们的看法是：宁可让看板先停在旧数据上，也别去换出口地址或轮换密钥硬绕。
排队期间，用户可能已经关掉页面，或者后来一次完整同步已经覆盖了前面的需求，恢复时把旧任务挨个执行一遍，很多都是白做。会改变账户状态的操作不走这条路；能合并或取消的只读任务，就合并、取消，并在界面上说明取消的原因。
调度改完之后，用少量必要读取、按正常业务节奏去验证，别开一排浏览器窗口一起刷。盯住限制有没有再出现、数据能不能正常更新、积压是不是在有序减少。日常轮询恢复了，历史导入未必也好了；问题只出在初次导入时，就单独在受控条件下跑一遍导入路径。
被限速时，用户该记什么？什么时候要找维护者？
作为用户，记下这些就够，收集它们不需要再多发任何请求：
- 最后一次成功同步的时间，第一次失败的时间；
- 出错后手动点了几次刷新；
- 当时是否在做历史导入；
- 同一工具的其他页面是不是也停了。
维护者那边，把等待起止、任务标识、接口类别和最终的恢复决定写进脱敏日志。
等待信息解释不通、一恢复就再次出现、不同节点表现明显不一样、工具一直不给错误类别，碰上任何一种，就停掉重试，找维护者。交给对方能定位的时间段和任务状态，账户历史不用全给。对方回复“已经优化”时，追问具体改了什么、凭什么判断可以恢复。
工具升级或规则变了，要重查哪些地方？
工具升级后多了账户摘要、图表或自动刷新入口，原来的预算就得重算。把接口文档核对、请求来源清单、等待状态处理写进维护记录；官方规则变了，改对应的成本和调度逻辑，旧教程里的数值别照搬。每次故障也留一条记录：原因、改了什么、之后观察到什么，并在暂停逻辑旁边注明它防的是哪一次故障。
测新版本时，模拟的 429 用来验证界面暂停、任务取消和恢复分支，测不出真实平台当前的额度和等待时间；真实故障日志能说明当时收到了什么，却证明不了每个客户端都处理对了。两类证据分开存：一份记应用怎样响应模拟状态，一份记真实运行时看到了什么。