自定义验证器函数必须接收单个参数且返回None：Django 5.0要求验证器为单参可调用对象，验证失败抛ValidationError，成功时必须显式return None，否则报TypeError。
自定义验证器函数必须接收单个参数且返回 None
Django 5.0 的表单字段验证器（validators 参数）要求验证器是可调用对象，签名必须为 def validator(value): ——只接受一个参数（即字段值），验证失败时抛出 ValidationError，成功时**必须显式返回 None**。返回字符串、True 或不写 return 都会触发 TypeError: Validator returned unexpected value。
常见错误：写成 return "too short" 或漏掉 return None，Django 会静默忽略验证逻辑或直接报错。
- 验证器函数名无需以
validate_开头，但建议语义清晰，如validate_phone_format - 不要在验证器里操作数据库或发 HTTP 请求——它应在表单 clean 阶段快速执行，阻塞主线程
- 若需访问其他字段值（比如确认密码），不能放在这里，得用
Form.clean()方法
在 ModelForm 中复用模型层验证器要小心路径引用
如果你已在模型字段上定义了验证器（例如 models.CharField(validators=[validate_slug])），想在 ModelForm 中沿用，别直接写 validators=[validate_slug] ——Django 5.0 默认不会自动继承模型的验证器到表单字段，除非你显式开启。
正确做法是：在 ModelForm 的 Meta.fields 列表中包含该字段，并在 Meta.widgets 或字段重定义时手动传入：
立即学习“Python免费学习笔记（深入）”；
class ArticleForm(forms.ModelForm):
slug = forms.SlugField(validators=[validate_slug]) # 显式覆盖
<pre class="brush:php;toolbar:false;">class Meta:
model = Article
fields = ['title', 'slug', 'content']
否则 Django 会跳过模型上声明的验证器，仅运行表单字段默认验证（如必填、长度等）。
- 模型验证器在
model.full_clean()和 admin 保存时生效；表单验证器只在form.is_valid()时触发 - 两个地方都加同一验证器，可能造成重复校验和冗余错误信息
- 推荐策略：模型层做强约束（如唯一性、格式），表单层做用户体验优化（如提示文案更友好）
ValidationError 的 error_list 参数决定错误显示位置
抛出 ValidationError 时，传入的参数类型直接影响错误渲染位置：ValidationError("xxx") 是字段级错误；ValidationError({"field_name": ["xxx"]}) 可绑定到特定字段；而 ValidationError(["xxx"], code="invalid") 支持分类和 i18n。
在自定义验证器中，几乎总是用单字符串或字符串列表：
from django.core.exceptions import ValidationError
<p>def validate_not_future_date(value):
if value > date.today():
raise ValidationError(
"日期不能晚于今天",
params={"value": value},
code="date_in_future"
)
- 避免传字典给单字段验证器——它没上下文知道该绑哪个字段
-
params用于模板中动态插值（如%(value)s），不是必需，但利于本地化 - 同个字段多个验证器抛出的错误会合并进同一个
error_list，顺序按validators列表顺序执行
验证器被绕过的典型场景：disabled 字段和 initial 值
如果字段设置了 disabled=True，Django 不会运行其任何验证器（包括自定义的），因为该字段值不会被提交；同样，initial 值也不会触发验证——它只用于渲染初始 HTML，不参与 POST 数据校验。
这意味着：你不能靠验证器阻止用户通过浏览器开发者工具篡改 disabled 字段后提交非法值。服务端安全校验必须落在 clean() 或模型 save() 阶段。
- 前端 disabled + 后端无验证 = 安全漏洞温床
- initial 值若来自不可信来源（如 URL query），应先清洗再传入，而不是依赖验证器兜底
- 验证器本质是“用户输入合理性检查”，不是权限或业务规则守门员
Django 表单验证器真正起效的前提，是你把它挂到了实际参与提交的字段上，且这个字段的值确实进入了 request.POST。其它任何地方的“看起来像验证”的逻辑，都只是幻觉。
