访问器属性是封装平台差异的统一接口，通过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 并引导降级方案