其实做web3开发，最大的障碍莫过于这帮人说的一些生僻的词。我们之前就是调个接口，人家说你发一笔交易，我们之前传入的一个参数，一个配置变量，人家说你得加一个合约地址。反正就是听娃娃哭的多了，你就差不多知道他是饿了，还是拉了。

目录

1 链上的接口

2 abi又是什么？ 

---

1 链上的接口

做链的同事，把代码写好以后，部署到链上的服务器，他们也许会说自己的服务部署好了，也许会说自己的应用部署上去了，也许会说自己的合约弄上去了，反正都差不多。这个时候，他们会给你文档，告诉你哪一步该调用哪个方法。

这就好像，我们做java前后端交互的时候，人家说，你调这个接口，传这些参数。而headers请求头里的东西是我们最初就该做的代码准备。而与链交互的时候，一些合约地址，web3服务端交互地址，这些也是我们该准备好的。前面的章节我们已经说过了。

比如链上有个获取某个详细信息的接口该怎么调用呢？看代码：

const Web3 = require('web3');// 连接到以太坊节点
const web3 = new Web3('http://localhost:8545'); // 这里的地址需要替换成你的以太坊节点地址// 合约地址和ABI
const contractAddress = '0x123456789abcdef'; // 合约地址
const abi = [/* 合约的ABI */]; // 合约的ABI// 创建合约实例
const contract = new web3.eth.Contract(abi, contractAddress);// 调用合约方法
contract.methods.methodName(param1, param2, ...) // 方法名和参数.send({  }) // 发送交易.then((receipt) => {console.log('Transaction receipt:', receipt);}).catch((error) => {console.error('Error:', error);});

上面的send方法里，我置空了，里面有几个参数需要注意：

1. from：当前钱包用户的钱包地址，这个可以获得到
2. gas：手续费，这个可以加，也可以不加，真正钱包交互的时候，为了让自己的这个行为快点被旷工处理，可以把手续费自己加高一些，不过这里可以写入一个最低费率

3. type：‘0x0’ 尝试过，不加大多数时候会报错

2 abi又是什么？ 

如果遇到链也不是很懂的但还要做链开发的同事，他们就会问你要abi，你就会问，啥是abi，他就说你就给吧，你就看着他，最后默默无言。

ABI（Application Binary Interface）是一种描述智能合约接口的规范，它定义了合约的方法、参数和返回值的数据类型。在与智能合约进行交互时，ABI告诉你如何与合约进行通信，包括调用合约的方法以及如何解析方法的返回值。

ABI通常以JSON格式表示，它描述了合约中每个方法的名称、参数列表和返回值。通过提供ABI，你可以在客户端（如JavaScript应用程序）中编程地调用合约的方法，而无需了解合约的实现细节。

一个ABI的简单示例可能如下所示：

[{"constant": true,"inputs": [],"name": "getValue","outputs": [{"name": "","type": "uint256"}],"payable": false,"stateMutability": "view","type": "function"},{"constant": false,"inputs": [{"name": "newValue","type": "uint256"}],"name": "setValue","outputs": [],"payable": false,"stateMutability": "nonpayable","type": "function"}
]

其实倒也不用担心，正常情况下，如果业务不太复杂很简单那种，链同事会给你一套abi，写死的，如果业务复杂，可能是多个abi，每种场景用一个。重点是，这个东西就像一个配置参数，他得给你，就是他给你的，你也别想着去哪里要。除非你的业务复杂，有专门的一个接口，你还需要去调用一下，获取一下abi，但翻来覆去，abi是死的，你当前做项目不会变的，上了线也几乎是这个。如果变了，他会再给你。

真正项目的abi会比这个又臭又长的多，几十Kb都有可能。