React跨端应用中country-state-city包前后端部署方案选型

以目前主流使用的v3.x稳定版为例，公开统计的体积数据如下：

• 原始未压缩体积（含全部国家、州、城市JSON数据源）：约2.3MB
• 生产环境minify压缩后体积：约1.1MB
• 线上传输时gzip压缩体积为380KB_{420KB，brotli压缩体积为290KB}320KB
  要注意：这个包几乎不支持Tree Shaking，核心就是全量静态行政区划数据，只要在代码中引入，不管你实际用到多少个地区的内容，整包都会被打进生产bundle，没法靠常规的按需引入手段减体积。

优先选方案2（包部署在后端、前端按需请求接口拿数据），尤其是需要同时适配移动端和网页端的场景，这个方案的合理性远高于前端直接引入

为什么不推荐方案1（前端直接加载整包） #

• 加载体验差：哪怕用户全程不碰地址选择功能，只要对应代码块被加载，就要额外拉取数百KB的静态资源。移动端弱网环境下会直接拉长页面可交互时间，甚至出现加载超时、白屏的问题。
• 运行开销大：全量地址数据加载后会长期占用前端运行内存，低端安卓移动设备上很容易加剧页面卡顿、滚动掉帧的问题。
• 迭代麻烦：后续如果要更新行政区划数据（比如行政区拆分、更名、新增），必须重新发布前端版本，所有用户得手动刷新才能拿到最新数据，覆盖成本很高。

方案2的核心优势 #

• 全端性能表现好：前端只在用户实际操作地址选择器、切换国家/州选项时才发请求，单次接口返回的数据量极小——选完国家返回对应州/省列表只有几百字节到1KB，选完州返回对应城市列表最多也就几KB，完全不影响首屏加载速度，哪怕是2G弱网环境，请求等待时间也几乎感知不到。
• 维护成本低：要更新行政区划数据只需要改后端的数据源就行，不用发前端版本，所有用户请求时自动拿到最新数据，没有版本覆盖的问题。
• 优化空间足：可以把用户常用的国家、热门城市列表存在前端本地缓存里，进一步减少重复请求；还能结合IP定位直接给用户预选默认地址，交互体验更好。

只有一种情况例外：如果你做的是纯离线可用的PWA或者内网封闭应用，再考虑前端引入的方案，就算是这种场景也建议手动把包内的JSON拆成按国家编码单独存储的分片，不要直接整包引入。

内容的提问来源于stack exchange，提问作者Bear Bile Farming is Torture