app端系统信息必须在onload等生命周期中调用uni.getsysteminfosync获取并绑定到data,filters无法访问原生api且不生效;systeminfo.platform为"ios"/"android",system字段已含版本号,需兜底处理空值。

App端的系统信息(如平台、型号、操作系统版本)根本不需要过滤器——它不是要“格式化”的数据,而是需要在运行时主动读取的原生能力,filters 在 App 端完全不生效,且无法访问 uni.getSystemInfoSync() 这类原生 API。
为什么 App 端不能用 filters 处理系统信息
过滤器只在模板渲染阶段执行,且仅对传入的值做纯转换;而系统信息必须调用原生接口获取,且不同端(iOS/Android)返回字段不一致。你在 filters 里写 uni.getSystemInfoSync(),真机上会直接报错 undefined is not an object (evaluating 'uni.getSystemInfoSync') —— 因为小程序编译器和 App 端 runtime 都不支持在 filter 函数内调用同步原生 API。
- App 端(iOS/Android)的
uni.getSystemInfoSync只能在onLoad、onShow或methods中安全调用 - filters 是纯函数,无 this 上下文,拿不到
uni实例,也访问不了原生模块 - 即使强行在 filters 里 import 或调用,HBuilderX 编译时会剥离,真机运行时静默失败
App 端正确读取并展示系统信息的做法
必须在生命周期或响应式逻辑中主动拉取,再绑定到 data 或 computed。例如:
export default {
data() {
return {
systemInfo: {}
}
},
onLoad() {
// 必须在这里调用,不能放 filters 或 template 里
try {
this.systemInfo = uni.getSystemInfoSync()
} catch (e) {
this.systemInfo = { platform: 'unknown', model: '', system: '' }
}
}
}
-
systemInfo.platform返回"ios"或"android",不是字符串拼接出来的 -
systemInfo.model在 iOS 上可能是"iPhone 14 Pro",Android 上是厂商定制名(如"MI 9"),别依赖固定格式 - 若需显示“iOS 17.5”或“Android 14”,应拼接
systemInfo.system字段,它已是"iOS 17.5"或"Android 14"格式 - 不要在
v-for里反复调用uni.getSystemInfoSync,它开销大,且多次调用可能触发权限弹窗
想封装成“类似过滤器”的调用?用计算属性或工具函数
如果希望模板里写得简洁,比如 {{ $sys.platform | upper }},那 $sys 必须是 data/computed 提前挂好的对象,而不是靠 filter 动态查:
// 在 data 或 setup 中预先赋值
data() {
const sys = uni.getSystemInfoSync()
return {
$sys: {
platform: sys.platform,
osVersion: sys.system.split(' ')[1] || '',
safeArea: sys.safeAreaInsets || { top: 0 }
}
}
}
- 所有字段必须在页面初始化时一次性取完,避免后续异步更新导致视图不重绘
- 别把
uni.getSystemInfo(异步版)塞进 computed,computed 不该有副作用 - 如果要用 TypeScript,记得给
$sys显式声明类型,否则platform可能被推导为string而非字面量类型
真正容易被忽略的是:App 端首次启动时,getSystemInfoSync 可能因权限未就绪返回空字段,尤其 Android 12+ 对 model 和 brand 有更严限制。别假设它一定有值,兜底逻辑比格式化更重要。











