01. 序言
这个 H5 项目承载景点百科、票务、活动聚合、社交动态等业务，要支持多语言，独立 Web 和 App 内嵌都要跑。目标是：在不确定的网络和设备环境里，给用户尽量确定的流畅体验。
下面抛开业务表象，聊聊技术骨架和选型理由。
02. 核心架构
架构就是做权衡。在"追新技术"和"保生产稳定"之间，我们选了 SPA + Vue 2 这套稳的。
2.1 基础框架：SPA
移动端每次强刷新都在消耗用户耐心。SPA 把页面切换变成组件替换，白屏间隙没了，体验更顺。
为啥坚持 Vue 2？在移动 H5 里，Vue 2 生态已经够成熟。我们这种重展示、轻运算的场景，Options API 维护成本低，协作也顺手。不追技术时尚，要工程实效。
2.2 状态管理：模块化拆分
业务一多，全局 State 很容易变成大杂烩。我们用 Vuex，但重点在严格模块化。
State 拆成 10+ 个业务域：详情页不干涉购物车，用户会话和社区 Feed 流分开。模块之间耦合低，多人并行开发时合并代码没那么痛苦。
03. 性能工程
跨境、漫游场景下弱网是常态，得在有限带宽里尽量压加载速度。
3.1 路由懒加载
以前把所有代码打一个大 Bundle，用户去海边度假却背着一箱冬装。我们做了路由级懒加载：只有用户点进"票务预订"之类的地方，才加载对应代码。首屏包体积减了 40% 以上，FCP 明显改善，3G/4G 下也能较快打开。
3.2 运行时配置：Build Once, Run Anywhere
传统做法是 Dev/Test/Prod 各打各的镜像，浪费算力还容易出环境不一致的诡异 Bug。
我们改成运行时配置：API 域名、环境标识等从构建产物里剥出来，放在外挂配置文件。代码包是无状态的，运行时根据宿主域名动态加载配置。测试通过的制品可以直接上生产，环境差异带来的发布风险基本消除。
04. 视觉与交互
4.1 弹性适配
Android 屏幕碎片化，前端适配一直是难题。我们用 Rem 做相对单位，配合 Vant，搭了一套标准化的视觉方案。不同尺寸下 UI 自动适配，跨机型一致性好，UI 走查返工少很多。
4.2 混合开发：通用桥接层
项目既要独立 Web 跑，又要嵌在原生 App 里。
我们做了通用桥接层：自动嗅探运行环境（App 内核 vs 普通浏览器）。在 App 内调 Native SDK 做沉浸式导航、账号同步、设备能力；在 App 外回退到 H5 登录和 URL 导航。同构设计，一套代码两端跑，维护成本减半。
05. 结语
这套架构不是堆新技术，而是按业务场景找最优解。
选成熟框架，因为稳定优先；选运行时配置，因为交付效率关键；做模块化和懒加载，因为可维护性决定系统能活多久。
在开发效率、运行性能、维护成本之间找了个平衡点。后续业务演进，还可以用微前端等手段扩展，目前算是一个稳的基底。