Bootstrap仅用于构建美观响应式界面，需通过API获取链上数据；搜索框须用正则识别哈希、区块高度、ENS或地址；金额转ETH/GWEI并标注单位；状态映射为Success/Reverted；摘要接口分页加载；表格加table-responsive和sticky关键列；时间戳统一转本地时区。
Bootstrap 本身不提供区块链相关功能，它只是前端 UI 框架。你要做的不是“用 Bootstrap 制作区块链浏览器”，而是用 Bootstrap 快速搭建一个**美观、响应式、易维护的查询界面**，再通过 API（比如 ethers.js、web3.js 或第三方服务如 Etherscan/Blockchair 的 REST 接口）获取链上数据。
真正关键的是：界面怎么组织才符合用户查区块、交易、地址的习惯？哪些交互必须做对，否则会误导用户？
区块/交易/地址搜索框要支持多类型自动识别
用户粘贴一串字符，你不能只当它是地址——它可能是哈希（66 字符带 0x）、区块高度（纯数字）、甚至 ENS 名（如 vitalik.eth）。硬编码成单一输入类型会频繁报错。
- 在提交前用正则快速分类：
/^0x[a-fA-F0-9]{64}$/→ 交易/区块哈希；/^\d+$/→ 区块高度；/^[a-z0-9.-]+\.[a-z]{2,}$/→ ENS；其余默认当地址处理 - 别直接发请求。先显示 loading 状态，并禁用搜索按钮，避免重复提交
- 错误提示要具体：不是 “查询失败”，而是 “
0xabc...def不是有效交易哈希” 或 “未找到区块高度99999999”
用 Bootstrap 的 card 和 table 呈现链上数据时注意字段语义
区块链数据字段命名和单位容易混淆（比如 gasUsed 是数值，gasPrice 是 wei，value 是 wei 但常需转 ETH）。前端渲染时若直接塞进 table，用户看不懂。
- 地址字段一律用
text-truncate+title属性展示全值，避免截断导致校验困难 - 金额类字段（
value、gasPrice）必须调用ethers.formatEther()或utils.formatUnits()转为 ETH/GWEI，且标注单位（如2.345 ETH），不能只写数字 -
status字段别只写1/0，要映射成Success/Reverted并加badge bg-success或bg-danger
避免在前端解析完整区块或交易原始数据
一个区块可能含上百笔交易，原始 JSON 动辄几 MB。用 fetch 拿到后直接 JSON.parse() 再渲染，页面会卡顿甚至崩溃，尤其移动端。
- 优先调用服务商的「摘要接口」（如 Etherscan 的
api?module=proxy&action=eth_getBlockByNumber加&boolean=true参数只取基础字段） - 交易列表页默认只加载 10–20 条，用分页或无限滚动；详情页才拉取单个交易的完整
input字段（必要时再 hex 解码） - 不要在
useEffect或mounted里无节制请求——加防抖（如搜索框 300ms 后触发）、加缓存（Map存最近 50 个 hash 结果）
响应式布局下，交易字段表格必须横向滚动而非换行
桌面端字段多（hash、from、to、value、gasUsed、timestamp…），小屏强行堆叠会丢失关键信息，用户无法横向比对。
- 给
table外层套<div class="table-responsive">，这是 <code>Bootstrap内置方案，别自己写 CSS 滚动 - 关键列（如
hash、status）设为sticky（需额外 CSS：position: sticky; left: 0; background: white;），否则滚动时看不到标识 - 移动端可隐藏非核心列（如
gasUsed、input），用「展开详情」按钮替代，而不是砍掉字段
实际最易被忽略的，是时间字段的时区处理——所有
timestamp 字段来自链上都是 UTC 秒级 Unix 时间戳，但用户直觉看的是本地时间。别依赖浏览器自动 toLocaleString()，要显式传 {timeZone: Intl.DateTimeFormat().resolvedOptions().timeZone}，否则用户跨时区协作时会误判交易发生顺序。
