动态序列化器需在正确层级实现字段控制：get_fields()用于根据上下文动态增删字段，SerializerMethodField用于计算字段值，to_representation()仅作输出格式调整。
动态序列化器不是靠“写得更灵活”实现的，而是靠在运行时控制字段生成逻辑——关键在于重写 get_fields() 或利用 SerializerMethodField、to_representation() 等钩子，而不是堆砌条件判断。
什么时候必须重写 get_fields()
当你需要根据请求上下文（比如用户权限、URL参数或 query string）动态增删字段，且这些字段无法用 read_only_fields 或 exclude 静态配置时，get_fields() 是唯一可靠入口。它在序列化器实例化时被调用，早于任何数据处理，是字段层的“第一道闸门”。
- 常见错误：在
__init__里直接 pop 字段或修改self.fields—— 此时字段已由get_fields()构建完成，后续行为不可预测，尤其在嵌套序列化或批量序列化时容易漏字段 - 正确做法：继承
ModelSerializer，重写get_fields()，先调用super().get_fields()获取原始字段字典，再按需过滤或注入 - 注意
context可用：该方法接收self，而self.context已被视图传入（如{'request': request}），可安全读取request.user或request.query_params
SerializerMethodField 适合计算型字段，不适合开关型字段
SerializerMethodField 的作用是“按需计算值”，不是“按需存在字段”。它始终会出现在输出中（除非你手动在 to_representation() 里删掉），只是值可能为 None。把它当字段开关用，会误导前端预期，也违背 REST 的可预测性原则。
- 适用场景：字段值依赖模型其他字段（如
full_name拼接）、需查库（如统计关联数量）、或需调用外部服务（如校验第三方 ID） - 不适用场景：管理员看全部字段、普通用户只看部分字段——这种权限级字段控制应走
get_fields()或视图层字段白名单 - 性能陷阱：每个
SerializerMethodField方法会在每个序列化对象上执行一次；若用于列表页且方法含数据库查询，N+1 问题立刻出现
to_representation() 是最后的数据出口，不是字段定义层
to_representation() 接收已构建好的字段字典，返回最终输出。它适合做格式微调（如日期转字符串、拼接 URL）、字段重命名、或基于对象状态隐藏整个字段（如草稿状态下不返回 publish_time）。但它不能改变字段定义本身——比如你没在 get_fields() 里声明 status_detail，to_representation() 就拿不到这个 key。
- 典型误用：在
to_representation()里临时加字段（如data['is_owner'] = obj.owner == self.context['request'].user）——这会让字段来源混乱，难以测试和复用 - 推荐替代：这种布尔标记更适合用
SerializerMethodField显式声明，语义清晰且可被 DRF 文档工具识别 - 兼容性注意：若你覆盖了
to_representation()却忘了调用super()，所有默认字段（包括id、created_at）都会消失
真正难的不是写动态逻辑，而是决定在哪一层做裁剪：字段存在性（get_fields）、字段值计算（SerializerMethodField）、还是字段呈现（to_representation）。选错层级，轻则增加维护成本，重则引发缓存不一致或前端解析失败。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
