去哪儿网前端架构师司徒正美：如何挑选适合的前端框架？
发表于 16:19|
来源去哪网|
作者司徒正美
摘要：前端框架不断推新，众多IT企业都面临着“如何选择框架”，“是否需要再造轮子”的抉择。去哪儿网前端架构师司徒正美分析了各主流行框架优劣点、适用场景，并针对不同规模的公司、项目给出了相应的前端技术选择方案。
最近几年，前端技术迅猛发展，差不多每年都会冒出一款主流的框架。&每次新开业务线或启动新项目时，首先第一件事就是纠结：使用什么框架，重造什么轮子？我很高兴应CSDN的邀请谈我的看法。RequireJS，前端技术发展分水岭在五六年前，移动端还没有兴起，我们没有什么选择，就是jQuery。有人会说，jQuery只是类库，不是框架；但那时前端业务还没有像今天这么繁重，原本是后端干的事，全部挪到前端来，因为光是jQuery就可以包打天下。jQuery不够用，还有成千上万的jQuery的插件呢。于是问题就是这样一一衍生出来了，一个页面太多jQuery插件了，请求数太多了，于是我们得打包。打包需要我们对插件有规划。于是这一需求在社区上逐渐形成了某些规则，其中最出名的是AMD规范，体现上RequireJS这个加载库上。RequireJS是前端技术发展上的一个分水岭。JavaScript在ES6之前一直没有自己的加载机制，RequireJS的出现意味着前端可以向更大规模发展。以后我说的技术选型，一个非常重要的甄选点， 即是否存在加载器机制或符合某个模块规范。选择前端框架应综合考虑框架本身与团队情况回到原来的话题，选择框架要从两面看，一是看该框架的本领，二是看你们团队的能耐。从框架的角度来看，&它的功能丰富不丰富、社区活跃度如何、国内社区活跃度如何（有的在国外流行，但国内只有初创公司或一些大公司的边缘项目在试水）、文档齐全与否、是否及时更新、测试覆盖率如何、上手难易度如何，都是我们考量点。不过能进我们视野内的外国框架，基本是身经百战，在造轮子兴盛的世界闯出来的领头羊。jQuery、Angular、KnockOut、Emberjs、Polymer、React、Backbone、Zepto，我们基本是围绕在这几个上面转了。当然还有更大型的东西，如EXT、&YUI、Dojo、EasyUI、Bootstrap，这是UI库层面的。下面是2012年外国对当时流行12个JavasScript&MVC框架的纯技术评估：显然，我们第一步就是圈定时下最流行的框架与库作为评估对象，然后再根据自家公司的情况进行筛选。贵公司是建站公司，还是有自己产品的公司呢？如果是建站公司，页面不会复杂到哪里去，基本上jQuery+Bootstrap搞定，不要想得太多，就是它们。如果有自己产品，&要维护一大堆客户数据，要与客户打交道，不难想象存在非常复杂的CRM系统，按照中国人的特性，这东西只会越来越复杂，这就要慎重考虑了。这往往是持续十年的维护升级，我们需要看一下某框架是否有你们的产品那么长寿，这框架的升级更新是否频繁平缓。大工程应尽量避开谷歌产品如果你的项目是一个跨度三年以上的大工程，用《人月神话》的术语来说，90%就是个焦油坑。我们需要使用更稳健成熟的技术方案，我们需要重点避开谷歌的产品，它的许多产品都是玩票性质，GWT、Closure、Darty就是前车之鉴。基于许多新技术构建，其中Object.observe()、&Custom&Elements、HTML&Imports、Shadow&DOM、Model-Driven&Views还远远没被标准化，&许多还是独家的，变数太大，因此才出现下图所示的。&Angular不是我黑它，这东西也喜欢断崖式升级，它在1.08时兼容IE6-8，1.2时需要打补丁兼容旧式IE，1.3摒弃了对旧式IE的兼容，直接在源码中删除了所有兼容代码，因此所有补丁方案都无力回天，并且不支持全局Ctrl函数，许多模块需要独立引用，1.4不向下支持动画模块，2.0由at改成ts构建，由于使用Object.observe()，因此不支持IE6-11，Chrome30……后台系统可考虑EXT、EasyUI，avalon等国内优秀框架也值得考虑如果你们的产品是后台系统，那么就有两个选择，使用EXT、EasyUI这些重大的UI库方案，其中EXT具有严重的排它性，它很难与其他前端解决方案并用。什么模块组织、打包、数据可视化，它都已经能全部帮你搞定。它文档齐备漂亮，入门难度中等，但它要求你的团队非常稳定，现在招一个专职EXT的前端是很难的。EasyUI是国内比较大牌的UI框架，虽然闭源，不过想扩展它不是难事。此外，国内的淘宝Kissy，&网易Nej也不错。还有更轻量的方案：MVVM。MVVM最擅长做这些重交互的产品。举例说，为了对应复杂交互的Gird，jQuery社区开发出各种庞大巨物DataGrid、jqGrid、FlexiGrid，还不如MVVM几个循环绑定来得干脆利落，扩展性又好。目前，KnockOut、Emberjs、Angular与我写的avalon就是这一类框架。Angular虽然有点坑，但如果你是从1.3用起，并且不鸟IE，它还是一个不错的选择，其活跃的社区为它带来无限的可能。KnockOut在.Net人群中非常流行，微软出品，前端MVVM框架的鼻祖，不过它需要对后端数据进行过多的加工，因为它本身是不支持对套嵌对象的绑定。Emberjs没有一个好干爹，但有一个好亲爹，作者Yehuda&Katz是jQuery，&Rails、SprouteCore、Merb、Handlebars这些著名框架的核心成员，虎父无犬子，Emberjs现在还是国外的第二大MVVM框架。avalon是比较适合国情的MVVM，有它专门兼容IE6的版本，易上手，性能高，视频教程多，出了问题可以抓得着作者，是它的几大卖点。重SEO产品，可考虑jQuery+Bootstrap+RequireJS组合如果你们的产品是商场这样重演示类的产品，就对SEO有要求，MVVM就不适合了。目前也就Angular与avalon在搞后端渲染机制，但还不上了台面。这时jQuery+Bootstrap+RequireJS就非常好用。RequireJS的作用不单单是提供了一个按需加载机制，它还能让我们组织起更为庞大的代码。如果不用RequireJS，国内另一个选择是SeaJS，它的规范是CMD。此外还有CommonJS规范，但这无法直接运行于前端，需要借助fekit、FIS、Webpack这样的构建工具进行合并了。不管怎么说，你这时选用的框架必须存在AMD、CMD或CommonJS任一种加载规范，这方便你以后的横向扩展。至于插件，目前小插件们都趋向用，它可以让AMD、CMD、CommonJS任一种加载器加载。移动端技术较混乱，需多管齐下如果你们的产品是移动端，基本上是SPA架构了，因为这会减少等待，整页刷新与请求数。目前该领域非常混乱，不同于PC端，要兼容的浏览器多出N倍，并且为了性能，浏览器商乱砍功能或改变一些浏览器特性的行为，往往引发一些奇怪的BUG，目前社区正在整理这些。但目前没有一个框架能够摆平所有问题，都需要多管齐下。我的见解是：RequireJS（按需加载，移动端上可以不打包，善用304缓存，腾讯搞出一个更牛叉的增量更新加载器MT，也可以试试）+Backbone（组织代码与路由管理）+Zepto（轻量DOM操作）&+&fastclick.js（点击穿透与延迟处理）+Hammer.js（各种触屏事件）+iScroll5.js（滚动条处理）+Animate.css（CSS3动画）+Enquire.js（处理响应式布局）。可见移动端每个部件都烂到蕊了，每个部件都需要专门的工具进行修复。移动端是非常注重体验的，每一个小角落都存在着各种动画，但浏览器或自带的WebView都很差劲，于是Native与Hybird的话题才一直这么火。有的人说，既然DOM最吃性能，那么就干脆用Canvas来代替吧（请见：&与&）。Facebook也推出了自己类似的方案React&Native，自己实现了一套GUI，不过编写语言是JavaScript。它是使用自己原来的超高性能轮子React实现的。这或者是一条道路。但优缺点也明显，正如Angular浓浓的Java风，React是在逻辑中插入大段标签语言（JSX）。同时React的排它性也非常强，很难与其它库搭配使用。同时，我们可以看到，出自jQuery名门的jQuery&Mobile并没有入围，那个性能太糟了，连Sencha&Touch也不及。上面说的只是核心库，&还没有搬出UI库呢。号称Mobile&First的UI库不在少数，由于无视IE，可以大胆使用CSS3。目前比较出彩的有Foundation、Semantic，Refill、Ratchet。如果只是想运行在平板上，性能问题就不会那么拮据了，我们还可以试试inoic、Sencha&Touch，&Kendo&UI&Mobile……没有最好，选择最适合自己的基本上，针对每个平台，我都列出一些主流框架，但不意味着你们都能驾驭得住。小马过马，老牛没过膝，松鼠淹个半死，就是这么回事。创业公司喜欢新框架，这与他们拿得起高薪招一两个前端牛人所致，基本上所有页面就是他们干的，因此用Angular或Ember都没区别。小公司则小心，人员流失大，jQuery+RequireJS是万金油。大公司则基本上有自己的技术沉淀，换言之，应该有自己的前端框架，除非那东西很陈旧，不建议再造轮子。对大公司的建议是搞自己的技术委员会，根据自己的人员配置来挑选的框架。有句话说得好，不求最好，但求最合适。有些框架就属于牛逼人手里牛逼闪闪，二逼人手里一团乱麻。对于某些成长特别快的中等公司来说，这点最需防范，牛人是有的，但作战的主体70%都是刚培训出来的实习生，难上手，中文文档不全的框架就必须过滤掉。我也不排除造轮子的可能性，毕竟有些公司就是人才济济，能推出一些靠谱的开源产品来造福社区。但无论我们选择什么框架或决定自己动手造轮子，都勿忘初心，技术必须让我们工作生活更为轻松愉快——我们只选择我们能驾驭住的框架，我们不能保证它在一年后是否会过时落后，但至少不会变成绊脚石。套用亚当·斯密的话（税收是一种必要的恶）来说，框架是一种必要的恶，它是强约束的，因此必须慎重选择。作者简介：钟钦成，网名司徒正美，是中国最早研究加载器、选择器与MVVM的人之一，著有《Javacript框架设计》一书。自栩为穿梭于二次元与二进制间的魔法师，致力发掘各种黑魔法，提升一般前端工程师的生产效率。欢迎加入CSDN前端交流群：，进行前端技术交流。&
推荐阅读相关主题：
CSDN官方微信
扫描二维码,向CSDN吐槽
微信号：CSDNnews
相关热门文章mengyancui 写道你妹的，连css都有框架&& 只要你拉BB，就有人送纸&&
bing_zz 写道rainsz 写道来自Twitter的Bootstrap居然没有提到。你的惊讶让我很惊讶。框架有多少你数得过来嘛，你喜欢的别人都喜欢嘛。除了 less 其他全没见过Bootstrap居然没有提到 githube上那么火...........
rainsz 写道来自Twitter的Bootstrap居然没有提到。
你的惊讶让我很惊讶。
框架有多少你数得过来嘛，你喜欢的别人都喜欢嘛。
来自Twitter的Bootstrap居然没有提到。
你妹的，连css都有框架&&之前专门为IE6、7开发的网站如何迁移到IE10及可能遇到的问题和相应解决方案汇总 – 海之澜 | 查问题
汇聚最新编程技术，编程问题一网打尽
& 之前专门为IE6、7开发的网站如何迁移到IE10及可能遇到的问题和相应解决方案汇总 – 海之澜
之前专门为IE6、7开发的网站如何迁移到IE10及可能遇到的问题和相应解决方案汇总 – 海之澜
[作者： 分类： ]
　　由于周末，早晨起来的比较晚，打开博客园转转，看到这样的一篇博文，内容大致是说，服务器由于升级导致的用Asp.NET的UpdatePanel写的下拉联动失效了，这让我联想到了前段时间看到的一份资料，关于IE10和Asp.NET的故事。
博客园中看到的博文：
博主最后总结 出的结论如下：
asp.net4.0出生得比IE10早，所以asp.net4.0以前版本不认识IE10 的 User-Agent 标头，导致的后果就是ASP.NET 特定功能失效。
导致这个问题的原因大致就是这样的，这个是微软官方给出的bug及升级补丁（下文中也有详细介绍关于IE10的问题）。
http://en-us/library/ie/hh869299(v=vs.85).aspx
下面我就目前了解的微软新版本IE10或者IE11与IE10一下浏览器的区别和可能遇到的问题整理了下，贴出来供大家参考，难免有疏漏或者错误的地方，欢迎留言帮忙指正，共同进步。
第1章 网站迁移简介
1.1 网站开发过去和现在
　　在过去专门针对IE6开发的系统中可能存在一些现在主流高版本浏览器不兼容的代码或样式，过去和现在Web开发的现状如下图。
　　IE版本从6升级到10过程中，由于IE10执行较新的Web标准，在IE9之前正确执行的代码或渲染的样式，在IE10中可能会失效，具体会在后面总结到。
1.2 解决兼容性方法
　　解决兼容性方法主要有两个：修复、备选方案。
1.2.1 修复
可以通过设置网页的兼容视图/ 或者调整GPO完成修复。
了解下IE新版本带来的变化：
每次使用一个新版本的浏览器，网站总是出错，导致此类问题的原因一般如下：
用条件注释来判断浏览器版本，如：
&!-[if gte IE 5.5] &p&you are using IE5 or higher&/p& &![endif]-&
用用户代理串User Agent String判断浏览器类型，如：
(1)&&&&&& 在IE10中不再支持条件注释语句，所以旧版本的web在IE10中可能显示不正确。
(2)&&&&&& 在IE10的兼容性视图中，User-Agent会变为IE7，如果代码是通过这样方式判断，则不能处理后期新出现的用户较多的浏览器的支持。
(3)&&&&&& 在旧版的服务器中，存在一个BUG，此bug将会导致服务器不会接收来自IE10的请求，需要升级服务器补丁，详细请见MSDN：
如何缓解兼容性问题：
　　普通用户，使用兼容试图按钮
　　开发人员：使用X-UA-Compatible，限制浏览器显示模式&
　　管理人员：列出兼容性试图，提交微软，强制限制网页显示模式
　　处理专为IE6开发的网站应用显示问题的方法：
关于Quirks模式介绍：
　　IE浏览器兼容性视图显示的一种，如图。
　　但在IE10下，Quirks模式既支持最新的html标准，也支持IE老版本的标准；IE 5 Quirks模式只支持IE老版本的标准。
　　在IE9下，Quirks模式只支持IE老版本的标准。
1.2.2 备选方案
　　1.加入Browsium ION加载项，一个轻量级的可使用在IE9/10上的浏览器插件，可以显示专为IE6/7所设计的网页，但需要授权费用，详细见网址：
　　2. Microsoft Enterprise Desktop Virtualization (MED-V) ，让IE6运行在本地的一个虚拟化的XP实例中。
3. Terminal Services(终端服务) 使用Windows 2003的Terminal Service把IE6发布为Remote App。
4. 在Windows 8上面使用Hyper-V客户端 IE6可以运行在一个Hyper-V的虚拟机上。
第2章 兼容性测试工具介绍
2.1 Application Compatibility Toolkit
　　Application Compatibility Toolkit (ACT) 帮助您确定在部署之前，您的应用程序是否与新版本的 Windows 兼容，还有助于您确定操作系统新的如何影响将这些应用程序。
　　它可以：
　　实时查看基于 Web 的问题
　　IECTT 使您能够在对 Internet Explorer 7 和 Internet Explorer 8 测试网站和 Web 应用程序时随时找到并查看基于 Web 的问题。完成测试之后，可以在 IECTT 的 Live Data 屏幕中查看结果。
　　将 Web 问题上载到 ACT 数据库中
IECTT 使您能够将基于 Web 的问题上载到 ACT 数据库中（ACT 数据库会处理这些信息），并使您能够在应用程序兼容性管理器的 Analyze 屏幕上查看结果。
2.2 Compat Inspector
Compat Inspector 是一种基于 JavaScript 的测试工具，可在站点运行时分析站点。Compat Inspector 报告导致在标准模式中出现问题的交互模式。这使您能够迅速识别问题，而无需熟记大量文档，无需在站点的全部代码中进行搜索。但Compat Inspector 只能在IE9，10下的标准方式下运行。
使用方法访问：
集成在网页中，及在网页中加载一段js。
&script src=”/TestDrive/HTML5/CompatInspector/inspector.js”&&/script&
&&& 同时也可以集成到fiddler中。
使用时会在网页右侧显示结果，如图
　　点击右上角的简要报告，进入到报告细节
　　使用说明：
　　详细指出页面存在的兼容性问题
　　在Tests的tab中可以选择要测试项目是否测试。
　　在Messages下的详细列表中有debug选项，如图
　　可以直接开启浏览器的F12调试，自动进入有问题的断点。
2.3 Modern.IE
Modern.IE是由微软官方发布的一款在线测试软件，开发人员可通过这组工具来测试自己的网站在新一代的 IE9、IE10或旧版浏览器上的效果，modern.IE 的程序侦测精灵(code detection wizard)能够扫描并辨识出可能影响使用体验的常见错误。
请访问查看详情。
比如检测& modern.IE给出如下报告，说明了该网页存在的一些问题，并指出解决这些问题的方法。
第3章 常见的兼容性问题
3.1 文档模式
文档模式(&!DOCTYPE&)定义了IE浏览器如何来展示网页，&!DOCTYPE& 声明位于文档中的最前面的位置，处于 &html& 标签之前。此标签可告知浏览器文档使用哪种 HTML 或 XHTML 规范。
该标签可声明三种 DTD 类型，分别表示严格版本、过渡版本以及基于框架的 HTML 文档。
详细的标准及最终解析的标准见下图（Q:Quirks模式，S：标准模式）：
详情请点击：
　　如何制定页面的文档模式。
　　使用 meta 元素，以在网页中包含 X-UA-Compatible http-equiv 标头。
　　例如：
　　　　& &meta http-equiv=”x-ua-compatible” content=”IE=7″ &
　　　　& &meta http-equiv=”x-ua-compatible” content=”IE=EmulateIE7″ &
　　　　& &meta http-equiv=”x-ua-compatible” content=”IE=edge” &
　　　　& &meta http-equiv=”X-UA-Compatible” content=”IE=7,9,10″ &
　　关于IE=7和IE=EmulateIE7的区别：
　　如果是写IE=7,指一定要再ie7下运行
　　如果是IE=EmaluteIE7，这种写法会根据文档模式docment type判断加载模式，其次才依据代码限制的IE=EmaluteIE7执行。
3.2 用户代理串
　　当访问网站的时候，浏览器会发送一个User-Agent字符串给服务端，以表明浏览器类型、版本、操作系统类型等。Web服务器端可以根据这些信息返回不同的网页信息。
　　通常情况下，很多网页开发人员喜欢通过&User- Agent&头信息来判断用户使用的是何种浏览器(称为浏览器检测)，这种方式存在极大的兼容性隐患。
例如使用如下方式实现检测：
　　以下情况，该代码会失效：
（1）&&& 新的浏览器发布或浏览器更新，此时需要修改代码。
（2）&&& 推出的新设备中往往包含新版本的浏览器。
（3）&&& 许多浏览器支持修改用户代理 (User-Agent) 头信息的功能。
　　推荐做法–使用更能检测(Feature Detection)：
3.3 条件判断
　　在早期版本的IE浏览器中，可以使用条件判断语句来判断是否是IE浏览器，以及其版本号，例如：
&&!–[if IE 8]& &p&Welcome to Internet Explorer 8.&/p& &![endif]–&
　　IE10已经不再支持条件判断&使用条件判断就如同使用User-Agent判断浏览器类型一样，存在类似的弊端&正确的做法是采用Feature Detection
3.4 脚本错误
　　IE10采用最新的web标准，可能之前能运行在IE9之前的脚本在IE10下会报错，例如。
　　报错原因即为元素的Id名称大小写不一致。
　　又如，IE10下不再支持滤镜效果，许多基于脚本的滤镜效果会失效，报出错误，如图。
　　因此，为了尽量避免网站在IE9/10上发生兼容性问题，在开发一个新的Web应用或者对旧应用进行改版之前，开发人员务必先学习IE9和IE10的兼容手册：
3.5 样式错乱
　　有些网页在IE10下出现显示错乱，往往是因为没有按照web标准来定义样式所致，如web标准中定义text-align如下：
text-align 属性规定元素中的文本的水平对齐方式。
　　如果有如下的html样式定义，IE10就会出现表格不居中显示，而IE9之前是居中显示的：
　　&div style=&text-align:&&
&&&&&&&&&& &table&&tr&&td&我要在中间&/td&&/tr&&/table&
　　&/div&
&第4章 常见兼容性问题排错
4.1 常见问题
1.页面显示问题&显示位置错乱、颜色不对、排列不整齐、该显示的内容没有显示等
2.功能问题&点击按钮没有反应、动画内容不播放、业务功能无法完成等
3.脚本报错&弹出Javascript报错框
4.ActiveX错误& ActiveX控件无法安装、ActiveX控件不加载、 Flash不播放等
4.2 如何排错
　　1. 简化页面，尽量用最简单的页面来重现问题
　　2. 审查文档模式，尝试使用各个文档模式来显示页面
　　3. 对问题进行归类：显示问题、功能问题、脚本报错或是 ActiveX问题
　　4. 审查网页的源代码
　　5. 使用工具对网页进行排错
&第5章 调试工具介绍
5.1 F12 Developer Tools
　　F12开发人员工具是一套内置于IE9/10的网页调试工具，可以调试以下问题：
&　　- HTML
&　　– CSS
　　- JS脚本错误和脚本性能（探查器tab）
　　- 网络传输
5.2 Fiddler
　　Fiddler是一个HTTP调试工具，适用于调试以下问题：
(1)&& 网络上的问题
(2)&& HTTP Response 错误
(3)&& 缓存
(4)&& 代理服务器问题
(5)&& 服务端的问题
(6)&& 服务端发回错误的Response
可适用于这些场合:
(1)&& 服务端通过User-Agent判断浏览器类型
(2)&& Ajax请求的问题
(3)&& 响应时间问题
(4)&& HTTP安全(cookies丢失, 非法SSL)
(5)&& 可以查看HTTPS的包
(6)&& 可以把结果保存以便日后重播
操作界面如图：
　　详情可以查看详细介绍：
5.3 Network Monitor
　　下载地址：
&　　Network Monitor可以用来监控网络活动
(1)&& 实时抓取并显示结果
(2)&& 可以同时抓取多块网卡上的网络活动
(3)&& 可以保存日志以备日后打开分析
　　适用场合:
(1)&& 网络底层的连接问题(比如代理服务器问题)
(2)&& Web Proxy Auto Discovery Protocol (WPAD)
(3)&& 审查每一个TCP包的具体内容
　　本人表达能力有限，只是整理了旧版网站迁移到IE10及更高版本浏览器可能出现的问题和相关解决方案，欢迎大家指正，谢谢！
本文链接：，转载请注明。怎样可以很好地保证网页的浏览器兼容性？
最近发现越来越多的网站在ie和火狐以及chrome下面的显示各有差异，比如知乎在不同浏览器下的显示及功能就不一样，怎样可以很好地保证网页的浏览器兼容性？
按投票排序
其实我特别不愿意看到这样的问题。保证浏览器的兼容性是一个落后的话题，先看一组豆瓣数据，各浏览器的占有率：ie6 - 30.23%ie7 - 4.8%ie8 - 30.6%ie9
1%chrome - 13.99%firefox - 7.17%safari ~ 5%其他 ~ 8%我们认为chrome + firefox + safari + ie9是高端浏览器，ie8勉强算准高端吧。这样这部分占有率约57%(如果加上其他webkit内核的浏览器会更高一些) 已经大于ie6 + ie7。高端和低端浏览器的差距可以用html5test量化一下：Google Chromium 11.0.690的分数是293，而Microsoft Internet Explorer 6.0的分数17也许有各种fallback方案可以保证完全兼容性各个浏览器，但依然不能保证低端浏览器的使用体验，顶多是看起来各个浏览器都一样了。因此，现在的设计和开发的策略是浏览器分级支持。优先为高端浏览器设计，同时考虑低端浏览器的退化方案。甚至有些复杂的应用可以拒绝ie6，提示用户使用高端浏览器。豆瓣7月份将会发布一款对ie6说no的产品（国内第一个拒绝支持ie6的产品吧）因此不要再考虑向后兼容，应该考虑向后退化，更多考虑向前兼容。
跨浏览器开发应该使用的一些经验1)一些关于跨浏览器/设备的工具1. modernizr.js 特性检测器，有就使用原生，没有就加载polyfill2. polyfill/shim 向后兼容的浏览器的js补丁，一般和modernizr一起用3. jshint.js js语法检测器4. Boilerplate 开发的最佳实践的初始模板5. 阅读第三方库关于最低版本支持6. 使用js单元测试，测试目标浏览器7. Responsive Design （针对屏幕大小）8. normalize.css 统一浏览器基本元素的风格2) 一个策略：另外，我一直说的一个策略：把浏览器分两类，一类是历史遗留浏览器，一类是现代浏览器，然后根据这个分类开发两个版本的网站，然后自己定义那些浏览器是历史遗留版本，凡是历史遗留版本浏览器，统统使用历史遗留版界面，然后通过通告栏（信息通知系统）明确告知本版本有些功能不能使用，尽快转移到现代浏览器上。然后现代浏览器的网站版本，功能全开，提供最好的用户体验。3)最后手段：最后方案，就是直接使用jReject.js这类插件，弹出有全黑蒙板的对话框，告诉用户这个网站什么版本的IE/浏览器不能用，请使用至少什么版本的IE，firefox和chrome.(这个是最后手段，以上方案都失效的情况下使用。)4)一个提醒：跨浏览器兼容问题，过去有，现在有，以后会更麻烦，所以这个问题在你的项目开始前，就必须确定下来最低支持的版本是什么，然后设计一个对应兼容方案。不要等开发完毕了，才告知要必须兼容个ie6啥的，那你的项目就有得好改了。5)面向未来：2015年es6就要正式完成了，等es6出来后，如何把es6的javascript向后兼容呢？这里我有个概念，还没实验过：1.使用es6编译器把代码导出成es5代码2.使用modernzr检查浏览器是否支持es6，支持用es6代码；不支持，用编译好的es5代码并且加载es6shim。3.使用grunt把es6编译过程完全自动化以上这个方案，应该可以使用es6代码去兼容所有的浏览器了。
你说的差异是由于不同企业的观念导致。现在越来越流行“优雅退化”，特别是IT行业的网站。优雅退化差别与传统观念在于不保证所有浏览器的表现均一致，在更符合w3c标准的浏览器中表现良好，在旧浏览器中表现没那么好但不影响正常操作（例如知乎按钮的圆角效果）。保证浏览器的兼容性更多需要靠经验，经验让你对CSS的根源有更深的认识，所以你实现兼容性不是靠hack，而是靠各种属性原本的实现再进行互补。对CSS从“how”到"why"，估计就OK了。总之这事做多了就可以了。（js那边通常用框架开发，框架本身已经隐藏了浏览器兼容）
psd转html时，需按照W3C标准流程和规范制作，用基于标准的浏览器测试，推荐firefox,chrome这样基本上，firefox,chrome,safari,opera,IE9都能表现一致然后再针对IE8、7、6进行修改
强悍的框架，还有耐心的调试 少用hack
这个问题对于Web开发者来说真是头疼的问题，我从事Web开发也有两年时间，期间遇到过许许多多类似的问题，每次都被搞得很累，后来画了大半年时间专门研究Web前端技巧，最后我总结了一些方案出来：1.在开发Web APP的时候，开发机上面最好把主流浏览器都装上，比如说：Chrome、FF、safari、IE、IE Tester... 在大多数情况下，FF和Chrome差别不是很大。2.开发过程中要注意，每做好一个样式，都要跑一遍所有要兼容的浏览器，这样虽然开发过程时间会比较长，可是会比你开发完成后再来改效率高得多，我曾经就碰到过一个产品，开发完成后由于兼容性问题导致其发展面很窄，最后不得不重新开发。3.如果真的碰到样式不兼容的情况，那么只能针对不同的浏览器做相应的调整。4.一些新的特效可能在一些版本落后的浏览器里不兼容，这个时候我们的原则就是：不求效果绚丽，只求工整规范 o(∩_∩)o 5.多积累，多看看符合W3C标准规范的CSS手册和JS手册，注意积累，或者用一些开源框架，那样兼容性可以省下不少时间以上都是个人见解，可能有的地方说得不对，还请知乎的牛人们指正!
上面的大家都说了，要渐进增强，所以要人为的制造差异，这样才能促进用户升级浏览器然后做的时候，先要CSS REST，然后在你遇到问题最多的浏览器上做首次开发（这样在首次开发时就能解决掉最多的问题，比如IE……），然后再针对不用的浏览器写HACK了（这时就要把渐进增强引入了……）
不得不考虑网站本身的用户群。像百姓网这类的分类信息网站，IE6在50%以上，反而firefox在1%都不到，设计时如果不考虑IE6，问题会非常的大。我想，保证产品的可用是底线，浏览器的兼容性方面可以通过避开一些不统一的写法等尽量保证效果统一，一些浏览器的特性，在现阶段只能说是锦上添花的东西。
构思整体和局部的实现时候就要考虑很多东西了，比如兼容性，制作成本，维护成本等等，而这恰恰是大量实际经验中不断学习而来的能力。吃过的苦头，争取下次不要再吃，没碰到过问题，没棘手过是不会有提高的。多多实践吧。
尽量使用标准的网页布局方式，也就是符合W3C的布局，再加上css的使用也符合W3C的使用，这样完成一个页面下来，其实很少有地方需要你针对特定的浏览器进行兼容性修正。做过比较多的页面，又复杂也有简单的，大多时候，一个页面下来，其实只有两三个地方需要进行大的兼容性调整。
规范的，良好书写习惯的代码写出的东西基本不需要太多兼容性的问题，一些兼容性的问题基本上都是可以避免的
全Flash，确保浏览器兼容。请权且把这个当作玩笑～真实的情况是，你可以通过一些成熟的手段去兼容90%的浏览器体验，尽管显示上略有差别，但至少不会走样。剩下的那10%就放弃吧，或者等待他们学会使用更好的浏览器。
在保证产品可用性的情况下,作些渐进增强,不必去追求表现层的一致性
我们都是采用预先监测浏览器的种类及版本，然后选择加载不同样式的不同的CSS文件，这样就能保证该网页在不同浏览器下的显示问题。