Go 开发首先需要区分链上模型
Go 是实现程序的语言，转账规则由目标区块链协议决定。理解相关概念时，应先明确资产如何记录、花费权限如何验证、交易结果如何确定。以下以以太坊和比特币为例，两者的数据结构与验证方式不能直接混用。
账户模型与 UTXO 模型
以太坊交易包含接收地址、金额、nonce、费用参数及可选调用数据，并由发送方签名。nonce 表示账户交易序号。比特币普通交易则通过输入引用既有的未花费交易输出，即 UTXO，再创建新的输出；引用使用前序交易标识与输出索引。
这意味着“余额足够”只是表层描述。账户模型需要考虑交易顺序，UTXO 模型需要明确花费哪些输出。Go 程序的数据设计必须体现这些差异，不能仅用发送地址、接收地址和金额描述全部交易语义。
地址、密钥与数字签名
数字签名用于验证花费授权。比特币传统 P2PKH 交易通过公钥、签名和脚本条件完成验证，接收地址用于表达相应的支付条件。这种具体结构有适用范围，不能代表所有比特币输出类型。
地址、签名和交易标识承担不同职责：地址表达接收目标或支付条件，签名提供授权证据，交易标识用于定位交易。理解这些区别，有助于避免把“知道地址”误认为“具有花费权限”，或把“生成交易标识”误认为“转账完成”。
金额、费用与合约调用
以太坊的 value 以 wei 计量，gasLimit 限制计算资源用量，动态费用参数限定单位 gas 的费用。调用合约时，data 可按 ABI 编码函数选择器和参数；交易的 to 指向合约。
金额单位与计算资源单位需要分别理解。gas 数量不能直接当作手续费金额，费用上限也不能直接当作实际支出。对于代币转账，还要区分交易外层的合约地址与调用参数中的资产接收地址，不能仅查看外层 to 和 value 就判断全部业务含义。
编码、节点通信与确认状态
程序中的交易字段需要按目标链规定编码，签名后的交易再通过节点传播。以太坊支持不同交易类型，因此内存中的对象、接口中的 JSON 表示和网络传输字节属于不同层次。
常见问题是把接口返回交易哈希当作成功证明。提交、待处理、进入区块、执行成功和达到最终性应分别理解。尤其是合约调用，交易进入区块后仍需核实执行结果；业务状态应依据链上结果更新，不能仅依据网络请求是否成功。