使用Django JSONField减少迁移问题是否为最优实践方案？

第一个问题：JSONField是不是规避迁移问题的最优方案？ #

不是，这是典型的过度使用反模式，只能在特定场景下解决表结构迁移问题，但会带来更多更难处理的后续问题：

• 丢失数据库原生约束能力：CharField的长度限制、EmailField的格式校验、IntegerField的类型约束等原生能力全部失效，所有数据合法性校验都要在应用层自行实现，稍有疏漏就会产生脏数据。
• 查询性能大幅下降：对JSON内部字段的查询效率远低于原生字段，且无法使用普通B树索引，即使针对JSON字段建GIN等特殊索引，维护成本和查询性能也远不如原生字段，数据量超过10万级后性能差距会非常明显。
• 数据可维护性大幅降低：JSON结构完全依赖业务代码逻辑约束，没有数据库层面的结构保障，时间久了或者团队人员更替后，很容易出现结构不统一的历史数据，排查问题的成本会高很多。
• 迁移问题只是被转移而非解决：后续如果需要调整JSON内部的字段结构，比如把旧的phone字段整合到contact_info对象下，你需要自行编写脚本全量更新历史JSON数据，这种迁移没有Django官方迁移工具的成熟支持，出错风险远高于普通表结构迁移。

第二个问题：能不能用单个含JSONField的模型存储联系表单、反馈表单等不同业务的数据？ #

仅在动态表单、用户自定义扩展属性等无法提前预知字段结构的特殊场景下可以这么做，普通业务场景下完全不建议：
你提到的联系表单、反馈表单都属于结构明确、变动极少的常规业务模型，分开建两个独立模型的开发成本极低，后续的查询、统计、维护成本都远低于把所有数据塞到同一个JSONField里的方案。
你给出的示例代码：

class Example(models.Model): 
    data = models.JSONField(null=False, default=dict)

这种无任何额外标记字段的通用存储设计，后续连区分某条数据属于联系表单还是反馈表单都需要额外在JSON里加字段判断，会平白增加大量业务代码的冗余逻辑。

合理使用建议 #

• 常规业务字段优先使用Django原生模型字段，正常做迁移即可：目前主流的MySQL 8.0+、PostgreSQL等数据库新增带默认值（或允许为NULL）的字段几乎是秒级操作，不会长时间锁表，只要提前在测试环境验证好迁移脚本，生产环境迁移出问题的概率极低。
• 仅当字段结构确实无法提前定义、属于动态扩展类内容时，再考虑使用JSONField，同时必须搭配Serializer、Pydantic等工具做应用层的JSON结构校验，禁止存入无规则的任意JSON数据。

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