最轻量可靠的方式是直接用uni.report上报view_content事件，需传含content_id和title的param对象，于onReady+$nextTick后首次调用并防重。
直接用 uni.report 上报阅读行为，配合 uni统计2.0 后台自动聚合，是最轻量、最可靠的方式。不需要自己写接口、存数据库、做去重或防刷——这些 uni 统计已内置处理。
阅读量统计该用哪个事件名
不要自创 eventKey，优先复用 uni 统计的内置语义事件：view_content 是官方定义的「内容页浏览」事件，后台会自动归入「内容统计」报表，支持按标题、URL、渠道等多维下钻。
- 必须传
param对象，至少包含content_id（唯一标识文章）和title（用于报表展示） - 避免用
page_view或open_article这类非标准名，否则不会进内容统计模块，只能当普通自定义事件查 - 如果文章有分类/标签，可额外加
category、tag字段，方便后续筛选
示例：
uni.report('view_content', {
content_id: 'art_123456',
title: 'uni-app 如何实现高性能小说阅读器',
category: '技术',
tag: ['uni-app', '性能优化']
})
什么时候调用 uni.report 最合适
在页面真正「可见且完成渲染」后触发，而不是 onLoad 或 onShow 立即调用。否则可能因数据未加载完、骨架屏未替换、或用户快速划走，导致误统计。
- 推荐放在
onReady+$nextTick后，确保 DOM 和数据都就绪 - 若文章内容异步加载（如通过 API 拉取），应在
then回调里调用，且加防重逻辑（见下条） - 对单页应用（SPA）模式的 H5，需监听
onPageScroll判断是否滚动到首屏再上报，避免预加载导致的提前触发
示例（Vue 2 语法）：
onReady() {
this.$nextTick(() => {
// 防重复：用 flag 标记是否已上报
if (!this.hasReportedView) {
uni.report('view_content', { content_id: this.id, title: this.title })
this.hasReportedView = true
}
})
}
怎么避免重复统计和无效曝光
uni统计本身不做过滤，重复调用 uni.report 就会产生多条记录。真实场景中，以下情况极易引发误报：
- 用户反复切换 tab 或前后台，触发多次
onShow - 下拉刷新后重新渲染页面，又执行一遍上报逻辑
- 小程序 onPullDownRefresh 未重置
hasReportedView，导致刷新后再次上报
解决方法很简单：用页面级 data 变量控制，且只在「首次进入+内容加载完成」时上报一次。不要依赖路由参数或全局状态——页面实例销毁后变量就没了，下次进来仍是初始值。
额外提醒：uni统计2.0 公有版默认不做 UV 去重（即同一设备多次访问算多次 PV），如需严格 PV/UV 分离，私有版可修改云函数跑批逻辑，但绝大多数运营场景无需改动。
内容标题不上报？检查 pages.json 和 navigationBar
如果你没手动调 uni.report，而是依赖 uni 统计的「自动采集页面标题」能力，那必须满足两个前提：
- 当前页面在
pages.json的pages数组中声明，且配置了navigationBarTitleText或使用了uni-nav-bar组件 - manifest.json 中
uniStatistics.enable为true，且type正确设为"public"或"private"
否则即使开了统计，view_content 事件也不会带 title 字段，后台报表里就显示为空或 URL 路径。这种情况下，必须手动补 uni.report，不能指望框架自动识别。
