很多问题不是接口逻辑错，而是缓存、Cookie、鉴权头或 `Content-Type` 设错了。
开发辅助
HTTP Header 解析器
把请求头或响应头整理成结构化 JSON 和字段表，适合排查 `Content-Type`、缓存、鉴权、Cookie 和重复 Header。
请求头 / 响应头结构化重复 Header 自动归并适合缓存和鉴权排查
直接解析 Header
输入原始 Header 后，系统会拆出首行、字段、重复项和常见缓存 / 内容类型信息。
支持重复 Header 合并成数组，也会保留 Set-Cookie 这类重复字段。
- 类型
- 响应头
- 字段数量
- 5
- 重复字段
- 1
- Content-Type
- application/json; charset=utf-8
- Cache-Control
- public, max-age=300
- Cookie 字段
- 2
首行：HTTP/1.1 200 OK
字段名值备注
content-typeapplication/json; charset=utf-8单字段
cache-controlpublic, max-age=300单字段
x-request-idreq_1a2b3c单字段
set-cookievisit=first; Path=/; HttpOnly重复字段
set-cookiesource=seo; Path=/重复字段
特别适合排查静态资源异常、接口鉴权失败、重复 Set-Cookie 和缓存命中问题。
Header 看完之后，通常还要继续对照状态码和资源类型，才能真正缩小问题范围。
为什么要把 Header 结构化
原始 Header 看起来像纯文本，但排查时更需要字段级别的视角，尤其是重复键和缓存相关字段。
- 把 Header 结构化成 JSON 后，更适合复制给后端、测试或日志平台继续查。
- `Set-Cookie`、`Cache-Control`、`Authorization` 这类字段很容易在原文里被埋没。
- 如果只是人工扫一遍纯文本，很难一眼看出重复字段和真正影响行为的关键头。
实际演示
示例输入输出
示例覆盖请求头和响应头两种结构化结果，适合看缓存、Cookie、Content-Type 和重复字段。
示例 1
响应头结构化
适合把 CDN、接口或资源响应头快速转成 JSON，再继续贴给后端或日志系统分析。
输入
Header 输入
HTTP/1.1 200 OK Content-Type: application/json; charset=utf-8 Cache-Control: public, max-age=300 Set-Cookie: visit=first; Path=/ Set-Cookie: source=seo; Path=/
键名模式
输出 JSON 小写
输出
结构化 JSON
{
"content-type": "application/json; charset=utf-8",
"cache-control": "public, max-age=300",
"set-cookie": [
"visit=first; Path=/",
"source=seo; Path=/"
]
}解析摘要
响应头 4 个 · 重复字段 1 个
示例 2
请求头结构化
适合把抓包工具里的请求头整理成字段表，快速核对 Authorization、Cookie 和 Accept。
输入
Header 输入
POST /v1/palettes HTTP/1.1 Host: api.tobecolor.com Content-Type: application/json Authorization: Bearer demo-token Cookie: session=demo123
键名模式
保留原始大小写
输出
结构化 JSON
{
"Host": "api.tobecolor.com",
"Content-Type": "application/json",
"Authorization": "Bearer demo-token",
"Cookie": "session=demo123"
}解析摘要
请求头 4 个
规则说明
HTTP Header 解析器适合把请求头或响应头结构化成字段表和 JSON，重点是把重复键、缓存键和鉴权键分开看。
- 支持常见的请求行和状态行识别，也支持只粘贴纯 Header 字段。
- 像 `Set-Cookie` 这类重复 Header 会被合并成数组，避免丢失真实返回结果。
- 结构化 JSON 更适合继续贴给后端、日志系统或工单，而不是直接拿去当原始请求发送。
常见误区
最常见的问题不是记不住 Header 名称，而是无法快速判断哪个字段真的在影响缓存、鉴权或资源返回。
- 只看纯文本时，最容易忽略 `Cache-Control`、`Content-Type`、`Authorization` 和重复 Cookie。
- 请求头和响应头职责不同，不能把它们混在一起按同一套思路理解。
- 字段值很长时，最好结构化后再分享，否则联调沟通里容易复制错或漏值。
结果解释
结果区会同时给出首行、结构化 JSON、字段表和重复项，方便快速确认这次异常更偏向哪一层。
- 如果首行是 `HTTP/1.1 200 OK` 这类状态行，说明你当前更适合配合状态码和缓存字段继续排查。
- 字段表适合逐个看 `Content-Type`、Cookie、鉴权头和跨域相关字段。
- 重复字段数量越多，越应该回头确认 CDN、服务端或代理层是否在多次注入。
推荐处理链路
Header 结构化之后，通常会继续看请求命令、状态码和资源类型。
- 如果你连原始请求都看不清，先回去整理 cURL 会更稳。
- 如果是资源加载、下载或接口返回异常，继续看状态码和 MIME 类型最有效。
常见问题
常见问题
HTTP Header 解析器 FAQ 主要补充重复字段、首行识别和结构化 JSON 的使用边界。
为什么同名 Header 会变成数组？
因为像 `Set-Cookie` 这样的 Header 本来就允许重复出现，结构化输出时合并成数组更接近真实传输结果。
请求头和响应头都能解析吗？
可以。只要粘贴的是常见的请求行 / 状态行加 Header 字段结构，工具都会按对应模式整理。
结构化 JSON 适合直接当接口参数用吗？
不建议直接把它当原始请求继续发送。这个结果更适合排查、分享和文档沉淀，真正发请求时仍要回到原始 Header 语境里。
继续了解
相关工具
你还可以继续使用其他已经可用的开发、格式和文本工具。