推荐封装 trackEvent 函数统一上报：平台适配（H5/fetch、小程序/wx.request、App/uni.request），事件名小写下划线，参数扁平化，500ms 防抖；埋点时机需覆盖 onShow（判栈顶）、onPullDownRefresh、onHide（缓存补报）；UID 优先登录态，未登录持久化 device_id（sha256生成），iOS 隐私合规降级；数据丢失需检查协议、白名单、证书及真机抓包验证。
uni-app里怎么发自定义埋点事件
直接调用 uni.$emit 或走统一上报函数，别在页面里硬写 request。uni-app 的跨端特性决定了不能依赖某端原生 API 做埋点发送，否则 H5 正常、小程序报错、App 又可能丢请求。
- 推荐封装一个
trackEvent函数，内部判断平台：H5 走fetch，微信小程序用wx.request，App 端优先走uni.request（它会自动适配） - 事件名别用中文或空格，统一小写下划线，比如
"page_home_load"、"button_search_click" - 参数必须扁平化，避免传嵌套对象——有些平台序列化不一致，iOS App 可能丢掉深层字段
- 加个简单防抖：同一事件 500ms 内重复触发只上报一次，防止用户狂点按钮刷爆日志
uni-app生命周期钩子中埋点容易漏哪些时机
很多人只在 onLoad 和 onShow 里打点，结果漏掉关键路径：比如从后台切回前台、下拉刷新、tabBar 切换后页面重新激活，这些都不会触发 onLoad，但业务上可能算一次“曝光”。
-
onShow是最常用也最容易误用的：它在页面每次显示时都触发，包括从子页返回、tabBar 切换、甚至小程序后台唤醒，需结合getCurrentPages()判断当前是否为栈顶页 - 下拉刷新要监听
onPullDownRefresh，但记得手动uni.stopPullDownRefresh()后再上报，否则刷新动画没结束就发请求，部分安卓机上报失败不报错 - 离开页面时慎用
onUnload：App 端可能被系统回收导致来不及发请求，建议改用onHide+ 本地缓存 + 下次启动时补报
uni-app里怎么处理用户标识（UID）和设备 ID
没有稳定 UID 就没法关联行为，但 uni-app 没有全局用户态，得自己兜底。别直接用 uni.getSystemInfoSync().deviceId，它在 iOS 微信小程序里返回空，在 Android App 上每次重装都会变。
- 优先取登录态里的
userId；未登录时用uni.getStorageSync('device_id')，首次生成后持久化保存，格式建议用sha256(uni.getSystemInfoSync().platform + new Date().getTime()) - 微信小程序可尝试
wx.getOpenDeviceId（需配置域名白名单），但仅限同主体，跨主体无效 - 上报时把
uid和device_id都带上，后端按优先级合并：有 uid 就用 uid，没有才 fallback 到 device_id - 注意隐私合规：iOS 14+ 要求弹窗授权获取 IDFA，uni-app 无法绕过，此时 device_id 必须降级为完全匿名的随机字符串
uni-app埋点数据丢了怎么办
不是代码没跑，而是请求发出去了没进数仓——常见于跨域、HTTPS 混合、header 被过滤、或上报地址写死成 http。
- 检查目标地址协议：H5 环境下若接口是
http://，Chrome 会静默拦截，必须用https://或 localhost - 小程序要求域名必须在
request白名单里，且不能带端口；App 端若用自签名证书，需在manifest.json中配置"sslVerify": false（仅测试环境） - 加个简易日志开关：
uni.setStorageSync('debug_track', true)，开启后所有埋点打印到console.log，不依赖网络也能确认是否触发 - 上线前用真机连 Chrome DevTools（App）或 vConsole（H5/小程序）抓包，看请求是否发出、状态码是否 200、响应体有没有
"code":0
埋点最麻烦的不是怎么发，而是怎么确认它真的到了。尤其跨端场景下，一个配置项写错，三个平台表现还不一样——得每个端单独验，别信“H5 OK 就代表没问题”。
