ping属性不是开箱即用的通用埋点方案，仅在chrome支持（98+禁第三方上下文）、firefox默认禁用、safari从未支持且需合法href共存时触发，后端须严格校验text/ping类型、ping-from头及限速，同源时会静默携带cookie引发隐私风险。
ping 属性不是“加了就能用”的通用埋点方案，它只在特定条件下触发，且浏览器支持度极不均衡——Chrome 98+ 默认禁用第三方上下文（如 iframe）中的 ping，Firefox 默认彻底禁用，Safari 从未支持。别指望它覆盖所有用户，更别把它当主力埋点手段。
ping 属性必须和合法 href 共存才生效
浏览器强制校验：没有有效 href，ping 直接被忽略。
- ✅ 正确：
@#@#@#@#@#@#@#@#@#@0（HTTPS 协议、可跳转 URL） - ❌ 无效：
@#@#@#@#@#@#@#@#@#@1（href非导航 URL） - ❌ 无效：
@#@#@#@#@#@#@#@#@#@2（#不触发导航，ping不发）
注意：Chrome 94 起静默禁用 HTTP 环境下的 ping 请求，控制台无报错、Network 面板也不显示——你根本不知道它没发。
后端接收 ping 请求必须严格校验 Content-Type 和 PING-FROM 头
浏览器发出的请求是 POST，Content-Type: text/ping，但攻击者可伪造任意类型和头。不校验 = 开放 SSRF 入口。
- 必须拒绝非
text/ping的Content-Type（如text/pingback、application/json） - 必须解析并校验
PING-FROM请求头：值需为合法 HTTP(S) URL，且不能含内网地址（http://127.0.0.1、http://192.168.x.x） - 必须限速：单 IP 每分钟最多 3 次，超限返回
429 Too Many Requests，响应体为空 - 不要解析请求体——标准行为下它就是字符串
"PING"；若收到非空 body，应视为异常并告警
同源 ping 会静默携带 Cookie，等价于一次未授权会话调用
如果 ping="/api/click" 指向同域 endpoint，浏览器会自动带上当前域全部 Cookie，包括登录态 token。这不是“埋点”，是潜在的身份泄露。
- 风险场景：内网页面嵌第三方 banner，banner 中链接带
ping指向同域日志接口 →PING-FROM暴露完整内网路径（如https://intranet.company.local/admin?user=alice） - 缓解方式：日志 endpoint 必须设为跨域独立子域（如
log.yourapp.com），且明确禁用 Cookie；或后端显式忽略Cookie请求头 - 别依赖
SameSite或referrerpolicy——ping绕过这些策略
真正决定要不要用 ping 的，不是它多轻量，而是你能否接受：没有回调、无法重试、Safari 零覆盖、不能传业务参数、且后端必须专设一个只认 text/ping 的入口并做严苛校验。它只适合记录“谁点了这个外链”，而不是“谁在什么状态下点了哪条带用户 ID 的推荐链接”。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
