Django模型怎么写？ORM对象关系映射详解

Django模型看似只是定义几个字段，实则暗藏大量影响数据完整性、查询性能、时区行为和跨数据库兼容性的关键细节：从必须加括号实例化字段、避开Python保留字，到精准选择CharField与TextField以防数据静默截断；从强制设置on_delete策略避免级联误删或外键崩溃，到谨慎使用auto_now/auto_now_add以免时间被意外覆盖；再到null/blank语义区分、related_name防冲突、时区处理陷阱及SQLite的特殊限制——每一个参数都不是可有可无的装饰，而是对“数据如何安全存、准确查、可靠删、稳定跑”的提前设计。写好一个Model，本质是在用Python语言为业务数据搭建第一道坚固防线。

怎么定义一个基础 Django Model 类

直接继承 models.Model，类名对应数据库表名（默认转为小写下划线），字段用 models.XXXField 声明。Django 会自动加 id 主键，除非你显式指定 primary_key=True 的字段。

常见错误：忘了加括号 —— 写成 models.CharField 而不是 models.CharField()，会报 TypeError: 'CharField' object is not callable；或者漏掉括号后直接传参（如 max_length=100）却没调用，同样失败。

• 每个字段必须是 models.Field 的实例，不是类本身
• 字段名不能是 Python 保留字（如 class、def），也不建议用 id、pk 等内部属性名
• verbose_name 推荐写上，对 Admin 和表单友好；help_text 在表单里显示提示，别等上线才发现字段含义模糊

CharField 和 TextField 到底该选哪个

CharField 必须带 max_length，底层对应数据库的 VARCHAR；TextField 不限制长度，对应 TEXT。选错会导致迁移失败或数据被截断 —— 比如存一篇博客正文用了 CharField(max_length=200)，内容超长时静默丢弃后面部分，连警告都没有。

使用场景差异很实际：CharField 适合用户名、邮箱、状态码这类有明确长度边界的值；TextField 用于评论、文章正文、JSON 配置串（虽然不推荐存 JSON，但真要存就别硬塞 CharField）。

• PostgreSQL 对 varchar 和 text 性能几乎无差别，MySQL 下 TEXT 字段不能建全文索引（除非用 ALTER TABLE ... ADD FULLTEXT 单独处理）
• SQLite 下 max_length 完全不生效，纯靠 Python 层校验，别依赖它防越界
• 如果字段可能为空，记得设 null=True（数据库层面允许 NULL）和 blank=True（表单/序列化器允许空字符串）—— 两者语义不同，常一起出现但不可互相替代

ForeignKey 和 ManyToManyField 的 on_delete 参数不能瞎填

Django 2.0+ 强制要求 ForeignKey 和 OneToOneField 必须显式声明 on_delete。填错最典型的问题是用 models.CASCADE 删除父对象时连带删光子记录，结果用户删了个分类，整页商品全没了；或者误用 models.DO_NOTHING，数据库外键约束报错 IntegrityError，而 Python 层毫无感知。

真实项目里更常用的是：models.PROTECT（删前检查有没有子对象，抛 ProtectedError）、models.SET_NULL（需配合 null=True）、models.SET_DEFAULT（需提前设好 default=...）。

• ManyToManyField 不需要 on_delete，它通过中间表维护关系，删模型实例不会自动清理关联
• 反向关系名（related_name）强烈建议自定义，否则默认的 xxx_set 在多对一嵌套时极易冲突，比如两个 ForeignKey 都指向 User，反向名都是 user_set
• related_query_name 影响 filter() 中的双下划线查找（如 Post.objects.filter(author__name='a')），默认和 related_name 一致，但可单独设

DateTimeField 的 auto_now 和 auto_now_add 别混用

auto_now=True 每次调用 .save() 都刷新时间，适合“最后修改时间”；auto_now_add=True 只在第一次保存时写入，适合“创建时间”。二者互斥，同时设会报 ValueError；更隐蔽的坑是：它们会绕过字段赋值逻辑 —— 即使你在代码里写了 obj.updated_at = timezone.now()，只要开了 auto_now，这个赋值就无效。

生产环境还容易踩时区坑：Django 默认用 USE_TZ=True，所有 DateTimeField 存 UTC 时间。如果前端传来带时区的时间字符串（如 "2024-05-20T14:30:00+08:00"），直接赋值给 DateTimeField 会出错，得先用 django.utils.dateparse.parse_datetime() 或 make_aware() 处理。

• 想手动控制时间字段？别用 auto_now*，改用信号（pre_save）或重写 save() 方法
• default=timezone.now（注意没括号）是安全的，它每次新建实例都调用一次函数；写成 default=timezone.now() 就变成模块加载时执行一次，所有实例共享同一个时间点
• SQLite 不支持时区，USE_TZ=True 下存的时间仍是本地时间，但 Django 会假装它是 UTC —— 这个隐式行为在线上 PostgreSQL/MySQL 环境里会暴露问题

字段类型看着简单，但每个参数背后都连着数据库行为、ORM 查询逻辑、时区处理和迁移兼容性。写模型不是填空，是提前想好数据怎么进、怎么查、怎么删、怎么跨环境跑。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~