偶然在微博看到在SegmentFault上的一个共享Header和Footer的问题，而正好我们也解决了这个问题。在这里，就分享一下我们的经验咯。
业务场景
我们的业务环境和58同城、搜房网这一类站点差不多。我们维护的站点主要有三个页面：
- 一个用于搜索的首页
- 一个搜索结果页
- 一个用于显示商品信息的详细页。
总体上和Google类似，有一个简洁的首页，一个搜索结果页，以及目标网站页。在旧有的系统中，这三个不同的页面都是同一个代码库中。
而对于我们的新系统来说，这些都是独立的项目。因为我们需要同Google一样可以快速打开首页，首页就变成了一个部分内容是动态的，但是大部分时间是静态网站。这一点可以参考我之前的另外一篇文章《编辑-发布-开发分离》，仅仅只在编辑更新内容的时候，才生成新的首页（静态页面）。在这时，由于能限制用户的访问速度，莫过于CDN了。
同时，我们还有几个不同的博客及十几个引流站点，这些都需要使用同样的Header和Footer。对应于我们的其他页面，我们使用React来构建，这意味着我们需要不同的模板。
并且当我们在设计新的系统的时候，我们有了一个更新网站UI的计划。这意味着我们在替换旧有的系统完成之前，我们需要更新所有网站的UI，WTF！
So，在这时我们设计了第一个Share Header和Footer的架构。
基于包与模板的共享
接着，由于Release时间的限制，我们并没有在一开始的时候实现基于脚本的共享方式。因此我们使用了内部的UI框架，同时这个UI框架将会在我们的所有站点上使用——我们可以使用同样的HTML和CSS。
因此在我们的新站点上，我们使用基于Bower与GitHub的Release方案——我们使用Grunt作为构建工具。每次在本地启动Server的时候，我们都会更新依赖。因此，在我们的站点上，我们只需要更新bower.json中的版本号即可。
而对于我们的旧有站点上，因为是一个遗留系统，没有这么先进的工具。并且从理论上来说，不应该会太多的时间和精力在上面，于是我们选择了手动复制的方案。
对于博客和其他站点，一部分使用手动复制，一部分使用iFrame加载。因此在Release新版本的时候，我们会上传新的Header和Footer到AWS S3上。
对于iFrame的站点来说，他们就实现了动态更新。对于其他站点来说，就需要手动更新。虽是如此，但是对于业务已经固定的网站来说，Header和Footer只会一年更新一两次。不过，如果发生收购和被收购时，会多更新一两次。
那么，对于那些使用的不是基于HTML，而是使用模板的站点怎么办？
脚本生成的共享方式
最明显的一个问题就是使用React的站点。因为大部分的模板引擎都是可以支持class=""，而React你只能用className=""。所以要么，我们将HTML写在基本的模板文件里，如base.html；要么我们将class替换成className。架构变换成如下所示的结构：
所以，在这时理想的方式就是通过某种类型的模板来生成对应的模板。即我们只需要有一个JSX的模板文件，然后替换其中的相应内容即可。
