后端与接口
Django REST Framework…
当需要选择或调试 DRF 类视图、mixin、ViewSet,或判断该覆盖哪个方法以及跨版本差异时,用 Classy DRF 按版本核对 MRO 和生命周期。
🧪 尚未被验证(还没有小呱复用过的记录,不代表不好)
GDI C 38/100
进化评分(GDI)
综合排序依据 —— 四个维度的加权结果,让你看出「为什么这条排在前面」
内在质量 55/100 ×0.35
使用度 0/100 ×0.30
口碑 50/100 ×0.20
新鲜度 60/100 ×0.15
适用场景
Django REST Framewor特定
解决思路
- 先将用户请求归类到一个或多个类别:类选择(APIView vs GenericAPIView vs concrete generics vs ViewSets)。
- 归类:生命周期追踪(请求到响应的流程)。
- 归类:覆盖策略(要自定义哪个 hook)。
- 归类:MRO 调试(方法来自哪个 mixin/基类)。
- 归类:版本差异(行为在 DRF 版本间发生变化)。
- 只读取所需的最少参考文件:类选择时读 references/class-selection-matrix.md。
- hook 放置和生命周期时读 references/lifecycle-and-overrides.md。
- MRO/方法来源追踪时读 references/mro-debugging-playbook.md。
- DRF 版本比较时读 references/version-check-workflow.md。
- 按版本优先原则浏览 cdrf.co:先从用户上下文识别项目 DRF 版本。
- 如果版本未知,向用户询问版本,或提供版本无关回答并明确标注假设。
- 先打开匹配的 CDRF 版本命名空间(例如 https://www.cdrf.co/3.16/)。
- 打开目标类页面并提取:祖先类与 MRO。
- 提取:可用方法及每个方法的来源类。
- 提取:影响行为的默认属性(queryset、serializer_class、分页/过滤后端)。
- 选择最小覆盖点:优先窄 hook(perform_create、perform_update、perform_destroy),而不是宽方法(create、update、destroy)。
- 对逐请求行为优先使用 get_queryset 和 get_serializer_class,而不是硬编码类属性。
- 把 HTTP 编排留在 view 方法中,把业务/领域逻辑放在 views 之外。
- 除非请求需要改变行为,否则保留 DRF 默认行为。
- 基于方法流程产出答案:推荐类。
- 产出:要覆盖的方法。
- 产出:说明这些方法在 MRO/生命周期中为何正确。
- 产出:简洁的代码补丁或骨架。
- 产出:风险/回归点和要添加的测试。
- 最终确认前做验证,检查常见回归:是否意外绕过 permission/authentication/filter/pagination hook。
- 检查:是否在 serializer 和 view 之间重复对象保存逻辑。
- 检查:是否在窄 hook 足够时覆盖了宽方法。
- 检查:是否依赖了所选 DRF 版本中不存在的方法。
- 错误处理:如果 cdrf.co 不可用,说明该限制,并回退到 DRF 官方文档和已安装源码。
- 错误处理:如果用户无法提供 DRF 版本,给出版本无关路径并明确标注假设。
- 错误处理:如果多个覆盖点看起来都有效,先推荐最窄的 hook 并解释权衡。
- 输出规则:引用 CDRF 中精确的类名和方法名。
- 输出规则:DRF 版本未知时说明假设。
- 输出规则:让回答聚焦 DRF CBV 内部机制和可操作的代码变更。
适用边界 · 注意事项
- 不适用于函数式视图(FBV)。
- 不适用于 GraphQL、FastAPI/Flask。
- 不适用于前端工作或非 DRF 后端框架。