本文实测验证 react-native-tooltip 在 HarmonyOS 上的可用性，推翻“导入即失败”说法：打包、构建、页面渲染均成功，但核心功能不可用。因 NativeModules.ToolTipMenu 为 null，调用 show() 时抛错；且该库依赖 iOS 原生组件，鸿蒙无对应实现。更深层问题：spec.json 标注错误（native: false），且使用已废弃的字符串

本文实测验证 react-native-tooltip 在 HarmonyOS 上的可用性，推翻“导入即失败”说法：打包、构建、页面渲染均成功，但核心功能不可用。因 NativeModules.ToolTipMenu 为 null，调用 show() 时抛错；且该库依赖 iOS 原生组件，鸿蒙无对应实现。更深层问题：spec.json 标注错误（native: false），且使用已废弃的字符串

本文记录了将 react-native-swipe-gestures 适配 HarmonyOS 的过程。实测证明，PanResponder 在 RNOH 上可正确响应真实滑动手势（onSwipe 被触发），表明手势事件链路已通。但因库存在严重缺陷：swipeConfig 为模块级单例，导致多实例配置污染，使方向判定失败（如 vx=0.5 因阈值被误设为 1 而不满足条件）。此外，还发现 JSX 中

本文记录了将 react-native-swipe-gestures 适配 HarmonyOS 的过程。实测证明，PanResponder 在 RNOH 上可正确响应真实滑动手势（onSwipe 被触发），表明手势事件链路已通。但因库存在严重缺陷：swipeConfig 为模块级单例，导致多实例配置污染，使方向判定失败（如 vx=0.5 因阈值被误设为 1 而不满足条件）。此外，还发现 JSX 中

本文完整记录了将 react-native-table-component 适配至 HarmonyOS 的过程。通过7个纯class组件实现表格，零依赖、无老旧API调用，7个组件的propTypes与结构均精确匹配源码。关键验证显示：列宽按widthArr精准布局，flex: 1实现平分，坐标数据与预期完全一致，证明布局逻辑正确无误。结论：该库适配成功，是目前最干净的一次，22项判据全通过，可直

本文完整记录了将 react-native-table-component 适配至 HarmonyOS 的过程。通过7个纯class组件实现表格，零依赖、无老旧API调用，7个组件的propTypes与结构均精确匹配源码。关键验证显示：列宽按widthArr精准布局，flex: 1实现平分，坐标数据与预期完全一致，证明布局逻辑正确无误。结论：该库适配成功，是目前最干净的一次，22项判据全通过，可直

本文完整记录了将 react-native-tag-input 适配至 HarmonyOS 的过程。针对预检中发现的三项潜在风险（ViewPropTypes、invariant(Platform.OS === 'ios')、内部路径导入），通过分析上下文均判定为安全：前者有现成 polyfill，后者函数永不调用，后者为 import type 可被消除。最终代码零修改，23 条判据全通过，实现零

本文完整记录了将 react-native-tag-input 适配至 HarmonyOS 的过程。针对预检中发现的三项潜在风险（ViewPropTypes、invariant(Platform.OS === 'ios')、内部路径导入），通过分析上下文均判定为安全：前者有现成 polyfill，后者函数永不调用，后者为 import type 可被消除。最终代码零修改，23 条判据全通过，实现零

本文完整记录了将 react-native-tag-input 适配至 HarmonyOS 的过程。针对预检中发现的三项潜在风险（ViewPropTypes、invariant(Platform.OS === 'ios')、内部路径导入），通过分析上下文均判定为安全：前者有现成 polyfill，后者函数永不调用，后者为 import type 可被消除。最终代码零修改，23 条判据全通过，实现零

本文详述将 react-native-otp-inputs 适配 HarmonyOS 的全过程。核心结论：功能可用，19项判据全通过。关键挑战在于：入口强制导入剪贴板原生模块，导致打包失败；通过引入带调用计数的空桩（stub）解决，并验证默认不触发剪贴板操作。其次，平台判断中 parseInt(Platform.Version) 在鸿蒙上返回 NaN，使自动填充失效，但逻辑安全。经验证，27处平台