curl -I 发送 HEAD 请求仅获取响应头，速度快但可能因重定向、服务特殊处理导致头信息不全；需配合 -L 跟跳转、-k 跳过 SSL 验证；查响应体内容须用 curl -i；取状态码推荐 -w "%{http_code}" 而非 grep。
curl -I 只拿响应头，但要注意重定向和简化头
直接用 curl -I 是最快看到响应头的方式，它发的是 HEAD 请求，不下载响应体，速度快、开销小。但很多服务对 HEAD 做了特殊处理：比如返回精简头、不设 Set-Cookie、甚至直接 302 跳转到 GET 页面却不再返回跳转后的头。
常见问题包括：HTTP/1.1 302 Found 后没后续头、Cache-Control 字段缺失、Content-Length 为 0 却实际有内容。
- 加
-L跟随重定向：确保看到最终目标的完整响应头，例如curl -I -L https://short.url/abc - 加
-k跳过 SSL 验证：内网或自签名证书场景下避免连接失败 - 别只信
Status行——有些 CDN 或反向代理会把 302 返回成 200，得看Location字段是否存在
curl -v 看全链路：请求头 + 响应头 + 连接细节
当你要确认“我发出去的请求头到底长啥样”，或者怀疑中间设备（如 Nginx、CDN、WAF）偷偷改了头，curl -v 是唯一可靠选择。它输出真实发送的请求行、所有请求头、响应行、响应头，以及 TCP 连接过程。
注意输出里以 > 开头的是请求头，< 开头的是响应头；* 开头的是 curl 自身行为（如 DNS 解析、SSL 握手）。
- 默认
User-Agent是curl/7.x，部分 API 会拒绝——用-H "User-Agent: Mozilla/5.0"覆盖 - 想过滤出纯请求头？可以用
curl -v URL 2>&1 | sed -n '/^> /,/^$/p' -
-v不会自动跟随重定向，要跟重定向就得组合-L -v，但输出会变复杂，建议先用-I -L定位终点，再对终点单独-v
curl -i 和 -I 的本质区别：GET vs HEAD
curl -i 发的是 GET 请求，响应头 + 响应体一起返回，用空行分隔；curl -I 发的是 HEAD，只返回头。很多人误以为 -i 是“带头的 -I”，其实逻辑完全不同。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
典型误用场景：想检查 HTML 中的 <meta http-equiv="Cache-Control">，却用了 -I——结果根本看不到响应体，自然找不到 meta 标签。
- 要查响应体里的 header 相关内容（如 meta、script 注入的 token），必须用
curl -i或curl（无参数，默认 GET） -
curl -i输出可能很长，加| head -n 20快速预览前 20 行 -
curl -I在脚本中判断状态码更安全：响应体为空，不会因大文件阻塞或污染管道
脚本里取状态码或特定 Header，别靠 grep 死匹配
在自动化检测或 CI 中，经常需要提取 HTTP/1.1 200 OK 或某个字段值（如 Content-Type）。直接 grep "200" 很危险——响应体里可能有 “200” 字符串，grep 会误判。
正确做法是只处理响应头部分，且区分大小写与字段边界。
- 取状态码：用
curl -s -o /dev/null -w "%{http_code}" URL，这是 curl 内置变量，最准 - 取单个 header 值：用
curl -s -I URL | grep -i "^content-type:" | cut -d: -f2- | xargs，注意^锚定行首、-i忽略大小写、cut -f2-防止冒号在值里被截断 - 批量检查多个 header：用
curl -s -I URL | awk 'BEGIN{IGNORECASE=1} /^server|^cache-control|^set-cookie/ {print}'
实际调试时，HEAD 请求的语义限制和中间设备的干预比文档写的更隐蔽；能用 -w "%{http_code}" 就别 parse 响应头，能用 -L -I 就别假设一次请求能到位。
