FHIR服务返回的带长度字符串@Slf4j日志打印为空白是什么原因

算力阿峰

2026-10-2

问题原因分析

该现象的核心逻辑是字符串本身包含完整有效内容，但日志渲染端执行了内容中的特殊指令/做了特殊过滤，导致视觉上不可见，常见原因如下：

响应携带ANSI终端转义控制序列
不少开启了调试模式的FHIR服务返回的响应会嵌入ANSI控制字符，比如用于设置终端字体颜色的\033[30m（黑色字体，若控制台背景为黑就完全不可见）、用于重置光标位置的\r（回车符，将光标移到行首后后续日志内容会覆盖当前输出）、用于清空行的\033[2K等。这类字符会被终端/本地日志控制台识别为控制指令执行，不会渲染为可见文本，你复制内容时终端会直接导出原始字节，因此粘贴后可以看到完整内容。
排查代码参考：
```
// 打印每个字符的Unicode编码确认是否存在特殊控制符
for (char c : responseStr.toCharArray()) {
    System.out.printf("字符: %c, 编码: 0x%04X%n", c, (int)c);
}
```
如果输出中存在0x1B（ESC控制符的ASCII码）、0x0D（\r的ASCII码）即可确认是该问题。
网页版日志平台自动渲染了响应中的HTML标签
FHIR标准支持返回xhtml格式的人类可读渲染结果，响应中可以合法携带HTML标签。如果你的日志是在网页版的日志管理平台查看，平台默认会把内容当作HTML代码解析，比如<div style="display:none">、<script>这类标签会被直接渲染为DOM元素，视觉上不会显示原始文本。你复制网页内容时浏览器会自动提取元素的原始文本，粘贴到文档后就能看到完整的字符串内容。
响应包含大量零宽不可见Unicode字符
部分编码异常的FHIR响应会携带零宽空格（U+200B）、零宽不折行空格（U+FEFF）、软连字符（U+00AD）这类不可见的特殊Unicode字符，这类字符渲染时不占任何显示宽度，视觉上和空白完全一致，但实际会占用字符长度，复制时也会被完整携带，粘贴到支持显示不可见字符的编辑器中就会显示所有内容。