acceptheaderversioning要求accept头严格为“media-type; version=xxx”格式，因它仅匹配分号后带空格的version参数；格式不符则request.version为none，需配置default_versioning_class、default_version、allowed_versions和version_param才生效。
直接用 AcceptHeaderVersioning，但必须确保客户端请求头里带 Accept: application/json; version=v1 这种格式，否则 request.version 会是 None 或触发 404。
为什么 Accept 头格式必须严格匹配？
AcceptHeaderVersioning 不解析任意键值对，它只从 Accept 请求头中提取 version=xxx 这个子串，且前提是整个头值符合 media-type; param=value 结构。常见错误包括：
- 发
Accept: v1→ 解析失败，request.version为None - 发
Accept: application/json, version=v1（逗号分隔）→ 不识别，跳过 - 发
Accept: application/json;v=v1（缺少空格、参数名不对）→ 匹配不上version键
正确写法只有：Accept: application/json; version=v1 或 Accept: text/html; version=v2 —— 分号后必须有空格，且 version= 是独立参数。
settings.py 配置要点
全局启用时，REST_FRAMEWORK 中这几项不能少：
'DEFAULT_VERSIONING_CLASS': 'rest_framework.versioning.AcceptHeaderVersioning'-
'DEFAULT_VERSION': 'v1'（当请求头没提供版本时 fallback 的值） -
'ALLOWED_VERSIONS': ['v1', 'v2']（必须显式声明，否则非默认版本会报NotFound） -
'VERSION_PARAM': 'version'（虽然 header 模式不依赖 URL 参数，但该配置仍被底层校验逻辑读取）
注意：VERSION_PARAM 在 header 模式下不用于解析，但它参与 is_allowed_version() 校验，漏配会导致合法版本被拒绝。
视图里怎么安全读取和分支？
request.version 可能为 None（解析失败）、字符串（如 'v1'）或 'v1' 以外的非法值（已通过 ALLOWED_VERSIONS 拦截）。实际判断建议：
- 不要直接写
if request.version == 'v1'—— 先确认不是None - 用
if request.version in ('v1', 'v2')更稳妥，避免拼写错误 - 序列化类切换示例：
def get_serializer_class(self): if self.request.version == 'v2': return UserSerializerV2 return UserSerializerV1
另外，request.versioning_scheme 是 AcceptHeaderVersioning 实例，可用于反向生成兼容 header 的 URL（极少用，但调试时可查 request.versioning_scheme.reverse(...)）。
调试时怎么快速验证 header 是否生效？
在视图 get() 开头加一行：
print(f"Accept header: {request.META.get('HTTP_ACCEPT')}")
print(f"Resolved version: {request.version}")然后用 curl 测试：curl -H "Accept: application/json; version=v2" http://localhost:8000/api/users/如果输出
Resolved version: v2 就说明通了。如果仍是 None，90% 是 header 格式或空格问题。
真正容易被忽略的是：header 版本控制完全依赖客户端配合，服务端无法“强制”客户端发正确头；一旦前端 SDK 或网关层改写 Accept，整个版本路由就失效 —— 所以生产环境建议搭配日志监控 request.version is None 的请求比例。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
