jwt报无ExpiredSignature，django-grapql-jwt配PyJWT2.0.0如何解决

问题根因 #

该报错属于典型的跨版本依赖不兼容问题：PyJWT 2.0.0 版本对模块内的异常类命名做了破坏性调整，将原1.x版本的ExpiredSignature类重命名为ExpiredSignatureError；但django-graphql-jwt 0.3.1版本的源码中仍然沿用旧版的jwt.ExpiredSignature属性调用逻辑，直接触发模块属性不存在的报错，导致GraphQL认证流程中断。

可落地的解决路径 #

• 生产环境首选：依赖版本对齐
  不要强行绑定PyJWT 2.0.0版本，在项目依赖声明文件中固定与django-graphql-jwt 0.3.1完全兼容的PyJWT 1.7.1版本，示例依赖配置：

  django-graphql-jwt==0.3.1
  PyJWT==1.7.1
  

  该方案不需要修改任何第三方库源码，依赖安装包体积小，适配Docker alpine镜像的轻量化构建要求，也能避免引入其他隐性兼容问题，适合部署在AWS的生产服务场景。
• 需要保留PyJWT 2.0.0特性时：升级第三方库版本
  如果业务必须使用PyJWT 2.0.0提供的安全更新特性，将django-graphql-jwt升级到0.4.0及以上版本。该版本已经完成对PyJWT 2.x的适配，替换了所有旧版异常类的调用逻辑，从根源上解决属性缺失问题。升级时注意核对版本兼容矩阵，避免和当前使用的Graphene、Django版本产生接口冲突。
• 短期快速修复：运行时兼容别名补丁
  如果短期内无法完成依赖版本调整，可以在Django应用的全局初始化流程中（比如应用配置类的ready()方法、全局路由初始化入口）给PyJWT模块注入旧版本的异常类别名，不需要改动第三方库源码即可完成兼容：

  import jwt
  # 为PyJWT 2.x 补全旧版本的异常类兼容别名
  # 逻辑和旧版完全一致，不会改变原有异常捕获流程
  if not hasattr(jwt, "ExpiredSignature"):
      jwt.ExpiredSignature = jwt.ExpiredSignatureError
  

  该补丁本质是给旧的类名做一层映射，不修改原有异常的处理逻辑，不需要调整Docker镜像的构建流程，适合线上问题的临时热修，但不建议作为长期维护方案。

部署提示：在Alpine镜像环境下安装固定版本依赖时，可添加--no-cache-dir参数清理安装缓存，减小最终镜像体积，适配AWS ECS、Lambda等场景的部署要求；固定版本依赖时建议添加哈希校验，避免拉取到被篡改的依赖包。

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