★ FEATURED ARTICLE 1. 项目概述为什么在 Django 里非得用 JWT而不是 Session“django中使用jwt”——这六个字背后藏着过去五年里无数后端开发者踩过的坑、改过的深夜代码、重启过十几次的开发服务器以及被产品经理追着问“登录态怎么又掉了”的尴尬时刻。我第一次在某高校实验室带学生做跨平台教学系统时就栽在这上面前端是 Vue3 写的 PWA 应用移动端用 Flutter 封装后台用 Django 搭建结果一上线iOS 端 Cookie 被 Safari 智能防跟踪机制拦截安卓 WebView 登录态隔两小时自动清空连学生提交实验报告都卡在“请重新登录”页面。我们当时试了 Django 的 SessionMiddleware、试了自定义 Token 认证、甚至临时加了一层 Nginx 透传 header——全都不稳定。直到把认证模块整个抽出来重写成 JWT 方案问题才真正消失。JWTJSON Web Token不是什么新概念但它在 Django 生态里真正落地成熟其实是从 djangorestframework-simplejwt 这个库稳定迭代到 5.x 版本之后才开始的。它解决的从来不是“能不能登录”而是“登录之后身份凭证如何在无状态、跨域、多端、高并发场景下可靠传递”。你不需要懂 RFC 7519 全文但得明白一个标准 JWT 是三段 Base64Url 编码字符串用点号分隔形如xxxxx.yyyyy.zzzzz其中第二段 payload 里默认包含exp过期时间、iat签发时间、jti唯一令牌 ID而这些字段直接决定了你的用户会不会凌晨三点被踢下线、管理员能不能实时吊销某个设备的访问权限、API 网关要不要对高频刷新 token 的请求限流。这个方案适合谁如果你正在做的是前后端分离项目Vue/React/Angular Django REST Framework、需要支持小程序或 App 原生调用、或者未来要拆分成微服务架构那 JWT 就不是“可选项”而是“必选项”。但反过来说如果你只是做一个内部 OA 系统所有用户都在公司内网 IE11 浏览器里打开那真没必要折腾——Django 自带的 Session 机制更省心、更安全、审计日志也更清晰。我见过太多团队为了“技术先进性”硬上 JWT结果连 refresh token 的轮转逻辑都没写对最后反而比 Session 更容易被爆破。所以这篇文章不讲“JWT 多酷炫”只讲在 Django 里怎么把它用对、用稳、用出生产级可靠性。下面所有内容都来自我在三个不同行业教育 SaaS、工业 IoT 平台、医疗数据中台真实项目中的配置记录、压测数据和线上事故复盘。2. 整体设计思路与方案选型为什么选 simplejwt而不是自己手撸或换其他库2.1 不选 Django 默认 Session 的三大硬伤先说清楚为什么放弃原生方案。Django 的SessionMiddleware配合数据库或 Redis 存储 session 数据逻辑清晰、文档完善、安全性有保障但它在现代 Web 架构里存在三个不可忽视的结构性缺陷状态耦合强每个请求必须携带sessionidCookie且后端必须能访问到同一份 session 存储比如 Redis 实例。一旦你把 API 部署到多个可用区或者要做灰度发布就必须确保所有节点共享 session 存储否则用户可能前一秒在 A 节点登录后一秒请求路由到 B 节点就提示未登录。我们曾在一个双机房部署的医疗平台里遇到这个问题杭州机房的 Redis 主从同步延迟偶尔达 800ms导致患者预约成功后跳转个人中心页面时显示“请先登录”。跨域天然受限Cookie 默认不支持跨域携带除非显式设置SameSiteNone; Secure而现代前端工程几乎全是localhost:3000调api.example.com这种模式。虽然可以配CORS_ALLOW_CREDENTIALSTrue和CORS_ALLOWED_ORIGINS但 iOS 15 的 ITPIntelligent Tracking Prevention策略会主动丢弃第三方 Cookie导致登录态在 Safari 下极不稳定。我们做过实测同一套登录流程在 Chrome 下 100% 成功在 Safari 下失败率高达 37%。扩展性差Session 数据存在服务端意味着每次鉴权都要查一次存储。当你的 QPS 上到 5000Redis 成为瓶颈是大概率事件。更麻烦的是你想做“单点登录踢人”功能比如用户在新设备登录旧设备自动下线就得遍历所有 session key 做匹配删除——这在千万级用户量下根本不可行。2.2 为什么是 djangorestframework-simplejwt而不是 PyJWT 或 Authlib市面上能跟 Django 集成的 JWT 方案其实不少但经过三年多的线上验证simplejwt 是目前唯一满足“开箱即用 可控性强 社区活跃”三角平衡的方案。我们对比过三类实现路径方案类型代表实现关键缺陷我们的实测结论纯 PyJWT 手写jwt.encode()jwt.decode()缺少 token 黑名单、refresh 机制、过期自动续期等企业级能力错误处理分散异常类型不统一JWT payload 字段命名不规范比如该用exp却写成expires_at开发周期延长 2.3 倍上线后第 3 天就因 refresh token 未校验jti导致重放攻击漏洞紧急回滚AuthlibOAuth2 风格authlib.integrations.django_oauth2过度设计把简单认证做成 OAuth2 授权码流程需要额外维护 client_id/client_secret前端必须实现 PKCE 流程增加 H5 页面 120KB JS 包体积在教育平台试点时学生用低端安卓机打开登录页平均加载超 8 秒跳出率上升 22%djangorestframework-simplejwtfrom rest_framework_simplejwt.tokens import AccessToken文档略简略部分高级配置需翻源码默认不开启 token 黑名单需手动配TokenBlacklistapp最终选定v5.2.0 版本起内置OutstandingToken和BlacklistedToken模型配合 Celery 定时清理线上稳定运行 18 个月无认证相关故障simplejwt 的核心优势在于它不做任何假设它不强制你用特定用户模型、不绑定特定序列化器、不规定前端必须用某种方式存储 token。它只提供四组基础能力AccessToken用于接口鉴权短时效默认 5 分钟RefreshToken用于换取新 AccessToken长时效默认 1 天SlidingToken滑动过期每次请求自动延长有效期适合长连接场景CookieToken将 token 存入 HttpOnly Cookie兼顾 XSS 防护与便捷性我们最终采用的是AccessToken RefreshToken 组合 Redis 黑名单 自定义用户载荷四件套这套组合在教育平台支撑了日均 120 万次 API 调用平均鉴权耗时 8.3ms压测数据4 核 8G 云服务器QPS 3000P99 延迟 15ms。2.3 架构决策背后的成本计算为什么不用 JWT 做权限控制这里必须划重点JWT 只负责身份认证Authentication绝不承担权限授权Authorization职责。我见过太多项目把user_permissions、groups全塞进 token payload结果 token 体积暴涨到 4KBHTTP header 超出 Nginx 默认large_client_header_buffers限制导致 400 Bad Request 错误频发。我们的做法是token 中只放最精简的认证信息——user_id、email、is_staff是否管理员、jti令牌唯一 ID其余权限数据全部通过User模型关联查询获取。这样做的好处是token 体积控制在 320 字节以内Base64Url 编码后完全适配所有 HTTP 服务器默认配置用户权限变更比如运营同学被移出管理员组能实时生效无需等待 token 过期避免因 token 过大引发的移动端网络传输失败尤其在 2G/弱网环境下。这个决策背后有明确的成本测算每次 API 请求多一次数据库查询SELECT * FROM auth_user WHERE id %s按 3000 QPS 计算MySQL 增加约 1200 次/秒的主键查询远低于单机 MySQL 5.7 的 5000 QPS 瓶颈。而如果把权限塞进 token带来的运维成本监控 token 大小、调优 Nginx、处理移动端兼容性问题是数据库查询成本的 7 倍以上。3. 核心细节解析与实操要点从安装到生产环境的 12 个关键配置3.1 安装与基础配置别跳过 requirements.txt 的版本锁simplejwt 的版本兼容性极敏感尤其是和 Django、djangorestframework 的组合。我们踩过最深的坑是 v4.8.0 与 DRF 3.14.x 的get_serializer_class()方法冲突导致所有视图返回 500 错误。以下是我们在三个项目中验证过的黄金组合# requirements.txt必须锁定小版本 Django4.2.11 djangorestframework3.14.0 djangorestframework-simplejwt5.2.2 PyJWT2.8.0 cryptography41.0.7安装命令必须带-U强制更新依赖树pip install -U -r requirements.txt提示不要用pip install djangorestframework-simplejwt这种裸装方式。simplejwt 依赖cryptography而后者在 CentOS 7 上编译需要gcc、python3-devel、openssl-devel三个系统包漏装会导致ImportError: cannot import name default_backend。我们已在自动化部署脚本中固化检查逻辑# deploy.sh 片段 if ! rpm -q gcc python3-devel openssl-devel /dev/null; then yum install -y gcc python3-devel openssl-devel fi3.2 settings.py 的 7 项必配参数每行都有业务含义这是settings.py中 JWT 相关配置的真实片段已脱敏每一行我都标注了业务含义和不配的后果# JWT 认证配置放在 settings.py 最底部避免被其他配置覆盖 from datetime import timedelta SIMPLE_JWT { # 【关键】AccessToken 过期时间设太短3min会导致前端频繁刷新影响体验 # 设太长15min会增大 token 泄露后的风险窗口。我们取 5 分钟配合前端 4 分半自动刷新。 ACCESS_TOKEN_LIFETIME: timedelta(minutes5), # 【关键】RefreshToken 过期时间必须长于 ACCESS_TOKEN_LIFETIME # 但不宜过长7天以防长期有效凭证被窃取。我们设为 24 小时符合 GDPR 用户数据最小化原则。 REFRESH_TOKEN_LIFETIME: timedelta(hours24), # 【关键】是否启用 token 黑名单生产环境必须为 True # 否则无法实现“退出登录即失效”、“修改密码后旧 token 失效”等安全需求。 ROTATE_REFRESH_TOKENS: True, BLACKLIST_AFTER_ROTATION: True, # 【关键】算法选择HS256 足够安全且性能比 RS256 高 3 倍实测 10w 次签名耗时对比。 # 不要用 HS384/HS512Django 默认 SECRET_KEY 长度仅 50 字符不足以支撑更高强度哈希。 ALGORITHM: HS256, # 【关键】密钥来源绝对禁止写死字符串必须从环境变量读取。 # 我们用 django-environ 库管理本地开发用 .env生产环境用 Kubernetes Secret 挂载。 SIGNING_KEY: env(JWT_SIGNING_KEY, defaultyour-secret-key-change-in-production), # 【关键】用户标识字段默认是 user_id但我们教育平台用邮箱登录 # 所以改成 email避免前端传 user_id 导致鉴权失败。 USER_ID_FIELD: email, USER_ID_CLAIM: email, # 【关键】载荷字段白名单只允许这几个字段进入 payload # 防止恶意用户通过伪造 token 注入非法数据。 TOKEN_TYPE_CLAIM: token_type, JTI_CLAIM: jti, }注意SIGNING_KEY必须与 Django 的SECRET_KEY完全不同我们曾在一个项目中误用同一密钥导致攻击者可通过反向工程SECRET_KEY篡改任意 token获得管理员权限。正确做法是SECRET_KEY用于 Django 内部加密如 session、CSRFJWT_SIGNING_KEY专用于 JWT 签名两者长度、生成方式、轮换策略必须独立。3.3 自定义 Token 类给 payload 加上业务必需字段simplejwt 默认的AccessToken只包含user_id、exp、iat等基础字段。但在实际业务中我们需要更多上下文信息来减少数据库查询。比如教育平台要求前端展示用户头像 URL不能每次请求都查UserProfile表权限判断需知道用户所属学校 ID多租户场景审计日志需记录登录设备类型Web/App/MiniProgram。我们通过继承AccessToken实现自定义# tokens.py from rest_framework_simplejwt.tokens import AccessToken from django.contrib.auth import get_user_model User get_user_model() class CustomAccessToken(AccessToken): def __init__(self, tokenNone, userNone, verifyTrue): super().__init__(token, verifyverify) if user and not token: # 创建 token 时注入业务字段 self[email] user.email self[avatar_url] user.profile.avatar.url if hasattr(user, profile) else self[school_id] getattr(user.profile, school_id, None) self[device_type] getattr(user, last_login_device, web) # 由登录视图设置 classmethod def for_user(cls, user): token super().for_user(user) # 强制添加 jti唯一令牌 ID用于黑名单校验 from rest_framework_simplejwt.state import token_backend token[jti] token_backend._outstanding_token_model.objects.create( useruser, jtitoken[jti], created_attoken.current_time, expires_attoken[exp] ).jti return token然后在settings.py中指向它SIMPLE_JWT[AUTH_TOKEN_CLASSES] (myapp.tokens.CustomAccessToken,)这个设计的关键在于所有业务字段必须是只读、不可变的快照。比如avatar_url是登录瞬间的值后续用户换了头像也不会影响已签发的 token——这正是 JWT “无状态”特性的体现。如果需要实时头像前端应单独调用/api/v1/user/profile/接口。3.4 视图层集成LoginView 的 5 个安全加固点Django REST Framework 的TokenObtainPairView是开箱即用的登录入口但直接暴露会给自动化攻击留下缝隙。我们做了五层加固频率限制防止暴力破解使用django-ratelimit对/api/auth/login/接口限流# views.py from django_ratelimit.decorators import ratelimit class LoginView(TokenObtainPairView): method_decorator(ratelimit(keyip, rate5/m, methodPOST)) def post(self, request, *args, **kwargs): return super().post(request, *args, **kwargs)设备指纹绑定降低 token 泄露风险在登录成功后将user_agentip_address的 SHA256 哈希存入RefreshToken的device_fingerprint字段# serializers.py class TokenObtainPairSerializer(TokenObtainPairSerializer): def validate(self, attrs): data super().validate(attrs) request self.context[request] fingerprint hashlib.sha256( f{request.META.get(HTTP_USER_AGENT, )}_{get_client_ip(request)}.encode() ).hexdigest() refresh self.get_token(self.user) refresh[device_fingerprint] fingerprint data[refresh] str(refresh) data[access] str(refresh.access_token) return data密码强度二次校验即使 token 被盗也无法用弱密码重置在validate()中加入 zxcvbn 密码强度检测from zxcvbn import zxcvbn result zxcvbn(attrs[password]) if result[score] 3: # 0-4 分3 分以上为强密码 raise serializers.ValidationError(密码强度不足请使用更复杂的密码)登录成功回调记录关键审计日志重写create_token_response()方法写入 Elasticsearchdef create_token_response(self, validated_data): response super().create_token_response(validated_data) # 记录到审计日志用户ID、IP、User-Agent、设备类型、登录时间 audit_log { event: user_login, user_id: self.user.id, ip: get_client_ip(self.context[request]), user_agent: self.context[request].META.get(HTTP_USER_AGENT), device_type: detect_device_type(self.context[request]), timestamp: timezone.now().isoformat() } es.index(indexaudit-log-2024, bodyaudit_log) return response响应体精简避免泄露敏感信息默认响应包含refresh和access两个 token但我们教育平台要求refresh只通过 HttpOnly Cookie 返回access通过 JSON body 返回def post(self, request, *args, **kwargs): serializer self.get_serializer(datarequest.data) serializer.is_valid(raise_exceptionTrue) tokens serializer.validated_data # 将 refresh token 写入 HttpOnly Cookie response Response({access: tokens[access]}) response.set_cookie( keyrefresh_token, valuetokens[refresh], httponlyTrue, secureTrue, # 仅 HTTPS samesiteLax, max_age24*3600 ) return response4. 实操过程与核心环节实现从开发到上线的完整链路4.1 开发环境搭建本地调试的 3 个必备技巧在本地DEBUGTrue环境下JWT 调试最容易陷入“token 无效但不知道哪错了”的死循环。我们总结出三个高效定位法技巧一用 curl 模拟完整登录-请求链路不要依赖 Postman 图形界面用终端命令直击本质# 1. 获取 token注意 -v 查看详细响应头 curl -v -X POST http://localhost:8000/api/auth/login/ \ -H Content-Type: application/json \ -d {email:testexample.com,password:123456} # 2. 用返回的 access token 请求受保护接口 curl -v -X GET http://localhost:8000/api/v1/user/profile/ \ -H Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9... # 3. 如果失败用 jwt.io 粘贴 token手动检查 payload 中的 exp、email、jti 字段技巧二在 Django shell 中手动解码 token当怀疑是签名密钥不一致时绕过框架直接验证 from rest_framework_simplejwt.tokens import AccessToken from rest_framework_simplejwt.exceptions import InvalidToken, TokenError try: ... token AccessToken(eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...) ... print(token.payload) # 查看原始 payload ... except (InvalidToken, TokenError) as e: ... print(f解码失败{e})技巧三启用 simplejwt 的 DEBUG 日志在settings.py中添加LOGGING { version: 1, disable_existing_loggers: False, handlers: {console: {class: logging.StreamHandler}}, loggers: { rest_framework_simplejwt: { handlers: [console], level: DEBUG, }, }, }这样每次 token 验证失败时控制台会输出类似Token has wrong type: refresh或Token is blacklisted的精准错误比看 500 页面高效十倍。4.2 生产环境部署Nginx Gunicorn 的 4 个关键配置当项目上线Nginx 成为第一道网关很多 JWT 问题其实出在反向代理配置上。以下是我们在阿里云 ECSCentOS 7上验证过的最小可行配置Nginx 配置片段/etc/nginx/conf.d/myapp.confupstream django_app { server 127.0.0.1:8000; } server { listen 443 ssl http2; server_name api.example.com; # 【关键】必须透传 Authorization header否则 Django 收不到 Bearer token proxy_set_header Authorization $http_authorization; # 【关键】修复 iOS Safari 的 Cookie 问题显式设置 SameSiteLax proxy_cookie_path / /; SameSiteLax; Secure; location / { proxy_pass http://django_app; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; # 【关键】增大 header 缓冲区避免 JWT 超长被截断 large_client_header_buffers 4 16k; client_max_body_size 100M; } }Gunicorn 配置gunicorn.conf.py# 【关键】禁用 gunicorn 的 accesslog避免日志中明文记录 token accesslog None errorlog /var/log/gunicorn/error.log capture_output True # 【关键】worker 数量 CPU 核数 × 2 1我们 4 核机器设为 9 workers 9 worker_class sync worker_connections 1000 timeout 30 keepalive 5 # 【关键】启用 preload避免每个 worker 重复加载 JWT 密钥 preload True注意proxy_set_header Authorization $http_authorization;这一行极其重要。Nginx 默认不会透传Authorizationheader必须显式声明。我们曾因漏掉这行导致所有生产环境请求都返回 401排查了 6 小时才发现是 Nginx 配置问题。4.3 Token 生命周期管理Refresh 流程的 3 种实现模式JWT 的最大陷阱不是“怎么签发”而是“怎么续期”。我们实践过三种模式最终选定第三种模式一前端定时刷新不推荐前端用setInterval每 4 分钟调一次/api/auth/refresh/。问题用户关闭浏览器标签页后定时器仍在运行造成无效请求多个标签页同时刷新导致 refresh token 被消耗两次第二次请求失败。模式二请求拦截自动刷新推荐但需谨慎在 Axios 请求拦截器中捕获 401 响应自动用 refresh token 换新 access token再重发原请求// axios.js instance.interceptors.response.use( response response, async error { const originalRequest error.config; if (error.response?.status 401 !originalRequest._retry) { originalRequest._retry true; try { const refresh Cookies.get(refresh_token); const res await axios.post(/api/auth/refresh/, { refresh }); Cookies.set(access_token, res.data.access, { expires: 1/48 }); // 30分钟 originalRequest.headers.Authorization Bearer ${res.data.access}; return instance(originalRequest); } catch (e) { // 刷新失败跳转登录页 window.location.href /login/; } } return Promise.reject(error); } );这个方案的问题是如果用户长时间不操作refresh token 过期前端无法感知直到下次点击才跳登录页。用户体验割裂。模式三后端静默续期我们最终采用在 Django 中间件里对每个成功请求2xx 响应检查 access token 是否将在 60 秒内过期如果是则生成新 token 并通过Set-Cookie返回# middleware.py class JWTRefreshMiddleware: def __init__(self, get_response): self.get_response get_response def __call__(self, request): response self.get_response(request) if response.status_code 200 and hasattr(request, user) and request.user.is_authenticated: # 解析当前 access token auth_header request.META.get(HTTP_AUTHORIZATION, ) if auth_header.startswith(Bearer ): token_str auth_header[7:] try: token AccessToken(token_str) # 如果剩余寿命 60 秒静默刷新 if token[exp] - time.time() 60: new_token AccessToken.for_user(request.user) response.set_cookie( keyaccess_token, valuestr(new_token), httponlyTrue, secureTrue, samesiteLax, max_age300 # 5分钟 ) except Exception: pass return response这个方案的优势用户无感知token 始终保持“新鲜”前端无需处理复杂逻辑服务端完全可控。代价是每次请求增加约 0.8ms 的 JWT 解析开销但相比用户体验提升完全值得。4.4 安全加固实战应对 3 类真实攻击场景场景一Refresh Token 被窃取后的横向移动攻击者通过 XSS 获取到refresh_tokenCookie然后不断调用/api/auth/refresh/获取新 access token。我们的防御是在TokenRefreshView中每次使用 refresh token 后立即将其加入黑名单from rest_framework_simplejwt.views import TokenRefreshView from rest_framework_simplejwt.exceptions import TokenError class SecureTokenRefreshView(TokenRefreshView): def post(self, request, *args, **kwargs): try: # 先校验 refresh token 是否有效且未被吊销 refresh RefreshToken(request.data[refresh]) # 使用后立即加入黑名单 refresh.blacklist() except TokenError: raise InvalidToken(Token is invalid or expired) return super().post(request, *args, **kwargs)同时在settings.py中开启ROTATE_REFRESH_TOKENSTrue确保每次刷新都生成新 refresh token旧 token 失效。场景二JWT 签名密钥泄露后的应急响应当发现JWT_SIGNING_KEY可能泄露如误提交到 GitHub必须立即轮换。我们的 SOP 是生成新密钥openssl rand -hex 32更新 K8s Secret并滚动重启所有 Django Pod执行数据库清理DELETE FROM token_blacklist_outstandingtoken WHERE created_at NOW() - INTERVAL 24 HOURS;通知前端强制登出所有用户通过 WebSocket 广播场景三重放攻击Replay Attack攻击者截获一个合法 access token在过期前反复使用。我们的防护是启用jti字段并在CustomAccessToken的__init__中强制写入import uuid self[jti] str(uuid.uuid4())在TokenVerifyView中检查jti是否已在OutstandingToken表中存在即是否已被使用过from rest_framework_simplejwt.views import TokenVerifyView from rest_framework_simplejwt.exceptions import InvalidToken class AntiReplayTokenVerifyView(TokenVerifyView): def post(self, request, *args, **kwargs): token request.data.get(token) try: decoded AccessToken(token) jti decoded[jti] # 检查 jti 是否已存在即是否被重放 if OutstandingToken.objects.filter(jtijti).exists(): raise InvalidToken(Token has been replayed) except Exception: pass return super().post(request, *args, **kwargs)5. 常见问题与排查技巧实录来自线上环境的 15 个真实案例5.1 Token 无效的 7 种原因及速查表现象可能原因快速验证方法解决方案401 Unauthorizedexp字段时间戳早于当前时间时钟不同步在 Django shell 中执行from datetime import datetime; print(datetime.now())对比服务器时间和 token 中exp统一所有服务器使用 NTP 时间同步systemctl enable chronyd systemctl start chronyd401 Unauthorizeduser_id字段在数据库中不存在用户被删除SELECT * FROM auth_user WHERE id token中user_id;在CustomAccessToken.for_user()中加入user.is_active检查非激活用户不发 token401 Unauthorizedjti字段对应的OutstandingToken已被标记为blacklistedSELECT * FROM token_blacklist_blacklistedtoken WHERE jti token_jti;清理黑名单表中过期记录DELETE FROM token_blacklist_blacklistedtoken WHERE blacklisted_at NOW() - INTERVAL 7 DAYS;401 Unauthorizeduser_id类型不匹配token 中是字符串数据库中是整数print(type(token[user_id]), type(User.objects.get(idtoken[user_id]).id))在settings.py中设置USER_ID_FIELD: id并确保id字段是整数类型400 Bad Requesttoken 字符串过长超出 Nginxlarge_client_header_bufferscurl -v -H Authorization: Bearer $(head -c 4096 /dev/urandom | base64) http://localhost/在 Nginx 配置中增加large_client_header_buffers 4 16k;401 UnauthorizedAuthorizationheader 未被 Nginx 透传print(request.META.get(HTTP_AUTHORIZATION))在视图中打印在 Nginx 配置中添加proxy_set_header Authorization $http_authorization;500 Internal Server ErrorJWT_SIGNING_KEY包含特殊字符如换行符导致 PyJWT 解析失败echo $JWT_SIGNING_KEY | hexdump -C检查是否有0a换行用tr -d \n\r清理环境变量或改用 base64 编码密钥5.2 前端集成的 5 个典型问题问题1Vue3 中 useRoute() 获取不到 token现象在路由守卫中router.beforeEachlocalStorage.getItem(access_token)返回 null。原因token 存在 HttpOnly Cookie 中JavaScript 无法读取。解决方案后端在登录成功响应中额外返回access字段非 Cookie前端存入 localStorage# serializers.py def validate(self, attrs): data super().validate(attrs) refresh self.get_token(self.user) data[access] str(refresh.access_token) data[refresh] str(refresh) # 仍通过 Cookie 返回 return data问题2Axios 请求头 Authorization 不生效现象axios.defaults.headers.common[Authorization] Bearer xxx设置后请求仍无 header。原因defaults.headers.common在创建实例后被覆盖。解决方案创建专用实例const apiClient axios.create({ baseURL: /api, headers: { Authorization: Bearer ${localStorage.getItem(access_token)} } });问题3Safari 下 Cookie 丢失现象iOS Safari 登录后后续请求无 Cookie。原因Safari 的 ITP 策略阻止第三方 Cookie且SameSiteLax在重定向场景下不发送。解决方案后端返回Set-Cookie时显式指定SameSiteNone; Secureresponse.set_cookie( keyaccess_token,
阅读完成 · 觉得有帮助？
