通过扫描totalSupply发现列表 (Totalsupply)

如果没有索引器，则每次刷新都是链式扫描

Bare Crypto 市场客户端使用 totalSupply() + tokenId 循环查找开放列表，而不是使用事件索引或子图。每一步都会进行其他调用，例如 wasNftSold、isListingOpenByTokenId 和 getLastListingByTokenId。随着供应量的增加，成本呈线性增长——事实上，情况更糟；储备容器每约 30 秒重复一次此操作。```text getListings(sold=false) maxToken ← NFT.totalSupply() for tokenId = maxToken … 1: wasSold? open? isListing? → maybe getListingInfo(tokenId) ↓ N tokens × M RPC calls / poll poll every ~30s (Reserve / Profile) ↓ Infura rate-limit → empty / stale grid

## 第一次提到的概念```text
📦 totalSupply Taraması
Listing kümesini, arz üst sınırından geriye tokenId döngüsüyle keşfetmek.

📦 N×RPC
Her token için birden fazla eth_call; poll ile çarpılınca kota tüketimi.

📦 Stale Listing
Satılmış veya iptal edilmiş ilanın UI'da hâlâ açık görünmesi; poll gecikmesi veya kısmi hata.

📦 Infura Rate Limit
Projeye bağlı istek kotası; aşılınca çağrılar başarısız olur veya yavaşlar.
```在小型 Rinkeby 集合上运行的循环不是主网规模的产品功能。

## 算法真相

`getListings` 首先读取 `getTokenSupply()` 到 `totalSupply`，然后从 `maxToken` 下降到 1。对于每个代币，都有出售/打开/上市检查，如有必要，还有 `getListingInfo`。即使是空的令牌范围也会燃烧 RPC。```text
Cost model (approx)
  cost ≈ totalSupply × calls_per_token × polls_per_minute
  UI cards may add metadata/IPFS reads on top
```## 30 秒的民意调查和陈旧的 UI

在保留容器挂载上运行 `getListings` 并迭代 `setInterval(..., 30000)`。与个人资料类似，它会在大约 30 秒内扫描所有物品；查看器和卡片使用 10-15 秒的间隔。当用户看到购买时，网格可能会因投票而保持陈旧状态，或者由于速率限制而为空。

## Infura 故障模式

整个扫描都会发送到读取节点 (Rinkeby Infura HTTP/WSS)。当达到配额时，部分 try/catch 路径可能会返回 `wasSold=false` 或空字符串；网格悄然变得虚假。将密钥埋在存储库中会加剧问题——项目 ID 从未写在文档中； env + 路由限制是 ADR 的一部分。```text
ADR: Listing discovery
  Accepted (prototype): scan totalSupply client-side
  Rejected (then): subgraph / event indexer
  Consequence: rate limits, stale polls, O(supply) cost
  Follow-up: index Transfer/Listing events; paginate
```## OpenSea 差异

OpenSea 客户端不会扫描每个访问者浏览器的全部内容；有索引+API。 Bare Crypto 复制 IA 中的产品参考，而不是发现基础设施——这是一个有意的（或至少是事后看来）的权衡。

## 本期最令人困惑的对决```text
❌ totalSupply taraması = üretim keşif stratejisi
✓ Prototip; indexer yokluğunun semptomu

❌ 30s poll gerçek zamanlı piyasadır
✓ Poll, stale listing ve kota riskidir

❌ try/catch ile yutulan RPC hatası = güvenli UI
✓ Sessiz yanlış listing daha tehlikelidir

❌ Infura anahtarını client bundle'a gömmek pratiktir
✓ Sızıntı + ortak kota; env ve proxy düşünün

您自己的系统清单

1. getListings 轮中每个代币有多少 eth_calls？
2. 当供应量增加 10 倍时，每次投票的成本是多少？
3. 发生速率限制时，UI 会陷入什么空/不正确状态？
4. 购买后烤架可以保持多少秒不新鲜？
5. 哪些事件被索引并且消除了扫描？

本节中需要记住的事情

1、Listing发现是totalSupply扫描；它不是 OpenSea 索引。 2. N×RPC × 30s 的投票使得 Infura 配额和陈旧的 UI 不可避免。 3. ADR：原型接受、索引器跟踪——不会悄无声息地扩展。

询问每个 tokenId，而不是市场；这是一个负载测试。