Alchemy NFT 查询费与 429 怎么算：分开消费 CU、吞吐和重试预算
链小知 · 进阶 · 核验 · 依官方文档整理
用官方NFT方法表对已有调用计划做算术核对，避免把10吞吐CU当消费单价或把排队刷新当完成。
开始前准备
- 准备已有脱敏请求日志或离线调用计划：方法名、网络、时间、HTTP/body错误、请求数量、当前账户吞吐与用量配额；没有配额时保留变量。
- 按2026-10-12公开NFT方法成本与吞吐说明，不发API请求、不跑429测试、不访问账户账单。CU是服务计量，不是NFT市场价格或链上Gas。
1. 先核对方法仍在当前产品范围
将计划里的方法名与当前NFT目录及8月18公告比较，getNFTMetadata、refreshNftMetadata在当前目录；getNFTSales、computeRarity、invalidateContract等列入9月30退役计划。
CU表仍保留部分被公告列出的条目，不能以“有价格”证明端点当前可调用。旧方法计划先标迁移待核，不自动换成另一API并假定同字段、同费用；本页只预算明确核对的两个方法。
检查结果：预算限定当前文档列出的具体方法，旧计划未混入可用调用量。
2. 给每个方法建立两列 CU
从NFT表摘录getNFTMetadata：消费80CU、吞吐10CU；refreshNftMetadata：消费40CU、吞吐10CU。第一列累计用量，第二列用于速率；不能因吞吐10就把一次Metadata的消耗写成10CU。
示例计划100次Metadata和20次Refresh，消费为100×80+20×40=8800CU，吞吐权重总和为120×10=1200；后者没有时间分布就不能推是否限流。这里是离线算术，不是账单回执。
检查结果：两列算式、数量和计量目的明确，没有CU到货币或Gas的未经证实换算。
3. 用账户总流量和十秒窗口检查速率
当前Throughput页写账户级，所有apps合并，用10秒滚动token bucket及严格补充速率；不要用另一个app分流当绕开账户限额。若已知限额L CU/s，只有这类10吞吐CU方法时，L÷10是理论持续请求/s。
例如文档300CU/s示例是10秒3000权重，除10得到30请求/s的理论上限，不保证每个突发或混合方法都成功。Compute Units页仍写app专用/弹性可超，和当前Throughput表述不同；本文按后者作预算并保留差异。
检查结果：配额有单位和来源，混合方法/其他apps的权重已计入或明确未知。
4. 错误计费与元数据源站错误分开
成本表将429/403记0消费CU，其他4xx/5xx按具体端点CU；离线预算保留失败请求，不能笼统说“失败都免费”。没有实际账户明细时，只称表规则，实际用量待核。
HTTP429是吞吐页的HTTP分支；不要把NFT raw.error里源站429自动套进这个零CU规则，也不要将403的0CU解释为取得数据。HTTP状态、原body和服务/源站层级一起保存。
检查结果：错误是否消费CU有明确规则与未知边界，零计费未被当成功数据。
5. 制定有上限的重试计划
已有HTTP429若带Retry-After，整数单位秒；没有时可设计指数退避并设置最大等待和最大次数，不能无上限并发重试。该计划先离线审阅，避免把文档里的httpstat.us测试地址当本任务必做验收。
所有真正重发的调用都要纳入请求次数和成功/其他失败的CU预算；429不消耗消费CU不等于无需等待、可无限请求。403保持原权限原因待核，不按吞吐退避推一定能恢复。
检查结果：重试时间单位、上限和累计调用量可计算，未执行请求或宣称恢复成功。
6. 把预算结果与刷新完成条件一并交付
输出方法、成功/错误次数、预计消费CU、时间窗吞吐权重、账户限额来源及未知配额。CU到金额还需当前方案/账单规则，不凭免费示例300CU/s保证本人资格或价格。
若计划含Refresh，Queued和estimatedMsToRefresh只是队列状态/预计毫秒时间；消费预算不代表NFT已刷新。完成需要以后取得的同资产更新记录与实际用量核对；目前只交付文档规则和离线预算。
检查结果：预算、权限、数据完成与计费验收是四项独立状态。
怎样确认完成
- 对既有日志或计划形成可复算的两列CU、时间窗与有限重试预算，未知账户限额/价格保持未知。
- 只完成官方资料与算术核对，没有认证请求、消费回执、429恢复或刷新验收。
常见错误与边界
- CU表包含旧方法；计费条目不证明现行服务可用。
- 吞吐按账户全部应用合计，持续理论速率不能保证瞬时请求成功。
- raw.error源站429不能自动当Alchemy HTTP429免费；没有账单不称费用验收。