ping 属性是 HTML <a> 标签的导航前轻量级追踪机制，非网络诊断命令；仅当 href 有效、用户真实点击、目标允许跨域 text/ping 时才触发，发送固定 POST 请求体“PING”，不支持自定义参数，且 Safari 不支持、Chrome 限制第三方上下文。
ping 属性不是用来测网络延迟的，它和命令行 ping 命令完全无关——这是最容易混淆的第一步。
什么时候 ping 会真正触发
必须同时满足三个条件，ping 才会发请求：
-
<a>标签中存在有效的href属性（不能是空值、#、javascript:void(0)等无效 URL） - 用户真实点击（非
click()脚本调用，也不响应mousedown或focus） - 目标 URL 是同源或目标服务器明确允许跨域接收
text/ping请求（需响应头含Access-Control-Allow-Origin）
常见失效场景：Vue/React 中用 @click 拦截跳转后手动 router.push，此时 ping 完全不会触发；或者 href 写成 href="void(0)"，浏览器直接忽略 ping。
ping 发出的请求长什么样
浏览器发送的是一个极简 POST 请求，内容固定为字符串 PING，Content-Type 是 text/ping。关键点在于它携带的隐式信息：
立即学习“前端免费学习笔记（深入）”；
-
PING-FROM请求头：值为当前页面完整 URL（含 query 和 hash） -
Referer：和普通导航一致，但受referrerpolicy影响（例如设为no-referrer时该头消失） -
User-Agent和Origin都存在，但Cookie仅在同源时自动带上 - 不支持自定义请求体、headers 或 query 参数——你无法往里面塞
utm_source或用户 ID
这意味着：它适合做粗粒度来源统计（比如“从首页 banner 点击了几个”），但不适合带身份或上下文的精准埋点。
为什么上线后发现 ping 请求没发出去
实际部署中最常被忽略的四个硬性限制：
- Chrome 从 98 版起默认屏蔽第三方上下文中的
ping（即 iframe 里嵌的页面点击链接，ping不发） - Safari 完全不支持
ping属性（截至 2026 年 4 月最新版依然无计划支持） - 如果页面启用了
Strict-Origin-When-Cross-Originreferrerpolicy，跨域ping的Referer头会被截断，部分后端日志服务可能因解析失败而丢弃整条记录 - 某些企业级代理或安全网关会主动过滤
Content-Type: text/ping的请求，表现为 403 或超时，且前端无任何错误回调
它不是一个“开箱即用”的追踪方案，而是一个需要前后端协同确认、且必须接受 Safari 零覆盖的窄口径能力。
真正决定是否用 ping 的，不是它多酷，而是你能否接受：没有回调、无法重试、不兼容 Safari、不能传业务参数、且后端必须专门适配 text/ping 类型的入口。
