Django表单验证失败不显示错误信息，主因是模板未渲染form.errors或form.field.errors；需检查是否调用form.is_valid()后再访问errors，且文件字段须传request.FILES。
Django表单验证失败时为什么没显示错误信息？
这个问题恐怕是新手开发者踩的第一个坑：明明表单验证没通过，页面上却一片祥和，用户完全不知道错在哪里。根源其实很简单——Django并不会自动把错误信息“泼”到你的页面上。它只负责在后台生成一个包含所有错误详情的对象，至于如何把这些信息展示给用户，得由你在模板里亲手“画”出来。
- 首先，检查你的模板。是否显式地渲染了全局错误
{{ form.non_field_errors }}和针对每个字段的错误{{ form.name.errors }}？请务必将这里的name替换成你表单的实际字段名。 - 其次，确认视图逻辑。只有在调用
form.is_valid()方法之后，form.errors这个字典才会被填充。在此之前，它始终是个空壳子，自然无错可显。 - 还有一个隐蔽的陷阱：当表单包含文件上传字段时，实例化表单必须同时传入
request.POST和request.FILES。如果漏传后者，Django会直接跳过所有与文件相关的验证规则，表面上看表单“通过”了，实则关键检查被完全遗漏。
Serializers 和 Django Form 验证逻辑冲突怎么办？
当项目里同时存在Django Form和DRF Serializer时，很多人会困惑：这两套验证体系，到底该听谁的？其实，问题的关键不在于比较孰优孰劣，而在于清晰地划分职责边界——谁该负责哪一层的校验。
- 面向Web页面的表单提交：优先使用Django原生的
Form或ModelForm。它们能无缝绑定HTML属性、自动生成表单控件，并且天然支持CSRF防护，这是为浏览器环境量身定做的方案。 - 处理API请求（如JSON数据）：DRF的
Serializer是更合适的选择。它在处理嵌套数据结构、进行复杂的字段类型转换时更为灵活，并且其生命周期与APIView完美契合。 - 需要警惕的是，切忌在同一个请求处理流程中先后调用
Form.is_valid()和Serializer.is_valid()。这会导致错误信息被覆盖，而且两者的cleaned_data与validated_data在结构上也可能存在差异，徒增混乱。
自定义验证器在 Form 和 Serializer 中写法差异大吗？
验证的核心业务逻辑当然可以复用，但挂载的“接口”和触发的“时机”却大有不同。如果直接把代码从一个地方搬到另一个地方，很容易出问题，尤其是在涉及数据库查询或字段间关联校验时。
- 在 Django Form 中，单字段验证通过
clean_方法实现，而涉及多个字段的交叉验证则在() clean()方法中进行。注意，此时你拿到手的字段数据，还是原始的字符串或上传文件对象，尚未转换成Python的整数、日期等类型。 - 在 DRF Serializer 中，对应的则是
validate_和() validate()方法。关键区别在于，validate()方法接收到的validated_data已经是经过类型转换后的数据。例如，一个IntegerField在这里已经是int类型，而非字符串。 - 特别提醒：不要将数据库唯一性检查这类需要原子性操作的逻辑写在
clean()方法里。在高并发场景下，这可能引发竞态条件，导致重复数据被创建。正确的做法是将其放在模型的full_clean()方法中，或者是在调用sa ve()时利用数据库的唯一约束来处理。
为什么 ModelForm.sa ve() 后字段值和表单提交的不一致？
你是否遇到过这种情况：表单明明提交了某个值，但保存到数据库后却发现字段内容“变了样”？这通常是因为模型层的一些“小动作”干扰了表单的原始意图。验证通过，绝不等于数据会原封不动地入库。
立即学习“Python免费学习笔记（深入）”；
ModelForm默认只保存那些在fields列表中明确声明的字段。如果某个数据库字段有默认值（default）但没被包含在表单字段里，sa ve()时它不会被更新，数据库的默认值会生效。- 对于设置了
auto_now=True的字段（如updated_at），情况更“霸道”。无论你在表单中提交了什么值，在调用sa ve()的瞬间，都会被当前时间覆盖。 - 如果想确保表单提交的值拥有最高优先级，避免模型层逻辑的“副作用”，可以尝试这个模式：先使用
sa ve(commit=False)获取模型实例但不保存，然后手动将表单值赋给实例的对应字段，最后再调用instance.sa ve()。这样你就完全掌控了数据入库前的最后状态。
最后，再提一个常见的混淆点：DRF Serializer 的 required=False 和 Django Form 的 required=False，虽然参数名相同，但影响层面截然不同。前者主要控制反序列化时该字段是否必须出现在输入数据中；而后者则同时影响前端表单的渲染（是否显示为必填项）和后端的空值验证。这个微妙的边界如果没理清，很可能导致API莫名其妙返回400错误，排查起来却困难重重。
