专栏：HarmonyOS 三方库适配实战（20/30）核心问题：线程、时间、文件和网络调用不兼容时，怎样避免在上游源码里散落平台判断？摘要Native 适配最难维护的写法，是在几十个源文件中追加平台宏。更好的方法是先识别能力端口，再把 HarmonyOS 实现集中在适配层，核心只依赖小接口。本文用教学text_core展示“纯核心 + Node-API 边界”的最小形态，并给出文件、时间、日志和线程的抽象模板。当前纯核心与桥接已经双 ABI 编译；真实系统调用和设备行为未执行。宏应该出现在哪里允许出现的平台差异位置：外层 CMake 选择源码和编译选项；单独的platform/harmony/实现文件；极少数无法抽象的类型或编译器兼容点。不应出现：算法循环的每个分支；公共头文件到处暴露平台类型；上游测试中改变预期来迎合平台；用宏直接吞掉错误。图 1：核心依赖能力接口，HarmonyOS 实现集中在外层。一个能力端口模板classClockPort{public:virtual~ClockPort()=default;virtualstd::int64_tNowMillis()const=0;};classFilePort{public:virtual~FilePort()=default;virtualResultstd::vectorstd::uint8_tReadAll(conststd::string
专栏：HarmonyOS 三方库适配实战（20/30）核心问题：线程、时间、文件和网络调用不兼容时，怎样避免在上游源码里散落平台判断？摘要Native 适配最难维护的写法，是在几十个源文件中追加平台宏。更好的方法是先识别能力端口，再把 HarmonyOS 实现集中在适配层，核心只依赖小接口。本文用教学text_core展示“纯核心 + Node-API 边界”的最小形态，并给出文件、时间、日志和线程的抽象模板。当前纯核心与桥接已经双 ABI 编译；真实系统调用和设备行为未执行。宏应该出现在哪里允许出现的平台差异位置：外层 CMake 选择源码和编译选项；单独的platform/harmony/实现文件；极少数无法抽象的类型或编译器兼容点。不应出现：算法循环的每个分支；公共头文件到处暴露平台类型；上游测试中改变预期来迎合平台；用宏直接吞掉错误。图 1：核心依赖能力接口，HarmonyOS 实现集中在外层。一个能力端口模板classClockPort{public:virtual~ClockPort()=default;virtualstd::int64_tNowMillis()const=0;};classFilePort{public:virtual~FilePort()=default;virtualResultstd::vectorstd::uint8_tReadAll(conststd::string
