访问器属性是封装平台差异的统一接口，通过getter/setter集中处理平台判断、API路由与数据标准化，配合条件编译兜底，避免业务层感知差异，但不可替代组件抽象或模拟缺失能力。
继承访问器属性本身不是抹平平台差异的直接手段，但它可作为封装策略中的一环，配合平台抽象层共同实现优雅适配。关键不在于“继承”动作，而在于用访问器（getter/setter）把平台判断、资源选择、API调用等差异逻辑收口到统一接口下，让业务代码无感。
用访问器封装平台判断逻辑
避免在组件或页面中反复写 Platform.OS === 'ios' 或 uni.getSystemInfoSync().platform === 'android'。而是集中定义一个平台能力对象，用 getter 暴露语义化属性：
-
状态栏高度：定义
get statusBarHeight()，内部根据 iOS/Android 返回不同值（如 iOS 44、Android 24），业务层只读UIConfig.statusBarHeight -
返回行为：定义
get canSwipeBack()，iOS 返回true，Android 返回false，导航组件据此决定是否启用手势 -
默认字体：定义
get defaultFontFamily()，iOS 用-apple-system，Android 用Roboto，样式系统自动注入
通过访问器代理平台专属 API
不同平台提供的原生能力名称和参数常不一致。访问器可作为“垫片”，对外暴露统一签名，对内路由到真实实现：
- 调用
Storage.save(key, value)时，getter 不参与，但 setter 可触发平台分支：H5 走localStorage，小程序走uni.setStorageSync，APP 端走 SQLite 封装 - 读取
Device.model时，getter 自动过滤 Android 的冗余型号字符串（如SM-G998B→S21 Ultra），iOS 则直接返回iPhone 14 Pro - 访问
Network.type时，getter 统一返回'wifi' | '4g' | '5g' | 'unknown'，屏蔽 iOS 的WWAN、Android 的MOBILE等底层枚举
结合条件编译增强访问器健壮性
访问器内部仍需处理平台不可用场景。此时条件编译不是替代方案，而是兜底保障：
- 在
get cameraPermission()中，H5 平台无相机权限概念，直接返回'granted'；小程序和 APP 则调用各自 API - 使用
#ifdef MP-WEIXIN包裹微信专属 API 调用，再通过访问器对外暴露统一openOfficialAccount()方法 - 访问器返回值类型保持一致，例如
get isDarkMode()在不支持深色模式的旧版 Android 上，fallback 为false，而非抛错或 undefined
避免常见误用陷阱
访问器是工具，不是银弹。需注意边界：
- 不用于高频计算逻辑——如每帧都读取
isIOS，应缓存结果，而非每次执行判断 - 不替代真正的平台组件抽象——按钮视觉差异靠访问器改颜色不够，仍需
BaseButton组件封装不同平台的 native button 或自绘实现 - 不掩盖根本性能力缺失——如 H5 无法调起 NFC，访问器不能“模拟”该功能，而应明确返回
isNFCAvailable: false并引导降级方案
