埋点数据需通过 fetch 或 XMLHttpRequest 发送 POST 请求至 PHP 接口，后端用 file_get_contents('php://input') 解析 JSON；须校验 Content-Type、Referer、IP 限频及字段格式；优先写文件或直传 ES/CK，避免 MySQL 同步写入与复杂操作；前端用 sendBeacon、once 监听和去重机制保障上报可靠性。
埋点数据怎么从浏览器发到 PHP 后端
前端行为（比如点击、页面停留、表单提交）必须通过 HTTP 请求发给 PHP 接口，不能直接写数据库或调用服务端函数。最常用的是 fetch 或 XMLHttpRequest 发 POST 请求，后端用 $_POST 或 file_get_contents('php://input') 接收原始 JSON。
常见错误现象：$_POST 为空，但请求明明发了——这是因为前端用了 Content-Type: application/json，而 PHP 默认只解析 application/x-www-form-urlencoded 和 multipart/form-data 的数据。
- 前端发 JSON 时，PHP 后端要改用
file_get_contents('php://input')读取原始体，再json_decode() - 如果前端坚持用
form-data或键值对方式发，$_POST才能直接用，但字段名得提前约定好（如event_type、page_url、timestamp） - 别在 PHP 中用
$_GET接埋点——URL 长度限制、缓存、日志泄露风险都太高
PHP 接口怎么防刷和保格式
埋点接口是公开的，没认证、没 Referer 校验、没频率限制，很快就会被爬虫打爆或灌脏数据。不能只图“能收”，得加基础防护。
典型问题：日志里突然出现大量 event_type=click 但 page_url 是空字符串或 javascript:;，说明有人在模拟请求。
立即学习“PHP免费学习笔记（深入）”；
- 必须校验
Content-Type头是否为application/json或你允许的类型，其他一律400 - 用
$_SERVER['HTTP_REFERER']做粗略来源判断（注意：可伪造，仅作辅助），拒绝明显异常域名 - 对同一 IP +
event_type做简单限频（如 10 秒内不超过 5 条），用apcu_store()或 Redis 缓存计数，别查库 - 字段必校验非空、长度、格式（如
timestamp必须是数字且在合理范围，page_url要filter_var($url, FILTER_VALIDATE_URL)）
PHP 存埋点数据该用什么方式
高频写入、结构松散、不强求事务一致性——这时候硬上 MySQL 主键自增+事务反而拖慢接口响应，还容易锁表。
真实场景中，90% 的埋点数据只要“写进去、别丢、后续能批量导出”就行，不是用来做实时报表的。
- 优先考虑写文件：用
file_put_contents($logPath, $line . "\n", FILE_APPEND | LOCK_EX)，每行一个 JSON，按天分文件（如track_20240615.log） - 如果已有 Elasticsearch 或 ClickHouse，直接 HTTP POST 到对应 API，比走 PHP 中转更稳
- 真要用 MySQL，别每个请求开连接，用长连接池（如 PDO 持久连接），且表引擎选
MyISAM或ROCKSDB（写密集场景比 InnoDB 轻） - 绝对不要在埋点接口里做复杂计算、关联查询、发送邮件等同步操作
JS 埋点脚本怎么避免阻塞和重复上报
前端 JS 是用户感知层，脚本加载慢、执行卡顿、多次触发，都会影响体验甚至导致数据失真。
常见坑：onclick 绑定两次、SPA 页面切换后事件监听器没清理、beforeunload 里发请求大概率被浏览器中断。
- 用
addEventListener+{ once: true }确保事件只上报一次 - 页面卸载前的上报，改用
navigator.sendBeacon()，它异步且浏览器保证发出（fetch在beforeunload中基本不可靠） - 脚本加载用
async或defer，别放<head>里同步加载 - 上报前加简单去重：对相同
event_type+element_id+ 10 秒窗口，用Set缓存指纹，避免快速连点重复发
真正难的不是“怎么发”或“怎么存”，而是字段定义能不能统一、前后端时间戳怎么对齐、网络失败后要不要本地暂存再重试——这些细节没对齐，后面查数据永远在猜。
