为什么选择 HashRouter 而非 History 模式？

H5 需高度渗透至各类 App WebView 且频繁跨二级域名部署。History 模式强依赖服务端 Nginx 配置，而 Hash 模式实现了产物的“全环境自适应”与零配置兼容性，是鲁棒性的首选。

什么是双轨制状态管理？

全局背包（Plain Store）存储版本、Token 等低频元数据；域内工坊（Redux）负责票务、购物车等高复杂度业务，并实施“随用随装，用完即焚”策略，确保内存的高效利用。

引入 Model 层有哪些核心价值？

通过在 Model 层进行数据清洗与领域建模，实现了逻辑下沉与视图上浮。组件层不再承载业务复杂计算，显著提升了代码的可读性与复用度。

H5 架构进化论：如何在复杂业务中构建鲁棒的前端基座

前言：工程设计的“实战哲学”

构建一套企业级 H5 架构，其目标往往是极度单纯却又充满挑战的：一套代码基座，必须跨越 N 个流量渠道、适配全球化多语种，且在极端弱网下保持秒开率。

为了达成这一目标，我们拒绝了“过度设计”的诱惑，转而拥抱基于业务痛点的“实效方案”。以下这 7 条法则，是我们从数千万次用户真实访问中萃取出的生存智慧。

一、路由抉择：为了“鲁棒性”而放弃“优雅”

策略：强兼容性的 HashRouter

在追求 RESTful 风格的今天，我们果断选择了 Hash 模式（`/#/path`）。

- 核心考量：H5 需要高度渗透至各种魔改版的 App WebView，且需频繁跨二级域名部署。

- 工程价值：History 模式对服务端配置（Nginx `try_files`）有强依赖，而 Hash 模式实现了产物的“全环境自适应”。在逻辑诡异的第三方 App 容器中，Hash 路由的零配置兼容性是系统稳定运行的最后一道防线。

二、状态治理：拒绝“全量堆砌”的熵增

策略：双轨制状态管理（Plain Store + Redux）

将所有数据塞进全局 Store 是大型项目腐化的开始。我们确立了双轨制：

1. 全局背包 (Plain Store)：针对版本号、城市标识、用户 Token 等高频、低频更新的元数据，使用简易 Store 配合 `sessionStorage` 兜底，确保页面刷新或参数透传时的状态自恢复。

2. 域内工坊 (Redux)：针对票务、购物车等强交互、高复杂度的业务逻辑，实施“随用随装，用完即焚”的动态注入策略。一旦用户离开该业务域，内存立即释放，确保长链路操作下的应用轻盈。

三、性能压缩：颗粒化按需加载

策略：80+ 业务路由的全量 Code-Splitting

首屏白屏时间是 H5 的生命线。我们利用 `react-loadable` 将 80 多个功能页面切割为独立的 JavaScript 分片。

- 成果：用户不再需要为整个应用的体积买单，仅下载当前触达路径的必要代码。在海外 3G/4G 环境下，这一决策成功将 FCP（首次内容绘制）压降了 55% 以上。

四、研发能效：解耦渠道差异配置

策略：抽象“渠道配置中心” (store/channel.js)

面对运营频繁发起的“渠道特供版”或“异业合作版”需求，频繁修改逻辑代码是低效的。我们将所有业务开关、视觉风格及接口环境参数抽离至配置中心。架构逻辑与渠道数据彻底解耦：代码基座保持纯净，通过外挂配置表即可瞬间实现应用的“千人前面”。

五、目录设计：以“业务域”为物理边界

策略：Domain-driven 目录架构

拒绝按技术类型分的“全家桶”目录。我们按 Order、Pay、Product 等业务领域进行物理隔离。

- 协作收益：支付团队的改动绝不会波及商品详情。这种高内聚设计极大降低了大型团队协作时的代码冲突与回归测试成本。

六、国际化深度：不止于翻译

策略：Context-aware 上下文管家 (jegoCtx)

跨境业务真正的挑战是货币符号、日期溢出及跨时区逻辑。我们封装了 `jegoCtx` 对象，它作为全局管家，静默处理所有与“地域”相关的展示策略。组件开发者只需关注 UI 逻辑，无需关心底层的 ISO 编码与换算。

七、逻辑下沉：给 UI 组件卸下“重担”

策略：引入逻辑模型层 (Model Layer)

React 组件应仅仅负责“视图表达”，而非“业务计算”。

我们强制引入了 `CouponModel` 等模型类。原始接口数据在进入视图前需进行“预清洗”与“领域建模”。

- 价值：视图层不再充斥 `if (status === 1 && type === 'vip')` 等面条代码。逻辑下沉，视图上浮，代码的可读性与复用度得到质的飞跃。

总结

这套架构并无炫目的黑科技，其核心在于对平衡点的精准捕捉。在可维护性、运行性能与交付速度的“黄金三角”中，我们选择了一条最符合业务体量的稳健道路。架构的终极价值，是让团队少加班，让用户少等待。

H5 架构进化论：如何在复杂业务中构建鲁棒的前端基座

TL;DR · 核心结论

前言：工程设计的“实战哲学”

一、路由抉择：为了“鲁棒性”而放弃“优雅”

二、状态治理：拒绝“全量堆砌”的熵增

三、性能压缩：颗粒化按需加载

四、研发能效：解耦渠道差异配置

五、目录设计：以“业务域”为物理边界

六、国际化深度：不止于翻译

七、逻辑下沉：给 UI 组件卸下“重担”

总结

TL;DR

该专题下的阅读路径

常见问题 FAQ

发表评论

TL;DR · 核心结论

前言：工程设计的“实战哲学”

一、 路由抉择：为了“鲁棒性”而放弃“优雅”

二、 状态治理：拒绝“全量堆砌”的熵增

三、 性能压缩：颗粒化按需加载

四、 研发能效：解耦渠道差异配置

五、 目录设计：以“业务域”为物理边界

六、 国际化深度：不止于翻译

七、 逻辑下沉：给 UI 组件卸下“重担”

总结

TL;DR

该专题下的阅读路径

常见问题 FAQ

发表评论

一、路由抉择：为了“鲁棒性”而放弃“优雅”

二、状态治理：拒绝“全量堆砌”的熵增

三、性能压缩：颗粒化按需加载

四、研发能效：解耦渠道差异配置

五、目录设计：以“业务域”为物理边界

六、国际化深度：不止于翻译

七、逻辑下沉：给 UI 组件卸下“重担”