在微服务架构中，网关作为流量入口，常常需要承担身份认证、权限校验等职责。其中，用户数据权限的传递看似简单，却隐藏着不少兼容性陷阱。本文将结合实际项目经验，聊聊如何解决 Feign 调用时请求头中 JSON 数据的传递问题。

场景再现：数据权限传递的常规思路

在我们的微服务系统中，网关负责解析用户 Token 获取身份信息，同时需要将用户的数据权限（如可访问的部门、资源范围等）传递给下游服务。这些数据权限通常是一个结构化的 JSON 对象，例如：

{"visibleDepts": [1001, 1002, 1003],"allowEdit": true,"maxLevel": 3
}

最初的实现思路很直接：将 JSON 字符串直接放入请求头（Header）中，下游服务从 Header 中读取并解析。代码大概是这样的：

// 网关层设置数据权限
ServerHttpRequest.Builder builder = exchange.getRequest().mutate();
builder.header("data - permission", jsonData);

下游服务通过 Feign 调用其他服务时，也会自动传递这个请求头。看起来一切合理，直到我们遇到了诡异的解析错误。

隐藏的陷阱：Feign 对请求头的特殊处理

在测试环境中，我们发现下游服务经常解析数据权限失败，报错信息多为 “JSON 格式错误”。通过日志排查，我们发现服务收到的 JSON 字符串被篡改了，原始的{“visibleDepts”:…}变成了$“visibleDepts”:…。
为什么会出现这种情况？这要从 Feign 的内部机制说起：
Feign 作为声明式 HTTP 客户端，在处理请求头时会触发表达式解析逻辑。这种机制原本是为了支持类似
${variable}的占位符替换，但它会把 JSON 中的{和}误认为是表达式的开始和结束标记。
具体来说，当 Feign 遇到{字符时，会尝试将其解析为表达式占位符，导致原本的 JSON 结构被破坏：

• 原始 JSON：{“visibleDepts”:[1001]}
• Feign 处理后：$“visibleDepts”:[1001]}（注意开头的{变成了$"）
  这种结构显然不符合 JSON 规范，下游服务自然无法正常解析。

解决方案：压缩 + Base64 转码

既然直接传递 JSON 会被 Feign 的表达式解析逻辑破坏，我们需要一种 “安全” 的传递方式 —— 将 JSON 数据转换为 Feign 不会特殊处理的格式。
最终我们采用了 “压缩 + Base64 转码” 的方案，完整流程如下：

数据处理步骤（网关层）

// 1. 原始JSON字符串
String dataPermission = "{\"visibleDepts\":[1001,1002]}";// 2. 转为字节数组并Gzip压缩（减少体积）
byte[] gzip = ZipUtil.gzip(dataPermission.getBytes(StandardCharsets.UTF_8));// 3. Base64转码（转为纯字母数字字符串）
String dataPermissionBase64 = Base64.getEncoder().encodeToString(gzip);// 4. 设置到请求头
builder.header("data - permission", dataPermissionBase64);

经过处理后，请求头中传递的不再是原始 JSON，而是类似H4sIAAAAAAAAA+3TMQ0AAAwE0L/7K3QnGQ…的 Base64 字符串，这种格式不会被 Feign 的表达式解析逻辑干扰。

数据还原步骤（下游服务）

下游服务需要执行反向操作来还原原始 JSON：

// 1. 从请求头获取Base64字符串
String dataPermissionBase64 = request.getHeader("data - permission");// 2. Base64解码
byte[] gzipData = Base64.getDecoder().decode(dataPermissionBase64);// 3. Gzip解压
byte[] jsonBytes = ZipUtil.unGzip(gzipData);// 4. 转为JSON字符串
String dataPermission = new String(jsonBytes, StandardCharsets.UTF_8);// 5. 解析为对象
PermissionDTO permission = JsonUtil.jsonToObject(dataPermission, PermissionDTO.class);

为什么这种方案有效？

• Base64 编码：将二进制数据转为由 64 个可打印字符（A - Z、a - z、0 - 9、+、/）组成的字符串，不含{、}等特殊字符，避免被 Feign 误解析
• Gzip 压缩：在数据量较大时（如复杂的权限配置），可以显著减少传输体积，提高效率
• 通用性：Base64 和 Gzip 都是标准编码 / 压缩方式，几乎所有编程语言都有成熟的处理库

实践中的注意事项

• 字符编码一致性：无论是网关还是下游服务，都要明确指定 UTF - 8 编码，避免因默认编码不同导致乱码
• 异常处理：
  • 对空值、非法 Base64 字符串、解压失败等情况做容错处理
  • 建议在网关层记录原始数据权限，方便问题排查
• 性能考量：
  • 压缩和解压缩会消耗一定 CPU 资源，对于简单的权限数据可权衡是否需要压缩
  • 可考虑使用线程池异步处理转码操作，避免阻塞网关主线程
• 规范统一：
  • 定义统一的请求头名称（如x - data - permission）
  • 制定转码 / 解码的标准工具类，避免各服务实现不一致

总结

微服务间的数据传递看似简单，却可能因为各组件的特殊机制产生意想不到的问题。Feign 对请求头的表达式解析逻辑导致 JSON 数据传递失败，正是这种 “隐藏规则” 带来的典型问题。
通过 “压缩 + Base64 转码” 的方案，我们成功规避了 Feign 的兼容性问题，同时兼顾了数据传输的安全性和效率。这个案例也提醒我们：在分布式系统中，对于跨服务的数据传递，需要充分考虑中间组件的特性，选择更通用、更稳定的方案。
希望本文的经验能帮助大家在类似场景中少走弯路，让微服务间的 “对话” 更加顺畅。