动态字段必须在form类的__init__方法中注入，因类定义阶段已固化字段；需调用super().__init__()后操作self.fields，严格匹配字段类型与配置，并在clean()中手动处理动态字段验证逻辑。
动态字段定义必须用 Form 类的 __init__ 方法注入
硬编码字段无法响应运行时变化，比如根据用户角色显示不同字段、或按数据库配置加载字段。Django 的 Form 类在类定义阶段就完成了字段绑定，所以不能在类体里用变量或查询动态写 CharField()；必须把字段添加逻辑移到实例化阶段——也就是重写 __init__。
常见错误是试图在类属性中用 for 循环生成字段，结果字段只在模块加载时执行一次，且所有实例共享同一套字段对象，导致并发下字段错乱或验证异常。
- 在
__init__开头先调用super().__init__(*args, **kwargs)，否则基类初始化失败，self.fields为空 - 新增字段用
self.fields['field_name'] = forms.CharField(...)，不要直接操作__dict__或绕过字段注册机制 - 如果需删除默认字段，用
self.fields.pop('old_field', None)，避免KeyError
字段类型与参数需按实际输入类型严格匹配
前端传来的数据类型和后端表单字段类型不一致时，Django 会在 is_valid() 阶段静默转换失败或抛出 ValidationError，但错误信息常指向“Enter a valid value”，而非具体哪一字段、为何失败。
例如：数据库配置字段为 integer，但代码中用了 forms.CharField()，用户输数字能过验证，但 cleaned_data 是字符串，后续做算术运算会报 TypeError；反过来，若配置是文本却用了 forms.IntegerField()，空字符串或非数字输入直接卡在验证层。
- 从配置读取字段类型后，映射到对应
forms.XXXField：如'text' → forms.CharField，'number' → forms.IntegerField，'date' → forms.DateField - 必填（
required）、默认值（initial）、最大长度（max_length）等参数必须从配置中显式提取并传入，不能依赖字段类型的默认行为 - 对
ChoiceField，选项列表必须是[(value, label), ...]元组列表，且value必须是字符串或可序列化类型，否则提交时可能匹配不到选项
clean_<field_name></field_name> 方法无法对动态字段自动触发
Django 表单的自定义清理方法（如 clean_email）是在类定义时通过名字反射注册的，而动态添加的字段名在类定义期不存在，因此这些方法不会被自动识别和调用。
提供使用 django-unfold (v0.56+) 构建高级 Django 管理界面的专业指导。当用户提及 django-unfold、unfold admin 等内容时使用此技能。
现象是：字段校验逻辑看似写了，但 is_valid() 总返回 True，或错误没出现在对应字段下，而是进了 non_field_errors。
- 统一使用
clean()方法处理跨字段逻辑，里面手动检查self.cleaned_data.get('dynamic_field') - 若必须字段级清理，可在
__init__中动态绑定方法：setattr(self, f'clean_{field_name}', lambda: self._custom_clean(field_name))，但要注意方法签名和异常抛出方式需符合 Django 要求 - 更稳妥的做法是把字段级规则封装成独立函数，在
clean()中逐个调用，并用self.add_error(field_name, msg)手动挂载错误
模板渲染时必须用 {{ form.field_name }} 或循环 {{ form.visible_fields }}
直接写 {{ form.dynamic_field }} 会报 KeyError，因为模板引擎查的是表单实例的字段字典，不是 Python 属性；而字段名含变量时，Django 模板不支持 {{ form[field_name] }} 这种语法（除非自定义模板过滤器）。
典型误操作是试图在模板里拼接变量：{% with 'field_'|add:obj.id %}{{ form.that_var }}{% endwith %}——这根本不会解析为字段对象，只会输出空字符串。
- 最简方案：在视图中把动态字段名列表传给模板，用
{% for field in dynamic_field_names %}{{ form[field] }}{% endfor %}，前提是模板启用了form.__getitem__（Django 默认支持） - 确保字段已加入
self.fields，否则即使名字对，form[field_name]也返回None - 若需控制 HTML 属性（如
data-*），在__init__中设置widget=forms.TextInput(attrs={'data-config-id': config.id})，而不是在模板里硬编码
动态表单真正的复杂点不在字段生成，而在验证上下文和错误定位——字段名来自数据库或 API，意味着错误消息也要能反向映射回原始配置项 ID，否则运维排查时根本不知道是哪个配置项出了问题。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
