Django自定义用户模型用加密SearchField作USERNAME_FIELD报NoneType无_meta错误

SearchField字段的clean方法存在设计适配缺陷：库代码中实现的clean逻辑，默认依赖传入的模型实例对象获取关联加密字段的元信息，但createsuperuser命令的执行流程中，会在尚未绑定具体用户模型实例的场景下直接触发字段校验，此时传入的模型实例参数为None，代码直接调用None._meta就会抛出AttributeError。
本质上原库的实现没有兼容Django字段接口的通用规范——Django内置所有字段的clean方法都支持model_instance为None的无实例校验场景，该库的自定义SearchField没有覆盖这个边界情况。

方案1：扩展SearchField适配无实例校验场景 #

这是改动最小、兼容性最好的方案：

• 自定义继承自原库SearchField的字段类，重写clean方法，当检测到传入的模型实例为None时，不再依赖传入的实例取字段元信息，直接通过字段本身关联的模型元信息找到对应的加密字段完成校验：

from encrypted_fields import fields

class AdaptedSearchField(fields.SearchField):
    def clean(self, value, model_instance=None):
        # 适配无模型实例的校验场景（如createsuperuser命令流程）
        if model_instance is None:
            related_encrypted_field = self.model._meta.get_field(self.encrypted_field_name)
            return related_encrypted_field.clean(value, model_instance)
        # 正常有实例的场景走原库逻辑
        return super().clean(value, model_instance)

• 将自定义用户模型中定义email字段的代码里，原来的fields.SearchField替换为上面实现的AdaptedSearchField即可，其他业务逻辑、配置都不需要改动。

方案2：自定义双字段实现等价的加密可搜索效果 #

如果不想引入对原库代码的扩展，可以手动实现和SearchField完全一致的能力，彻底绕开兼容性问题：

• 在用户模型中定义两个内部存储字段：
  • email_hash: 普通CharField(unique=True, max_length=64)，用来存储邮箱地址的单向加盐哈希值，承担唯一性校验、登录等值匹配、精确搜索的能力，不会存储明文
  • email_encrypted: EncryptedCharField(max_length=255, blank=True)，用来存储加密后的完整邮箱内容，需要读取明文邮箱时直接从这个字段解密获取
• 给模型增加对外暴露的email属性，实现自动映射逻辑：赋值时自动计算哈希写入email_hash、加密内容写入email_encrypted；读取时自动从email_encrypted解密返回明文。
• 将USERNAME_FIELD设置为email_hash，由于这是原生的Django字段，不存在原库SearchField的校验兼容问题，createsuperuser创建流程、登录认证、唯一性约束、搜索功能都可以正常运行，最终效果和使用加密SearchField完全一致。

• 不要直接对加密后的密文字段设置unique=True约束，因为同一邮箱每次加密的密文结果会随机变化，根本无法触发唯一性校验，必须配合单独的哈希字段才能实现去重、登录匹配的效果。
• 哈希计算的盐值要和加密字段的密钥一样做环境级配置，不要硬编码在代码里。

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