使用create-react-app有何弊端？对比自定义React模板有哪些劣势？

作为常年和React项目打交道的开发者，我来分享下实际使用create-react-app（简称CRA）过程中遇到的问题，以及和自定义模板对比的劣势：

当然有，而且不少都是实际开发中会碰到的痛点：

• 隐藏配置导致灵活性缺失：CRA把Webpack、Babel这些核心配置都封装得严严实实，日常开发用着省心，但一旦你需要自定义高级配置——比如加个特殊的loader、调整构建输出路径、优化打包体积的细节——要么就得用eject命令把所有配置暴露出来（但eject之后就没法再回到CRA的官方维护了，配置会变得非常复杂，新手很容易搞砸），要么就得依赖react-app-rewired这类第三方工具，但这类工具经常会有版本兼容问题，升级CRA的时候容易踩坑。
• 冗余拖慢项目初始化：CRA默认集成了一大堆你可能用不上的东西——比如Jest、React Testing Library这类测试工具，还有PWA相关的插件、ESLint的默认规则等等。对于小型项目或者只需要基础React功能的场景来说，这些冗余的依赖会增加npm/yarn的安装时间，还会让项目初始体积变大。
• 新特性适配滞后：当React本身或者Webpack、Babel这类工具出了新特性，CRA的官方更新往往需要一段时间才能跟上。如果你急着用这些新特性，要么自己手动折腾配置，要么只能等官方发布新版本，非常被动。
• 固定结构缺乏个性化：CRA的默认项目结构是固定的，如果你有自己的开发习惯或者团队规范——比如特定的目录分层、全局样式的约定、状态管理工具的预设——你得手动去修改调整，浪费不少时间。

和完全自定义的boilerplate比起来，CRA的劣势会更明显，主要体现在这些方面：

• 定制化程度不在一个层级：自定义模板是完全按照你的需求打造的——你可以只保留必要的依赖，提前预设好常用的工具（比如Redux、React Router、Tailwind CSS），甚至把团队常用的基础组件、目录结构、代码规范都固化进去。而CRA是通用模板，所有项目初始化出来都是一个样，你得花额外时间去删改冗余内容、添加自己需要的工具。
• 配置可控性几乎为零：自定义模板里，你可以完全掌控Webpack、Babel的每一项配置，想怎么调就怎么调——比如优化构建速度、配置按需加载、自定义环境变量的处理逻辑。而CRA要么不让你碰核心配置，要么得用hack的方式修改，遇到复杂需求的时候特别受限。
• 冗余依赖问题被放大：自定义模板只安装你真正需要的依赖，比如如果不需要测试，就不用加Jest；不需要PWA，就完全不集成相关插件。但CRA不管你用不用，都把这些东西打包进去，导致项目初始化后就有一堆冗余的文件和依赖，清理起来很麻烦。
• 项目扩展成本更高：当项目需要扩展复杂功能——比如加SSR（服务端渲染）、集成TypeScript之外的类型检查工具、自定义构建脚本——自定义模板可以直接在现有配置上修改，而CRA要么得 eject 之后大改配置，要么找第三方插件来兼容，过程繁琐还容易出各种奇怪的bug。
• 无法沉淀团队协作规范：如果是团队协作，自定义模板可以把团队的代码规范、目录结构、常用工具、甚至通用业务逻辑都固化进去，新人接手项目直接用模板初始化，就能和团队保持一致。但CRA的默认结构和配置如果和团队规范不符，每个人都得手动调整，很容易出现项目结构不一致的情况，增加协作成本。

内容的提问来源于stack exchange，提问作者Vishnu Anilkumar