DRF的RetrieveUpdateDestroyAPIView与get_queryset运行原理疑问

你不需要手动在get_queryset中添加pk过滤条件，是因为DRF的RetrieveUpdateDestroyAPIView通用视图已经内置了根据路径参数筛选单条数据的逻辑，这部分能力不需要开发者自行实现。

我们可以把单条资源请求（查询/更新/删除）的完整处理流程拆解为以下几步：

1. 路由匹配成功后，请求进入RetrieveUpdateDestroyAPIView对应的处理方法
2. 视图首先调用你重写的get_queryset方法，得到当前登录用户关联的所有Todo对象的查询集，这一步的作用是做全局范围限制，保证后续所有操作都只能在当前用户的私有资源范围内执行，天然避免了越权访问其他用户数据的问题
3. 之后视图自动调用内置的get_object()方法完成单条数据的筛选：
   • 读取第一步得到的用户专属查询集作为基础筛选范围
   • 自动从路径参数中提取pk值（如果你自定义了lookup_field配置，就会读取对应字段的参数）
   • 自动在基础查询集上追加pk=路径传入值的过滤条件，尝试查询唯一匹配的对象
   • 如果查询不到匹配对象直接返回404响应，查询到就返回该对象交给后续逻辑处理
4. 最后将得到的单个Todo对象传入序列化器，处理完成后返回给前端

你当前的写法其实是DRF单用户资源接口的标准实现，既不需要手动处理pk筛选，也额外实现了用户资源的权限隔离，完全符合规范。

内容的提问来源于stack exchange，提问作者Diqosh