GeneratedField 在 Django 5.0 中未正式支持，仅存在于开发分支；应使用 @property、Func 表达式或手动 RunSQL 迁移替代，避免 ORM 同步失效与数据库失配问题。
GeneratedField 在 Django 5 中不被支持
Django 5.0 并未引入 GeneratedField，它仍处于开发中（截至 2024 年中，仅在 main 分支实验性存在，未发布）。你如果在文档或 GitHub issue 里看到 GeneratedField，大概率是误读了 RFC 提案、PR 草稿，或混淆了 PostgreSQL 的 GENERATED ALWAYS AS 与 Django 的字段抽象。
替代方案：用 DatabaseFeatures.supports_computed_columns 判断后手写 SQL
Django 5 对数据库生成列（computed / generated columns）的支持非常有限——仅 PostgreSQL 12+ 和 SQLite 3.31+ 在底层能支持，但 Django 自身没有提供高层 API 封装。想用原生生成列，必须绕过 ORM 字段层，直接操作建表语句：
- 确认数据库能力：
connection.features.supports_computed_columns返回True才可继续（PostgreSQL 默认为True，MySQL/MariaDB 为False） - 用
RunSQL在迁移中手动添加列：RunSQL( "ALTER TABLE myapp_mymodel ADD COLUMN full_name TEXT GENERATED ALWAYS AS (first_name || ' ' || last_name) STORED", reverse_sql="ALTER TABLE myapp_mymodel DROP COLUMN full_name" ) - 不要在
models.py中声明该字段，否则makemigrations会试图管理它，引发冲突
更安全的实践：用 @property 或 Func 表达式代替
绝大多数场景下，“数据库计算字段”的真实需求其实是「查询时动态计算」或「ORM 层只读派生值」，而非物理存储。这时应优先选 Django 原生方式：
python-script-generator
下载
快速生成专业的 Python 脚本和应用代码。一键创建完整项目结构，支持CLI、API、爬虫、Bot、Django等多种项目类型，包含完整的项目结构、配置文件、依赖管理、测试、README和文档。
- 模型层只读计算 → 用
@property：class MyModel(models.Model): first_name = models.CharField(max_length=50) last_name = models.CharField(max_length=50) @property def full_name(self): return f"{self.first_name} {self.last_name}" - QuerySet 中计算 → 用
F+Func：from django.db.models import F, Func MyModel.objects.annotate( full_name=Func(F('first_name'), Value(' '), F('last_name'), function='CONCAT') )（PostgreSQL 用||，SQLite 用||，MySQL 用CONCAT，注意函数名差异） - 需要索引加速？在数据库侧单独建函数索引，Django 不感知也不管理
为什么别硬套“GeneratedField”概念
强行模拟 GeneratedField 容易踩三个坑：
立即学习“Python免费学习笔记（深入）”；
- 迁移不可逆：STORAGE 类型（
STOREDvsVIRTUAL）在不同数据库语义不同，Django 无抽象，写错就锁表 - ORM 同步失效：
save()不会触发重新计算，字段值可能 stale；bulk_create更是完全跳过 - 多数据库失配：同一份迁移在 SQLite 跑通，在 MySQL 直接报错，因为
GENERATED语法非标准 SQL
真正需要数据库级生成列的场景极少——比如审计字段（created_at DEFAULT NOW()）、物化路径（lft/rgt），这些 Django 已有成熟模式（auto_now_add、django-mptt）。其余情况，先用 annotate 或 @property，性能瓶颈再考虑底层优化。
