埋点数据应发送至轻量抗压的PHP接收接口，需校验Content-Type与来源，用file_get_contents('php://input')读JSON，强制校验event/uid/ts/url/ua字段，ts须为13位且偏差≤5分钟，数据经日志或消息队列异步落盘，避免同步耗时操作。
埋点数据该往哪儿发：PHP 后端接收接口怎么写
用户行为前端触发后，最终得有个 PHP 脚本收数据，不能直接往数据库里硬插。核心是设计一个轻量、抗压、能快速响应的接收入口。
- 用
$_POST或file_get_contents('php://input')读原始 JSON（前端常发application/json），别只依赖$_REQUEST，否则字段丢失 - 必须校验
Content-Type和请求来源（比如检查HTTP_ORIGIN或加简单 token，防恶意刷点） - 别在接收接口里做耗时操作：不连 Redis 写缓存、不调外部 API、不发邮件——统一走队列或异步落盘
- 示例接收逻辑：
if ($_SERVER['REQUEST_METHOD'] !== 'POST') { http_response_code(405); exit; } $data = json_decode(file_get_contents('php://input'), true); if (!$data || !isset($data['event']) || !isset($data['uid'])) { http_response_code(400); exit; } // 记 log 文件或投递到 Kafka/RabbitMQ，立刻返回 200
埋点字段怎么设计才不翻车：PHP 侧校验与标准化
前端传来的字段五花八门，PHP 不是来者不拒的垃圾桶。字段缺失、类型错、长度超、时间戳乱码，都会让后续分析崩掉。
- 强制要求字段：至少含
event（事件名）、uid（用户标识）、ts（毫秒级时间戳）、url（当前页）、ua（User-Agent） - 用
filter_var()做基础过滤：filter_var($data['uid'], FILTER_SANITIZE_STRING)，但别信它能防所有注入——关键字段仍要白名单匹配 -
ts必须验证是否为 13 位数字，且与服务器时间偏差不超过 5 分钟（防伪造） - 避免嵌套过深的结构，如
$data['props']['page']['meta']['title']—— PHP 解析慢、日志难查、ES 导入易失败
落地存储选 MySQL 还是文件：PHP 写入策略的真实取舍
小项目图快写进 MySQL 单表，大流量下直接锁表；全扔日志文件又难关联、难聚合。PHP 层要清楚每种方式的代价。
- MySQL 方案只适合日均埋点 event、
uid、ts复合索引，data字段用JSON类型（MySQL 5.7+），别用TEXT存序列化字符串 - 文件方案更稳：PHP 用
fopen(..., 'a')追加写入，按天切分，如/var/log/track/20240615.log，每行一个 JSON 对象。注意设置umask和磁盘配额，防止撑爆 - 千万别用
file_put_contents()每次都覆盖写，高并发下会丢数据；也别在循环里反复new PDO()，连接池或长连接更靠谱
为什么埋点总对不上：PHP 时区、编码、超时这三关最容易漏
前端看到的“点击转化率下降”，后端查出来是 PHP 把 ts 当成本地时间解析，或者 UTF-8 的 emoji 被转成乱码再入库，最后统计全错。
立即学习“PHP免费学习笔记（深入）”；
- PHP 脚本开头必须设时区：
date_default_timezone_set('Asia/Shanghai')，且确认php.ini中date.timezone一致，否则date()和 MySQL 的NOW()对不上 - 所有输入输出强制 UTF-8：
mb_internal_encoding('UTF-8')，JSON 解析前用mb_convert_encoding()清洗，尤其处理微信、钉钉等渠道带 emoji 的nickname - 接收接口
set_time_limit(2)，超时就丢弃，别让慢请求卡住整个 FPM worker；Nginx 侧也要配fastcgi_read_timeout 3
埋点不是“能收到就行”，而是从 PHP 接收那一刻起，每个字符的编码、每一毫秒的时差、每一次磁盘写入的原子性，都在悄悄决定你下周做的分析报表明不明、准不准。
