Ethers.js 非权威开发指南（续）

原本以为两篇文章的内容应该足以覆盖 Ethers.js 的关键内容，但目前看来似乎还有些遗漏，于是乎就有了这个续篇。与之前的风格一样，本篇的内容同样采用问题驱动的风格。

在本篇中，你可以了解到：

• 不要忽视地址
• 如何读取合约中的 public 变量
• 合约地址不定，仅能确定事件名，如何监听。
• 优化 infura 调用次数
• 留意日志查询的跨度
• 对接其他网络
• 值得了解的 ethers 周边工具

相比前两篇包含的都是实战代码，本篇则更偏向于开发策略和一些优化方法的总结。

看似简单的地址

从接触 dapp 开发的第一天，你就要跟地址打交道，不论是 EOA 还是 contract address，离了任何一个都很难开发出有意义的应用。地址本身，其实没有什么太多的复杂性，即便你不了解以下的几个事实，也并不影响应用的开发：

• 地址可以由私钥或者公钥生成：ethers.utils.computeAddress
• 它可以由用户签名恢复：参见下篇。
• 它可以由部署交易号获得：ethers.utils.getContractAddress
• 它也可以提前计算出来：参见 How to Define Smart Contract Address Before the Deploy。

然而，一个容易忽略的细小地方却可能对于你的 dapp 体验带来比较大的影响，虽然这个影响在数据量小的时候并不会暴露出来：地址同时包含了大小写。

这种地址有个专有名称：Checksum 地址，并且 ethers 也提供了方法来得到它：ethers.utils.getAddress。对于一般 dapp 来说，如何生成和计算 checksum 地址并不重要，真正值得关注的地方在于：你打算如何保存地址？

我在这篇状态同步的文章里曾经解释过为何要做状态同步的同步的原因，也提到过一般会利用数据库来作为状态同步数据的存储。看到这里，有经验的朋友应该很快就会明白我的潜台词：地址的大小写会影响数据查询的速度！

...