冲天香阵透长安，满城尽带黄金甲。这篇文章主要讲述字节跳动是如何落地微前端的相关的知识，希望能为你提供帮助。
本文内提及的 Garfish 微前端解决方案已开源：??https://github.com/modern-js-...??（目前的 Garfish 作为字节跳动各部门应用最广泛的微前端解决方案已经服务超过 100+ 前端团队，400+ 项目），另外字节跳动的现代 Web 工程体系即将开源（??Modern.js??），深度集成 Garfish 提供了对微前端的原生支持，提供更开箱即用的能力，敬请期待！微前端的出现的背景和意义微前端是什么：微前端是一种类似于微服务的架构，是一种由独立交付的多个前端应用组成整体的架构风格，将前端应用分解成一些更小、更简单的能够独立开发、测试、部署的应用，而在用户看来仍然是内聚的单个产品。
微前端诞生在两个大的背景下，在提倡拥抱变化的前端社区可以看到新的框架、技术、概念层出不穷，并且随着 Web 标准的演进，前端应用已经具备更好的性能、更快的开发效率。但随着而来的是应用的复杂程度更高、涉及的团队规模更广、更高的性能要求，应用复杂度已经成为阻塞业务发展的重要瓶颈。
微前端就是诞生于 Web 应用日益复杂化的场景中，因为随着网络速度、计算机硬件水平的提升和 Web 标准的演进，过去 Web 应用用户体验远不如传统的应用软件时代已逐渐远去，两者之间在用户体验上的差距不断缩减，并且由于 Web 应用开发速度快、用完即走等特性，导致的一个最终结果就是「能用 Web 技术实现的应用，最终都会通过 Web 来实现」。在近几年涌现了一大批之前只能在传统 PC 软件中才能看到的优秀产品，例如：Photoshop、Web Office、Web IDE。尽管随着 Web 标准的演进，前端工程化也在不断演变，从模块化到组件化在到现在的工程化，但在面对跨团队大规模开发、跨团队企业级应用协作，现有的分治设计模式仍然显得有心无力。
大规模 Web 应用的困局尽管 Web 应用的复杂度和参与人数以爆炸式的增长速度，但却没有一种新的架构模式来解决现有的困境，并同时兼顾 DX（developer experience）和 UX（user experience）。
以字节跳动内「研发中台」举例，在研发日常工作中需要使用非常多的研发系统，例如：代码管理、代码构建、域名管理、应用发布、CDN 资源管理、对象存储等。站在整个公司研发的角度考虑，最好的产品形态就是将所有的研发系统都放置同一个产品内，用户是无法感知他在使用不同的产品，对于用户而言就是单个产品不存割裂感，也不需要去学习多个平台，仅仅需要学习和了解字节跳动内的「研发中台」即可。
在字节跳动内这一类应用随处可见，由于字节跳动内存在大量业务线，每一条业务线都会诞生大量的中台系统，并且还在指数增长，以字节跳动内电商业务举例，对于电商运营的日常工作来说，其实与研发日常工作一样，围绕在：商品、商家、品牌、风控、营销等工作上，那么对于电商运营来说怎么样才最高效的电商运营系统呢，由于整个系统涉及范围较广，在实际的研发过程中必然会以功能或业务需求垂直的切分成更小的子系统，切分成各种小系统后尽管由于分治的设计理念提升了开发者体验，但是一定程度上降低了用户体验。那能否以一种新的架构模式，既保开发者体验，又能提升用户体验呢。
传统 Web 应用的利与弊这里简单分析一下传统 Web 应用在开发大规模应用和涉及多研发团队协作时遇到的一些困境，以上面案例中的「电商运营平台」举例，对于电商运营而言商品、商家、品牌等都是电商运营平台能力的一部分，而不是独立之间的孤岛。若以传统的前端研发模式进行开发，那么此时有两种项目设计策略：
- 将平台内多个系统放置同一个代码仓库维护 ，采用 SPA（Single-page Application） 单页应用模式
- 将系统分为多个仓库维护，在首页聚合所有平台的入口，采用 MPA（Multi-page Application）多页应用模式
若采用多个系统放置同一个项目内维护：
- 优势：
- 更好的性能
- 具备局部更新，无缝的用户体验
- 提前预加载用户下一页的内容
- 统一的权限管控、统一的 Open API 开发能力
- 更好的代码复用，基础库复用
- 统一的运营管理能力
- 不同系统可以很好的通信
- SPA 应用特有优势：
- 劣势：
- 代码权限管控问题
- 项目构建时间长
- 需求发布相互阻塞
- 代码 commit 混乱、分支混乱
- 技术体系要求统一
- 无法同时灰度多条产品功能
- 代码回滚相互影响
- 错误监控无法细粒度拆分
尽管降低了开发体验，如果对项目整体的代码拆分，懒加载控制得当，其实对于使用平台的用户而言体验却是提升的，这一切都归咎于 SPA 应用带来的优势，SPA 应用跳转页面时无需刷新整个页面，路由变化时仅更新局部，不用让用户产生在 MPA 应用切换时整个页面刷新带来的抖动感而降低体验，并且由于页面不刷新的特性可以极大程度的复用页面间的资源，降低切换页面时带来的性能损耗，用户也不会感知他在使用不同平台。
若采用拆分成多个仓库维护
- 优势
- 可以以项目维度拆分代码，解决权限管控问题
- 仅构建本项目代码，构建速度快
- 可以使用不同的技术体系
- 不存在同一个仓库维护时的 commit 混乱和分支混乱等问题
- 功能灰度互不影响
- 劣势
- 用户在使用时体验割裂，会在不同平台间跳转，无法达到 SPA 应用带来的用户体验
- 只能以页面维度拆分，无法拆分至区块部分，只能以业务为维度划分
- 多系统同灰度策略困难
- 公共包基础库重复加载
- 不同系统间不可以直接通信
- 公共部分只能每个系统独立实现，同一运维通知困难
- 产品权限无法进行统一收敛
背景和意义总结通过以上两个场景案例，其实可以发现由于 Web 应用在逐步取代传统的 PC 软件时，大规模 Web 应用在面对高复杂度和涉及团队成员广下无法同时保证 DX 和 UX 的困境。传统的分而治之的策略已经无法应对现代 Web 应用的复杂性，因此衍生出了微前端这样一种新的架构模式，与后端微服务相同，它同样是延续了分而治之的设计模式，不过却以全新的方法来实现。
微前端解决方案上一节总结了微前端出现的背景和意义，并且了解了两种传统 Web 应用的研发模式：SPA（Single-page Application）、MPA（Multi-page Application）在涉及人员广和项目复杂度高的场景下带来的劣势，那么期望能有一种新的架构能同时具备 SPA 和 MPA 两种架构优势，并同时提升 DX（developer experience）和 UX（user experience）呢？
那在理想的情况下，期望能达到，将一个复杂的单体应用以功能或业务需求垂直的切分成更小的子系统，并且能够达到以下能力：
- 子系统间的开发、发布从空间上完成隔离
- 子系统可以使用不同的技术体系
- 子系统间可以完成基础库的代码复用
- 子系统间可以快速完成通信
- 子系统间需求迭代互不阻塞
- 子应用可以增量升级
- 子系统可以走向同一个灰度版本控制
- 提供集中子系统权限管控
- 用户使用体验整个系统是一个单一的产品，而不是彼此的孤岛
- 项目的监控可以细化到到子系统
微前端的整体架构那么如何提供一套既具备 SPA 的用户体验，又具备 MPA 应用带来的灵活性，并且可以实现应用间同灰度，监控也可以细化到子系统的解决方案呢？目前在字节跳动内应用的微前端解决方案「Garfish」就是这样的一套方案 ，该解决方案主要分为三层：部署侧、框架运行时、调试工具，采用的是 SPA 的架构。
解决方案整体架构
微前端部署平台部署平台作为微前端研发流程中重要的一环，主要提供了：微前端的服务发现、服务注册、子应用版本控制、多个子应用间同灰度、增量升级子应用、下发子应用信息列表，分析子应用依赖信息提取公共基础库降低不同应用的依赖重复加载。
用于解决微前端中子应用的独立部署、版本控制和子应用信息管理，通过 Serverless 平台提供的接口或在渲染服务中下发主应用的 html 内容中包含子应用列表信息，列表中包括了子应用的详细信息例如：应用 id、激活路径、依赖信息、入口资源等信息，并通过对于子应用的公共依赖进行分析，下发子应用的公共依赖，在运行时获取到子应用的信息后注册给框架，然后在主应用上控制子应用进行渲染和销毁。
微前端运行时
Why not iframe谈到微前端绕不开的话题就是为什么不适用 iframe 作为承载微前端子应用的容器，其实从浏览器原生的方案来说，iframe 不从体验角度上来看几乎是最可靠的微前端方案了，主应用通过iframe 来加载子应用，iframe 自带的样式、环境隔离机制使得它具备天然的沙盒机制，但也是由于它的隔离性导致其并不适合作为加载子应用的加载器，iframe 的特性不仅会导致用户体验的下降，也会在研发在日常工作中造成较多困扰，以下总结了 iframe 作为子应用的一些劣势：
- 使用iframe 会大幅增加内存和计算资源，因为 iframe 内所承载的页面需要一个全新并且完整的文档环境
- iframe 与上层应用并非同一个文档上下文导致
- 主应用劫持快捷键操作
- 事件无法冒泡顶层，针对整个应用统一处理时效
- 事件冒泡不穿透到主文档树上，焦点在子应用时，事件无法传递上一个文档流
- 跳转路径无法与上层文档同步，刷新丢失路由状态
- iframe 内元素会被限制在文档树中，视窗宽高限制问题
- iframe 登录态无法共享，子应用需要重新登录
- iframe 在禁用三方 cookie 时，iframe 平台服务不可用
- iframe 应用加载失败，内容发生错误主应用无法感知
- 难以计算出 iframe 作为页面一部分时的性能情况
- 无法预加载缓存 iframe 内容
- 无法共享基础库进一步减少包体积
- 事件通信繁琐且限制多
尽管难以将 iframe 作为微前端应用的加载器，但是却可以参考其设计思想，一个传统的 iframe 加载文档的能力可以分为四层：文档的加载能力、HTML 的渲染、执行 javascript、隔离样式和 javaScript 运行环境。那么微前端库的基础能力也可以参考其设计思想。
从设计层面采取的是基座+子应用分治的概念，部署平台负责进行服务发现和服务注册，将注册的应用列表信息下发至基座，通过基座来动态控制子系统的渲染和销毁，并提供集中式的模式来完成应用间的通信和应用的公共依赖管理，因此 Garfish 在 Runtime 层面主要提供了以下四个核心能力：
- 加载器（Loader）
- HTML 入口类型，拆解 HTML Dom、Script、Style
- JS 入口类型，提供基础 Dom 容器
- 负责注册平台侧提供的应用列表
- 负责加载和解析子应用入口资源
- 预加载能力
- 解析子应用导出内容
- 沙箱隔离（Sandbox）
- 提供代码执行能力，收集执行代码时存在的副作用
- 提供销毁收集副作用的能力
- 支持沙箱多实例，收集不同实例的副作用
- 路由托管（Router）
- 解决不同应用间的路由不同步问题
- 提供路由劫持能力，在主应用上管控子应用路由
- 提供路由驱动能力来拼装完整的平台的能力
- 子应用通信（Store）
- 建立通信桥梁
- 提供共享机制
应用生命周期
整个微前端子应用的生命周期基本可以总结为：
- 渲染阶段
- 若入口类型为 HTML 类型，将开始解析和拆解子应用资源
- 若入口类型为 JS，创建子应用的挂点 DOM
- 主应用通过路由驱动或手动挂载的方式触发子应用渲染
- 开始加载应用的资源内容，并初始化子应用的沙箱运行时环境
- 判断入口类型
- 将子应用存在”副作用“（对当前页面可能产生影响的内容）交由沙箱处理
- 开始渲染子应用的 DOM 树
- 触发子应用的渲染 Hook
- 销毁阶段
- 若路由变化离开子应用的激活范围或主动触发销毁函数，触发应用的销毁
- 清除应用在渲染时和运行时产生的副作用
- 移除子应用的 DOM 元素
加载器的设计
加载器的整体设计理念其实与 React-loadable 非常类似，具备以下能力：
- 异步加载组件资源
- 可以预加载资源
- 可以缓存组件资源
- 缓存组件实例
由于 HTML 入口类型天然具备独立、开发、测试的特性，在微前端整体架构设计中，对于跨团队协作而言，最好的研发模式是能降低其沟通成本，而降低沟通成本的最好方式是不沟通，所以一般项目类型都尽可能的推荐用户使用 HTML 的入口类型。
那么针对 HTML 入口类型的加载器需要做一些什么呢，下面是一张浏览器的渲染过程图：
针对浏览器的渲染过程也可将其分为：HTML 文本下载、 HTML 拆解为语法树、拆解语法树中具备”副作用的内容“（对当前页面可能产生影响的内容）如 Script、Style、Link 并交由沙箱处理进行后渲染，与一般的子应用不同的是需要子应用提供 provider，provider 中包含了子应用渲染和销毁的生命周期，这两个 Hook 可以应用缓存模式中进一步增强应用的渲染速度和性能。
沙箱的设计
为什么需要沙箱其实在过去的 Web 应用中是很少提及到沙箱这一概念的，因为组件的开发一般都会由研发通过研发规范来尽可能的去避免组件对当前应用环境造成副作用，诸如：组件渲染后添加了定时器、全局变量、滚动事件、全局样式并且在组件销毁后会及时的清除子应用对当前环境产生的副作用。
与组件完全不同的是微前端是由多个独立运行的应用组成的架构风格，这些系统可能分别来自不同的技术体系。项目的开发、测试从空间和时间上都是分离的，由于没有 iframe 一样原生能力的隔离很难应用间不发生冲突，这些冲突可能会导致应用发生异常、报错、甚至不可用等状态。
以 Webpack4 JsonpFunction 为例在 Webpack5 中提供了一个重要的功能就是 Module Federation，随着 Webpack 5 推出 Module Federation ，与 Webpack 4 发生变化的一个重要配置就是 ?
?JsonpFunction??
属性变为了
??chunkLoadingGlobal??，并且由原来的默认值
??webpackJsonp??
变成了默认使用
??output.library??
名称或者上下文中的
??package.json??
的 包名称(package name)作为唯一值（webpack.js.org/issues/3940）。为什么会发生这个转变呢，如果了解过 Webpack 构建产物的一定会知道 Webpack 通过全局变量存储了分 chunk 后的产物，用于解决分包 chunk 的加载问题。由于 Webpack 5 引入 Module Federation 页面中可能会同时存在两个以上的 Webpack 构建产物，如果还是通过是通过同一个变量存储要加载的 chunk ，必然会造成产物之间的互相影响。
通过 Webpack 4 到 Webpack 5 支持 Module Federation 之后可以发现，在一个基础库尚未考虑默认兼容多实例的场景下，贸然将其作为多实例使用很可能会造成应用无法按照预期运行，更为严重的是你以为其正常运行了其实应用已经发生了严重的内存泄漏或不可预知的情况，倘若将 Webpack 构建产物的应用多次动态的在页面中运行，将会发现已经造成严重的内存泄漏，因为 Webpack 会增量的向全局存储 chunk 的变量上挂载模块以及依赖信息，简单来说就是每次执行 Webpack 构建的子应用代码都会向 webpackJsonp 数组 push 大量的数据，最终造成内存泄漏，直至页面崩溃。
沙箱的核心能力为了保证应用能够稳定的运行且互不影响，需要提供安全的运行环境，能够有效地隔离、收集、清除应用在运行期间所产生的副作用，那应用运行期间主要会产生哪些副作用呢，可以将其分为以下几类：全局变量、全局事件、定时器、网络请求、localStorage、Style 样式、DOM 元素。
在 Garfish Runtime 中的沙箱主要能力也是围绕在这一块的能力建设上，针对子应用可能产生的副作用类型主要分为两类，一类是：静态副作用、另一类则是：动态副作用。这里静态副作用和动态副作用分别指的是什么呢，静态副作用指的是 HTML 中静态标签内容例如：Script 标签、Style 标签、Link 标签，这些内容属于在 HTML 文档流中就包含的，另外一部分副作用属于动态副作用，动态副作用指的是由 JavaScript 动态创建出来的，例如 JavaScript 可以动态创建 Style、动态创建 Script、动态创建 Link、动态执行代码、动态添加 DOM 元素、添加全局变量、添加定时器、网络请求、localStorage 等对当前页面产生副作用的内容。
针对子应用的静态副作用的收集比较简单，Loader 核心模块上已经提供了子应用入口资源类型的分析和拆解，可以从子应用 DOM 树中轻松拆解获取副作用内容，那么对于静态副作用已经可以完成有效的收集、清除，但是尚未具备隔离的能力。动态创建的副作用都是通过 JavaScript 来动态创建的，需要收集到 JavaScript 运行时产生的副作用，并提供副作用的隔离和销毁能力。
沙箱设计的两种思路在 Garfish 微前端中，如何有效收集、隔离、清除应用的副作用是保障应用能够平稳运行的核心能力之一。沙箱的主要能力也在于能够捕获动态创建的副作用，对应用的副作用进行隔离和清除。
那么如何能够有效的捕获到动态创建的副作用、收集、并隔离呢？目前 Garfish 提供了两种设计思路，一种是快照模式，另外一种是 VM 模式。
快照沙箱顾名思义，在应用运行前通过快照的模式来保存当前执行环境，在应用销毁后恢复回应用之前的执行环境，用于实现应用间副作用的隔离和清除。类似于 “SL 大法”，通过 save 存储环境，通过 load 加载环境的模式。
代码实现思路
核心设计思想简述：
- 针对每一种副作用提供一个 Patch 类，这个类需要提供 save 和 load 两个方法
- Save 对应着该副作用的环境快照存储，Load 对应着销毁该副作用的销毁恢复环境
- 并且针对每一种 Patch 还可以存储其在运行期间发生的变化，在优化场景时并不用所有代码，仅恢复执行环境即可
通过上面的代码可以发现，在同时运行多个快照沙箱实例时，在代码执行顺序非线性的场景下，并不能有效的收集和处理应用的副作用，也基于此快照沙箱无法使用在非线性呢多实例的场景中，因此也进一步推出了 VM（virtual machine） 沙箱。
维基百科关于 VM 的解释：在计算机科学中的体系结构里，是指一种特殊的软件，可以在计算机平台和终端用户之间创建一种环境，而终端用户则是基于虚拟机这个软件所创建的环境来操作其它软件。虚拟机（VM）是计算机系统的仿真器，通过软件模拟具有完整硬件系统功能的、运行在一个完全隔离环境中的完整计算机系统，能提供物理计算机的功能。
在 Node 中也提供了 VM 模块，不过不过不同于传统的 VM，它并不具备虚拟机那么强的隔离性，并没有从模拟完整的硬件系统，仅仅将指定代码放置了特定的上下文中编译并执行代码，所以它无法用于不可信来源的代码。
参考 Node 中 VM 模块的设计，以及 JavaScript 词法作用域 的特性，可以设计出 VM 沙箱，不过与传统的 VM 差异也同样存在，它并能执行不可信的代码，因为它的隔离能力仅限于将其运行在一个指定的上下文环境中。
从而得出以下设计
隔离环境需要哪些上下文针对副作用的类型：全局变量、全局事件、定时器、网络请求、localStorage、Style 样式、DOM 元素，分别提供了全新的执行上下文：
- Window
- 用于隔离全局环境
- document
- 收集 DOM 副作用
- 收集 Style 副作用，进行处理
- 收集 Script，继续放置沙箱处理
- 用于捕获动态创建的 DOM 节点、Style、Script
- timeout、interval
- 处理定时器
- localstorage
- 隔离 localStorage
- listener
- 收集全局事件
新的执行上下文哪里来新的执行上下文有两个来源，
- 来源于当前环境
- 来源于 iframe 的执行环境
快照沙箱和 VM 沙箱能力对比
路由系统的设计
在于现代 MVC 的设计思想，前端框架的设计思想也一直在发生变更，现代 Web 前端框架提供的最经典的能力莫过于将 MVC 中的 Constroller 变为了 Router，目前几乎主流的前端框架都支持路由驱动视图，仅提供一个 Router Map 路由表，无需关注控制任何路由状态即可完成跳转后的路由更新。
通过微前端出现的背景和意义，可以了解到微前端主要是用于解决：应用增量升级、多技术体系并存、构建大规模企业级 Web 应用而诞生的。那么在基于 SPA 的微前端架构中也可以了解到，目前微前端主要是采用应用分而治之 + 动态加载 + SPA 应用的模式来解决大规模应用带来的一系列问题。在以组件为颗粒度的 SPA 应用中组件内部是不需要关心路由的，但是在微前端中主要通过应用维度来拆分，那么拆分的应用也可能是一个独立的 SPA 应用，那么此时主应用与子应用的关系如何编排呢？
微前端应用中理想的路由调度假设存在一个 Garfish 站点，这个站点它是由主应用+三个子应用构成，主应用的 basename 为 ?
?/demo??，并存在三个 Tab 分别指向跳转至不同的应用，理想的路由效果：- 在点击 vue-app Tab，跳转至
?
?/demo/vue-app?? 路由后，分别激活 ??vue-app?? 下，为 Vue 类型的 A 应用和 B 应用，并激活 A 应用和 B 应用中的 Home 组件 - 点击 React-app Tab 进入到
?
?/demo/react-app?? 路由后，分别激活 ??react-app?? 下，为 React 类型的 C 应用，并激活 C 应用的 Home 组件 - 在激活 C 应用的基础上，点击 Detail 按钮，跳转至
?
?/demo/react-app/detail??，并激活 C 应用的 detail 组件。 - 点击浏览器返回按钮展示，跳转
?
?/demo/react-app/detail??，并激活 C 应用的 Home 组件，至此完成浏览器的基本路由跳转能力。
不考虑任何路由处理的场景假设存在一个 Garfish 站点，这个站点它是由主应用+一个子应用构成。由于 Garfish 采用的是 SPA 架构，子应用与主应用所处于同一个执行上下文，子应用的路由原样反应在主应用上。
那么此时分别跳转到：?
?/home??、??/detail??路由会发现哪些问题呢？- 假定跳转的方法可以同时触发主子应用路由更新，主应用路由和子应用路由会同时发生抢占情况，后渲染的组件会覆盖先渲染的路由组件
- 在触发路由跳转方后，只有主应用视图触发刷新、只有子应用视图刷新、或都不刷新
- 「视图的路由状态维护在框架内部」，通过原生跳转无法触发视图更新
?/home??、??/detail??、??/test??
路由时分别触发对应的组件视图，但是倘若子应用路由中也存在
??/detail??视图呢，由于应用的开发采用分治的模式，应用的开发从空间和时间上都是分离的，无法保证应用间的路由不发生路由抢占的情况。「通过 history 路由跳转无法保证应用能够触发视图更新」，在通过 history api 进行路由跳转时，是无法触发应用视图更新，假设存在一个 React 应用 A，存在一个组件视图 Test，分别通过 React 提供的路由方法跳转和原生的路由跳转进行观察：
Hash 和 History 路由模式目前主流的 SPA 前端应用基本上都支持两种路由模式，一种是：hash 模式、另一种则是 History 路由模式，两者的优劣和使用并不在本文的讨论范围之内，这里仅做在微前端这种分离式开发模式下的介绍，在微前端这种分离式 SPA 应用开发的模式下该选择哪种路由模式，以及多 SPA 应用下他们的路由应该如何编排：
【字节跳动是如何落地微前端的】假设站点地址为：?
?http://garfish.bytedance.net??正常路由情况
- 主应用 history 模式、子应用 history 模式
- 主应用（
basename: /example）：
- 主应用所有路由基于：
http://garfish.bytedance.net/example例 - 例如跳转到：/appA，
http://garfish.bytedance.net/example/appA/子
- 子应用（
basename: /example/appA）：
- 子应用所有路由基于：
http://garfish.bytedance.net/example/appA - 跳转到子应用的 /detail 页，
http://garfish.bytedance.net/example/appA/detail
- 特点：
- 当主子应用分别为 history 模式时，子应用的路由基于主应用基础路由并带上自己的业务路由
- 路由同步到主应用路由上，通过 子应用 scope 命名空间隔离（子应用 A，提供 appA 的 scope）主应用和其他应用的路由冲突，并将子应用
- 路径符合用户和开发者认知和理解
- 支持嵌套层级使用，并继续通过 scope 的命名空间保证路由可读
- \\
- 主应用 history 模式、子应用 hash 模式
- 主应用（
basename: /example）：
- 主应用所有路由基于：
http://garfish.bytedance.net/example - 例如跳转到：/appA，
http://garfish.bytedance.net/example/appA/
- 子应用（
basename: /example/appA）：
- 子应用所有路由基于：
http://garfish.bytedance.net/example/appA - 从主应用：
http://garfish.bytedance.net/example/appA，跳转到子应用的 /detail 页，http://garfish.bytedance.net/example/appA#/detail特
- 特点：
