连通性测试核心是能建连、有响应、状态码合理；推荐用 curl -I 或 curl -o /dev/null -s -w "%{http_code}" 判断，须加 --connect-timeout 和 --max-time 超时控制，HTTPS 证书错误可用 -k 临时绕过但禁用于生产，测纯端口应使用 telnet 或 nc，且连通性不等于服务可用性。
连通性测试不等于业务调用，核心就三件事：能建连、有响应、状态码合理。其他都算额外动作。
curl -I 和 -o /dev/null -w "%{http_code}" 是最准的连通性判断方式
只看 body 或屏幕输出容易误判——比如返回 HTML 重定向页、空 JSON、甚至 502 页面，但你根本没注意到状态码是 301 或 502。
-
-I发起 HEAD 请求，只取响应头，秒级完成，适合人工快速确认：curl -I http://localhost:8080/health -
-o /dev/null -s -w "%{http_code}\n"静默执行并仅输出状态码，适合脚本断言：curl -o /dev/null -s -w "%{http_code}" http://api.example.com/readyz - 别依赖
curl http://...直接打印 body——它默认走 GET + 全量响应，既慢又干扰判断
必须加超时，否则 curl 可能卡死在 DNS 解析或 TCP 握手阶段
默认无超时，遇到内网 DNS 慢、服务未监听、防火墙静默丢包等情况，curl 会挂住几十秒，导致自动化检测失败或阻塞流水线。
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
-
--connect-timeout 5：限制建立 TCP 连接的时间（含 DNS 查询），5 秒内连不上就报错 -
--max-time 10：总耗时上限，防止响应体巨大或服务卡顿拖垮整个检查 - 生产脚本建议组合使用：
curl --connect-timeout 5 --max-time 10 -o /dev/null -s -w "%{http_code}" http://svc:8080/health
HTTPS 证书错误时，-k 能绕过但要清楚代价
自签名证书、私有 CA 或过期证书会导致 curl https://... 直接失败，报 SSL certificate problem 或类似错误。
-
-k（或--insecure）可跳过证书校验，让连通性测试继续——但仅限测试环境，绝不可用于生产验证 - 想确认证书本身是否有效，用
-v查握手细节：curl -v https://example.com 2>&1 | grep "SSL certificate" - 若需信任私有 CA，应配置
CURLOPT_CAINFO对应的 PEM 文件，而非滥用-k
用 curl 测端口连通性？小心它和 telnet 的本质区别
curl ip:port 看似能测端口，但它实际发的是 HTTP 请求——目标端口必须运行 HTTP 服务，且返回合法响应头，否则就报错或超时。它不是 TCP 层探测。
- 真要测纯端口（比如数据库 3306、Redis 6379），用
telnet ip port或nc -zv ip port更准确 -
curl 192.168.1.100:8080成功，只能说明“HTTP 服务在 8080 启动了”，不能说明“8080 端口本身可达” - 如果服务启用了 TLS 但没配好 HTTP 协议（如只监听 HTTPS），
curl http://ip:8080会失败，但端口其实是通的
真正容易被忽略的点是：连通性 ≠ 可用性。一个返回 200 的 /health 接口，可能背后依赖的数据库已宕机，只是健康检查逻辑没覆盖到。所以连通性只是第一道门，别把它当成服务可用的充分条件。
