React Native应用的条件编译实现方案咨询

编译阶段剔除冗余依赖 #

• 条件编译+模块树摇（Tree Shaking）
  借助Webpack、Rollup、Vite这类构建工具的条件编译能力，结合环境变量标记要剔除的依赖。比如在构建配置里注入process.env.APP_TYPE，代码里用环境变量判断包裹依赖引入，同时开启工具的Tree Shaking（确保项目用ES模块，禁用CommonJS），就能让构建工具自动把未被引用的依赖从最终包中移除。
  示例代码：

  let analyticsSDK;
  if (process.env.APP_TYPE === 'full_version') {
    analyticsSDK = require('analytics-sdk'); // 仅完整版应用会引入该依赖
  }
  

• 自定义构建脚本过滤依赖
  写个简单的Node脚本，根据目标应用类型修改package.json：把不需要的依赖移到devDependencies或者直接删除，再执行依赖安装和构建流程。适合某款应用完全不需要接触特定依赖的场景。

运行时检查依赖可用性 #

• Inline Require + 异常捕获
  避免在文件顶部静态引入依赖，而是在需要使用功能的地方动态require，同时捕获模块不存在的异常，做降级处理。
  示例代码：

  function trackUserBehavior(event) {
    try {
      const analyticsSDK = require('analytics-sdk');
      analyticsSDK.track(event);
    } catch (e) {
      // 依赖不存在时的降级逻辑，比如打日志或空实现
      console.log('Analytics SDK not available, skip tracking');
    }
  }
  

• 全局标记模块可用性
  构建阶段根据环境变量注入全局标记，比如window.HAS_ANALYTICS，运行时先判断这个标记再尝试引入或使用相关功能。
  示例代码：

  if (window.HAS_ANALYTICS) {
    import('analytics-sdk').then(sdk => {
      sdk.track('page_enter');
    }).catch(e => {
      // 处理模块加载失败的情况
    });
  }
  

实际落地参考 #

不少跨应用共享代码库的团队都在使用这类方案：比如电商APP区分标准版和轻量版，轻量版剔除支付、营销类SDK；工具类APP区分免费版和Pro版，Pro版才引入高级功能依赖。核心逻辑都是构建阶段靠环境变量+Tree Shaking做依赖剔除，运行时靠动态引入+异常捕获做兼容降级。

内容的提问来源于stack exchange，提问作者aghid mon