嵌套序列化核心是解决真实树状数据的读写问题：读需prefetch_related防N+1，写需手动重写create/update并控制事务一致性，而非依赖drf-writable-nested掩盖风险。
Serializer 处理嵌套数据不是为了“炫技”，而是因为真实业务里，客户端几乎从不只要一个 User.id —— 它要用户、头像、所属部门、最近三条订单、订单里的商品列表……这些天然就是树状结构。DRF 的嵌套序列化机制，是把这种结构映射到 JSON 的最小可行路径。
嵌套序列化器默认只读，但你可能误以为它能写
绝大多数人第一次用 BookSerializer 嵌套进 AuthorSerializer 时，会发现 POST 或 PUT 提交带 "books": [...] 直接报错或被静默忽略。这不是 bug，是 DRF 的明确设计：read_only=True 是默认值。
-
many=True字段（如一对多）必须显式设read_only=False才可能参与反序列化，但还不够 - 即使放开读写，DRF 不会自动调用子序列化器的
create()；你得重写父序列化器的create()和update() - 外键字段（如
author）若没在fields中声明，或没配source，嵌套数据根本进不到验证流程
prefetch_related 不加，嵌套读取必然 N+1
当你返回 Author 并嵌套 books，DRF 默认对每个 author 执行一次 Book.objects.filter(author=...)。100 个作者 → 100 次查询。这不是慢，是灾难。
Django Unfold
下载
提供使用 django-unfold (v0.56+) 构建高级 Django 管理界面的专业指导。当用户提及 django-unfold、unfold admin 等内容时使用此技能。
- 必须在 ViewSet 的
get_queryset()里加prefetch_related('books') - 如果嵌套里还有嵌套（比如
books里要带publisher），得链式写：prefetch_related('books__publisher') -
select_related只适用于单对象外键（一对一/正向外键），不能用于many=True场景
drf-writable-nested 能省事，但会掩盖数据一致性风险
装了 drf-writable-nested 后，WritableNestedModelSerializer 确实能让嵌套 POST “看起来” 自动生效。但它绕过了你对事务边界和错误回滚的控制。
- 它内部用
atomic包裹整个写入，但失败时抛出的异常是顶层的，你无法单独捕获某条Book创建失败的具体原因 - 如果子对象需要依赖父对象 ID（比如外键不能为空），而父对象还没 commit，它会帮你延迟保存——这在自定义逻辑（如生成 slug、触发信号）时极易出错
- 它不处理部分更新（PATCH）中嵌套字段的“空数组清空关联”语义，容易意外删掉所有子记录
create()，而是没想清楚：这条 API 到底该由谁负责保证最终一致性？是前端校验后分多次提交，还是后端用单事务兜底？这个决策比任何序列化器语法都关键。 
