204响应无响应体，调用text()返回空字符串是规范行为；需先检查status或ok，对204应直接返回null/{}而非调用text()，统一封装解析逻辑并警惕伪204空白字符。
204 No Content 响应本身没有响应体，调用 response.text() 会返回一个空字符串，这不是“解套”问题，而是符合规范的正常行为。所谓“不规范的空响应”，往往指服务端本该返回 200 + 有效文本却错误返回了 204；或前端误判状态码、未检查响应状态就直接调用 text() —— 此时不是 text() 出问题，而是逻辑没兜住。
先确认响应状态是否合理
Fetch 不会自动抛错 2xx/3xx 状态码，必须手动判断：
- 用
response.ok快速检查是否为 200–299 - 或显式比对
response.status === 204，区分“无内容”和“有内容但为空字符串” - 若业务上 204 是合法成功态（如删除接口），就不该调用
text()，直接 resolve 即可
避免对 204 调用 text() 或 json()
204 响应体为空，调用 response.text() 虽不会报错，但返回空字符串容易掩盖逻辑漏洞：
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- 不要写
await response.text()后直接 parse 或 trim 判断——空字符串可能是真数据缺失，也可能是 204 被误处理 - 推荐写法：
if (response.status === 204) return null;或return {};明确语义 - 若必须统一处理响应体，先判断状态码再决定是否读取：
response.status !== 204 && await response.text()
统一响应解析逻辑（推荐封装）
把状态码判断和 body 解析收拢到一个函数里，避免散落各处：
立即学习“Java免费学习笔记（深入）”；
- 对 204：直接 resolve
null或预设值（如{ success: true }） - 对 200/201：按 content-type 尝试
json()或text() - 对非 2xx：抛出自定义错误，含 status 和 url 便于排查
- 示例：
async function safeText(res) { if (res.status === 204) return ''; return res.text(); }
警惕服务端“伪204”——实际返回了空格或换行
极少数后端在 204 响应头里错误塞了空白字符（如空格、\n），导致 text() 返回 "\n" 或 " "，看似“有内容”实则无效：
- 用
str.trim().length === 0替代str === ''判断空值 - 日志中打印
JSON.stringify(str)查看真实内容（避免被控制台隐藏空白符误导） - 必要时加校验：
if (!/^\s*$/.test(await response.text())) throw new Error('Unexpected non-empty 204');
