在Django模型字段中存储NFT钱包地址的最佳方案咨询

核心方案：带验证的CharField #

推荐使用带长度约束和自定义验证器的CharField，这是最贴合NFT钱包地址特性的选择，具体配置如下：

模型示例代码 #

from django.db import models
from django.core.validators import RegexValidator

class NFTCollection(models.Model):
    # 自定义验证器：确保是合法十六进制字符串，支持可选的0x前缀
    wallet_address_validator = RegexValidator(
        regex=r'^(0x)?[0-9a-fA-F]+$',
        message='请输入有效的十六进制钱包地址，可带0x前缀',
        code='invalid_wallet'
    )

    owner_wallet = models.CharField(
        max_length=64,
        validators=[wallet_address_validator],
        unique=True,
        verbose_name='持有者钱包地址'
    )
    # 其他业务字段示例
    nft_name = models.CharField(max_length=100)
    mint_date = models.DateTimeField()

    def __str__(self):
        return f"{self.nft_name} - {self.owner_wallet}"

关键细节说明 #

• 长度设置：max_length=64
  主流公链的钱包地址长度都远低于64位：以太坊/BSC/Polygon是42位（0x+40位十六进制），Solana是44位，其他小众链最长也不会超过64位。预留足够冗余，避免后续适配新链时修改字段结构。
• 强制验证逻辑
  通过正则验证确保输入是合法十六进制字符串，避免脏数据入库。如果只针对单一链（比如以太坊），可以把正则改成r'^0x[0-9a-fA-F]{40}$'，强制0x前缀和固定长度。
• 唯一性约束
  钱包地址是用户的唯一标识，设置unique=True可以避免数据库中存储重复地址，同时优化查询性能。
• 为什么不选TextField？
  TextField无长度限制，会浪费数据库存储资源，且无法利用数据库的长度索引优化查询，而NFT地址长度固定且有限，CharField更合适。
• 为什么排除UUIDField？
  UUID的格式和NFT钱包地址完全不匹配，钱包地址是公钥哈希后的十六进制字符串，和UUID的结构没有关联，完全不适用。

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