Dio请求AccessToken接口返回500错误排查求助

核心问题梳理 #

项目中部分API依赖JWT（Authorization: Bearer <JWT>）、部分依赖AccessToken（AccessToken头），接口支持同时携带双Token。目前JWT接口正常，AccessToken接口返回500；已确认Token值正确，且Postman中调用正常。

可能的问题点及修复方案 #

1. AccessToken空值处理不当 #

代码中直接调用cognitoToken.toString()，若cognitoToken为null，会生成字符串"null"，导致后端接收到无效Token值（Postman中不会传该无效值）。

修复代码：

// 在BaseOptions初始化时修改
headers: {
  'Authorization': 'Bearer $_cachedToken',
  'AccessToken': AppData().appModel.cognitoToken?.toString() ?? '',
},

// 在拦截器中修改
options.headers['AccessToken'] = AppData().appModel.cognitoToken?.toString() ?? '';

2. 异步初始化导致Token未就绪 #

_initializeNetworkHelper是异步方法，但私有构造函数同步调用它，会导致初始化阶段cognitoToken可能未从存储/业务逻辑中加载完成，初始请求的AccessToken为空或无效。

修复代码：

class NetworkHelper {
  // 新增初始化状态标记
  static bool _isInitialized = false;

  // 修改单例获取方式为异步
  static Future<NetworkHelper> get instance async {
    if (!_isInitialized) {
      await _instance._initializeNetworkHelper();
      _isInitialized = true;
    }
    return _instance;
  }

  // ... 其他代码不变
}

// 调用时需await
final networkHelper = await NetworkHelper.instance;

3. 请求头命名/大小写不匹配 #

后端可能对请求头大小写敏感，比如实际期望access-token而非AccessToken，需对比Postman的请求头名称，确保完全一致（包括大小写、连字符等）。

4. 拦截器头覆盖逻辑冲突 #

拦截器中强制覆盖options.headers字段，若存在其他自定义头设置，可能引发冲突。建议打印完整请求头，与Postman请求头逐字段对比，排查差异。

5. Token传递方式错误 #

核对Postman中AccessToken的传递方式：是否是放在AccessToken头？还是需要添加前缀（如Bearer ）、或放在Authorization头中？若代码中的传递方式与后端要求不符，会导致解析失败。

验证步骤 #

1. 抓包对比：用Charles/Proxyman抓取App请求与Postman请求，对比请求头全量字段，定位差异。
2. 极简测试：编写仅携带AccessToken的极简Dio请求，单独测试目标接口，逐步排除变量。
3. 后端日志：查看后端500错误的具体栈信息，直接定位Token解析或校验失败的原因。

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