django 5.0 中 databasegenerated 列需手动在数据库中创建（如 alter table ... add column ... generated always as ... stored），再在模型中声明对应字段，设 editable=false、default=not_provided 且 db_column 严格匹配；django 不自动生成 ddl，也不支持跨表或非确定性表达式。
Database-generated列在Django 5.0中怎么定义？
Django 5.0 引入了 DatabaseGenerated 字段（位于 django.db.models），用于映射数据库原生的生成列（如 PostgreSQL 的 GENERATED ALWAYS AS ... STORED、MySQL 5.7+ 的 AS ... STORED）。它不参与 Python 层赋值，只读，由数据库自动计算并持久化。
- 必须配合支持生成列的后端（PostgreSQL ≥12、MySQL ≥5.7、SQLite ≥3.31）
- 字段需显式设为
editable=False和default=NOT_PROVIDED（不能用default=None或blank=True） -
db_column名必须与数据库中定义的列名完全一致 - 迁移前，需先在数据库中手动创建该生成列（Django 不自动建），再用
python manage.py inspectdb或手写迁移补上字段定义
例如，在 PostgreSQL 中先执行：
ALTER TABLE myapp_order ADD COLUMN total_amount NUMERIC GENERATED ALWAYS AS (quantity * unit_price) STORED;然后在模型中声明：
total_amount = models.DecimalField(max_digits=10, decimal_places=2, editable=False, db_column='total_amount')为什么不能直接用@property或@cached_property替代？
@property 在 Python 层计算，无法被 filter()、order_by()、annotate() 直接使用；@cached_property 依赖实例生命周期，且不保证数据一致性（比如并发更新时缓存未失效）。
- 查询时无法下推到数据库：如
Order.objects.filter(total_amount__gt=100)会报错或全表 Python 过滤 - 聚合失效：
Order.objects.aggregate(avg_total=Avg('total_amount'))对@property返回None - 序列化/DRF 输出时若未显式
SerializerMethodField，字段直接丢失 -
DatabaseGenerated列则全程走 SQL，支持所有 ORM 查询操作，且值始终与底层数据同步
迁移中如何安全添加生成列字段？
这是最容易出错的环节。Django 不生成 DDL，你必须自己控制顺序和兼容性：
- 先在数据库中添加生成列（注意：某些数据库要求列类型与表达式结果严格匹配，比如
quantity * unit_price若为INTEGER × DECIMAL，结果可能是NUMERIC，不能声明为IntegerField） - 再运行
python manage.py makemigrations --empty myapp，手动编辑迁移文件，在operations中加入migrations.AddField，但不要加RunSQL—— 因为列已存在 - 确保
state_operations与operations一致，否则showmigrations状态错乱 - 如果旧数据已有，生成列会立即生效；但若表达式引用了 NULL 值，需提前处理（如加
COALESCE），否则 PostgreSQL 可能报null value in column violates not-null constraint
哪些业务场景适合用Database-generated列？
核心原则：逻辑稳定、无外部依赖、可完全由已有字段推导。
- 订单总金额：
quantity * unit_price（前提是单价和数量不为空） - 用户昵称拼接：
CONCAT(first_name, ' ', last_name)（MySQL/PostgreSQL） - 状态派生字段：
CASE WHEN paid_at IS NOT NULL THEN 'paid' ELSE 'pending' END - 时间戳组合：
DATE(created_at)或EXTRACT(YEAR FROM created_at)
不适用的情况：
- 涉及跨表关联（如
JOIN后计算）→ 用Subquery或视图 - 需要调用 Python 函数（如加密、正则匹配）→ 仍放业务层
- 表达式含 volatile 函数（如
NOW()、RANDOM()）→ 大多数数据库禁止在生成列中使用
生成列不是万能的“自动计算”开关，它把确定性逻辑下沉到存储层，换来的是查询性能和一致性保障——但代价是灵活性降低，改表达式就得改库、改迁移、重跑数据校验。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
