直接手动拼接字典不靠谱，因重复、易错、难维护，且异常路径（如400/401/403）返回格式与正常响应不一致；自定义jsonrenderer可在渲染阶段统一包装code/data/msg结构，覆盖render()方法、依赖response.status_code判别状态、兼容错误类型并归一化data字段，需按需局部注册避免影响html/csv等非json响应。
为什么直接在视图里写 {'code': 0, 'data': ..., 'msg': 'ok'} 不靠谱
因为重复、易错、难维护——每个 APIView 或 ViewSet 都手动拼字典，一旦字段名变更（比如把 msg 改成 message），就得全局搜改；更麻烦的是异常路径（如权限拒绝、参数校验失败）往往被忽略，返回的仍是 DRF 默认的 400 Bad Request 原始错误结构，和正常响应格式不一致。
自定义 JSONRenderer 的关键三步
DRF 的渲染器链在序列化后、响应发出前介入，是统一包装响应的最佳位置。你不需要重写整个渲染逻辑，只需继承 JSONRenderer 并覆盖 render() 方法：
- 先调用父类
render()得到原始 JSON 字节（注意：此时已是bytes，需先解码为str再转dict） - 判断原始内容是否为错误响应（比如含
'detail'或状态码非2xx）——但更稳妥的方式是依赖renderer_context['response'].status_code - 构造统一结构：
{'code': ..., 'data': ..., 'msg': ...}，再用json.dumps()编码回bytes
示例精简版：
from rest_framework.renderers import JSONRenderer import json <p>class StandardJSONRenderer(JSONRenderer): def render(self, data, accepted_media_type=None, renderer_context=None): response = renderer_context['response']</p><h1>正常成功响应：data 是序列化后的 dict/list</h1><pre class="brush:python;toolbar:false;"> if 200 <p></p>
注册渲染器时必须注意的两个坑
很多人把自定义渲染器加到 DEFAULT_RENDERER_CLASSES 就以为完事了，结果发现 TemplateHTMLRenderer 或文件下载接口出问题——因为所有响应（包括 HTML 页面、CSV 导出）都会走这个渲染器。
- 只对 API 接口生效：在视图类或视图集上显式指定
renderer_classes = [StandardJSONRenderer]，而不是全局配置 - 兼容其他格式：如果你的项目同时提供 JSON 和 CSV 接口，
StandardJSONRenderer必须只处理application/json，其他类型应 fallback 到默认链。可在render()开头加判断：if not renderer_context['request'].accepts == 'application/json': return super().render(...)
如何让 ValidationError 错误也走统一格式
DRF 默认把 serializers.ValidationError 渲染成扁平 key-value 结构（如 {'email': ['Enter a valid email.'] }），这和你的 data 字段预期类型（通常为 object 或 null）不一致，前端解析容易报错。
- 在自定义渲染器中识别
data是否为dict且含字段级错误，可做一层归一化：提取第一个错误信息作为msg，把整个错误对象挂到data下 - 更彻底的方案是在
APIView.dispatch()中捕获异常并重写response.data，但侵入性太强；推荐在渲染器里处理，保持关注点分离 - 别忘了测试 401/403 这类认证异常——它们的
data是字符串（如'Authentication credentials were not provided.'），需转成dict再包裹
统一响应这件事，最难的不是写代码，而是想清楚哪些响应该包、哪些不该包，以及错误信息到底该暴露多少给前端。漏掉一个异常分支，线上就可能出现两种格式混杂的情况。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
