为何OpenZeppelin ERC721定义两个safeTransferFrom方法？

提问内容 #

各位好：
我在阅读OpenZeppelin的ERC-721源码时，发现其定义了两个实现不同的safeTransferFrom方法。
我对这种设计方式感到好奇，能否有人为我解答？
非常感谢。

相关源码 #

/**
     * @dev See {IERC721-safeTransferFrom}.
     */
    function safeTransferFrom(
        address from,
        address to,
        uint256 tokenId
    ) public virtual override {
        safeTransferFrom(from, to, tokenId, "");
    }

    /**
     * @dev See {IERC721-safeTransferFrom}.
     */
    function safeTransferFrom(
        address from,
        address to,
        uint256 tokenId,
        bytes memory data
    ) public virtual override {
        require(_isApprovedOrOwner(_msgSender(), tokenId), "ERC721: caller is not token owner or approved");
        _safeTransfer(from, to, tokenId, data);
    }

设计原因说明 #

这是**函数重载（Function Overloading）**的典型应用，核心目的是贴合ERC-721标准并提升开发与交互体验，具体原因如下：

• 严格遵循ERC-721标准：以太坊官方的IERC721接口本身就定义了这两个签名的safeTransferFrom方法——一个支持传递额外字节数据（data参数），一个不支持。OpenZeppelin作为合规的标准实现库，必须完整实现接口的所有方法，才能保证合约符合ERC-721规范。
• 简化常见调用场景：大部分NFT转账场景不需要传递额外数据，提供不带data参数的版本，能让调用者（比如钱包、DApp）更简洁地发起转账，无需手动传入空字节数组。
• 代码复用减少冗余：不带data的方法直接调用带data的版本并传入空字符串，把权限检查、实际转账的核心逻辑都放在带data的方法里，避免重复编写相同代码，符合“Don't Repeat Yourself”（DRY）的编程原则。
• 保证兼容性：确保所有符合ERC-721标准的工具、合约在与该合约交互时，无论是调用带data还是不带data的方法，都能正常执行，不会因为方法签名缺失导致交互失败。

内容的提问来源于stack exchange，提问作者Ray