f() 用于字段间比较，避免误作 python 变量或字符串；正确用法如 account.objects.filter(balance__gt=f("frozen_amount"))，错误写法会导致查询失败或 fielderror。
用 F() 比较两个字段值，比如“余额大于冻结金额”
直接在 filter() 或 exclude() 里用 F() 引用字段名，Django 就不会把它们当 Python 变量或字符串处理，而是生成 SQL 的列引用。
常见错误是写成 balance > frozen_amount（Python 比较），或者 "balance__gt=frozen_amount"（字符串硬编码），结果查不到数据，甚至报 FieldError。
-
Account.objects.filter(balance__gt=F("frozen_amount"))→ 查余额大于冻结金额的记录 -
Account.objects.filter(last_login__lt=F("created_at"))→ 查最后登录时间早于创建时间的异常账号（逻辑错位） - 不能混用：
F("balance") > 100是对的，但F("balance") > F("frozen_amount") + 10在旧版 Django（DatabaseError，因为某些后端不支持字段表达式参与算术运算
用 F() 做原子更新，避免竞态条件
比如“用户点赞，计数器 +1”，如果先 get() 再 save()，高并发下会丢更新；F() 把计算下推到数据库层，一行 SQL 完成。
典型场景：阅读数自增、库存扣减、积分累加。不这么做，就等于默认接受数据错乱。
-
Article.objects.filter(id=123).update(view_count=F("view_count") + 1)→ 安全，返回影响行数 -
Order.objects.filter(status="pending").update(locked_at=F("updated_at"))→ 把更新时间复制给另一个时间字段，避免 Python 层时区/精度问题 - 注意：不能在
update()里混用普通值和F()做条件判断，比如update(status="done", finished_at=F("updated_at") if condition else None)—— 这是 Python 逻辑，F()不支持三元运算，得用Case+When
F() 和 Q() 套着用，实现复杂查询条件
F() 处理字段间关系，Q() 组织逻辑结构，两者天然互补。单独用 F() 写不了 “A > B 或 C
容易踩的坑是以为 F() 能替代所有查询逻辑，结果发现 or、not、嵌套括号都得靠 Q()。
-
Q(balance__gt=F("frozen_amount")) | Q(is_premium=True)→ 余额超冻结额 或 是 VIP -
~Q(updated_at__lt=F("created_at"))→ 排除更新时间早于创建时间的脏数据 -
F()不能出现在Q()的左值位置，比如Q(F("status")=="active")是错的——F()只能当右值（比较对象），不能当左值（被比较的字段要写在 lookup 键里）
更新时读取新值？F() 本身不返回结果
F() 是纯表达式，用于生成 SQL，它自己不携带运行时值。想拿到更新后的字段值，不能靠 F() 返回，得额外查一次，或用数据库的 RETURNING（PostgreSQL）。
很多人卡在这一步：以为 .update(..., counter=F("counter")+1) 后能直接拿到新值，结果发现返回的是整数（影响行数），不是数据。
- 安全做法：用
refresh_from_db()（适合单对象，且你刚改完自己这个实例） - 高效做法：PostgreSQL 用户可配合
returning参数（需自定义 raw SQL 或用django-postgres-extra等扩展） - 别写
obj.counter = F("counter") + 1; obj.save()—— 这会把F()当 Python 对象存进字段，导致数据库里出现类似"F(counter) + 1"的字符串
F() 的边界就立刻暴露出来。它不是万能占位符，而是一个精准下推到 SQL 层的钩子——用对地方省事，用错地方反而更难 debug。
