埋点数据应写在middleware中，因其可统一拦截请求、获取完整上下文、支持异步写入且不干扰业务；controller仅限特殊场景并需try...finally保障；须过滤爬虫、分域命名参数、轻量序列化并禁用全量数据上报。
埋点数据该往哪儿写：Controller 还是 Middleware？
用户行为埋点不是日志记录，核心是「可追溯、可关联、不干扰业务」。ThinkPHP 里最稳的落点是 MiddleWare，不是每个 Controller 方法都补埋点逻辑——容易漏、难维护、还可能因异常跳过。
Middleware 能统一拦截请求生命周期，在 handle() 中拿到完整路由、参数、用户 ID（session 或 token 解析后），且天然支持异步写入（比如用 think-queue 推到 Kafka/ES）。
- 别在
__construct()里埋点：此时 Request 尚未绑定，$this->request可能为空或不全 - 避免在模型回调（如
afterWrite）中做前端行为埋点：那是数据层动作，和「用户点击/停留/跳转」语义不匹配 - 如果必须在 Controller 写（例如 A/B 测试特定按钮），务必用
try...finally包裹，防止业务异常导致埋点丢失
怎么保证埋点不拖慢接口：异步 + 轻量序列化
同步写数据库或 HTTP 上报，一个埋点卡住，整个接口就超时。ThinkPHP 默认没有内置异步埋点通道，得自己搭一层缓冲。
推荐用 think-queue + JSON 序列化，字段只留关键项：时间戳（microtime(true)）、uid、url、action（如 'click_product_detail'）、referer、ua（截取前 128 字符防爆）。别塞 $_POST 全量或 session 数据。
- 禁用
json_encode($request->param())：含文件上传、大数组时极易 OOM 或超时 - 不要在队列任务里重新查用户信息：Middleware 中已解析好的
$uid必须透传过去，避免二次 DB 查询 - 队列失败重试最多 1 次，超过就丢弃——埋点数据不是交易数据，强一致性反而伤性能
如何区分真实用户与爬虫/监控流量
不做过滤的埋点，一半以上是无效噪音。ThinkPHP 的 Request 对象能帮你挡掉大部分。
优先检查 $request->isAjax() 和 $request->header('user-agent')，再结合 $request->header('x-requested-with')。简单规则：非 AJAX 请求 + UA 含 HeadlessChrome|curl|python-requests|monitor → 直接跳过埋点。
- 别依赖
$request->ip()黑名单：CDN 后端 IP 经常是内网段，误杀率高 - 不要用
session_id()是否存在判断真人：微信 JS-SDK 静默登录场景下 session 可能延迟创建 - 对管理后台（
/admin/*）路由，默认关闭埋点——运营自己刷数据没意义
埋点字段命名冲突怎么办：ThinkPHP 的 Request 和自定义参数混用
前端常把埋点参数塞进 URL query 或 POST body，比如 ?event=pay_success&pid=1001，但你的业务参数里也有 pid。直接取 $request->param('pid') 会覆盖或混淆。
解法是分域：约定埋点参数统一加前缀，如 track_event、track_pid，服务端用 $request->param('track_*') 批量提取，业务参数走原名。ThinkPHP 5.1+ 支持通配符，$request->param('track_*') 返回关联数组，干净不冲突。
- 禁止用
$request->param()全量合并后再 unset：key 名冲突时 PHP 会静默覆盖，debug 极难发现 - 如果前端无法改参数名，用
$request->get('event')和$request->post('event')分开取，再手动合并，比靠param()猜安全 -
track_*参数一律不参与业务校验和数据库写入，只进埋点队列——避免被当成业务字段误处理
真正麻烦的是跨域 iframe 场景下的 referer 丢失和 uid 匿名化映射，那得动 cookie 策略和登录态设计，不是加几行代码能解决的。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
