弊端概述

并不能真正的识别用户客户端。由于 CSS 级别的响应式普遍都是通过 @media 的媒介查询方式根据屏幕尺寸判断手机端还是PC端， 这种做法显然是不科学的，例如，将手机横屏 CSS 可能就认为该客户端为 PC，将PC浏览器窗口缩小，CSS 就认为该客户端是手机。 自然基于这种判断渲染出来的界面并不是真正客户需求的。 2.可能导致样式混乱。由于 CSS @media 存在一个临界点，如@media screen and (max-width:800px)， 如果整站代码存在临界点不一致的情况，当窗口尺寸缩小或放到大这一临界点(800px)附近时， 样式就可能出现混乱了。这是常有的事情，相比不做响应式，可能带给用户的麻烦比便利会更多。

代码冗余量大。从 CSS 级别来做的响应式网站代码冗余量是很大的，一方面需要用大量的 CSS 媒介查询代码处理不同尺寸的样式。 一方面 HTML 也会有大量的容易代码，一般而言响应式网站在 PC端效果会丰富一些，手机端就会简洁一些，在这种动态渲染的HTML，普遍存在 一部分 HTML 只有在 PC端才会显示，反之亦然，这就意味着势必有部分HTML在手机/PC是不会出现的。那么不会出现的元素何必要发送给用户呢？无疑是增加了 代码冗余量，消耗了网络带宽。对于访问量大，传输、渲染要求都很高的网站，这点缺点是不可容忍的。

维护成本高。由于一套HTML要同时考虑 PC端、手机端，每修改一个样式，需要在两种条件下进行测试，特别是对于手机端，还要考虑不同厂商不同手机尺寸的各种复杂情况。 修改了 PC端的样式，又有可能影响了手机的效果展示。总之，维护起来相当麻烦。

响应式网站最佳实践方法

不做CSS级别的响应式，而是分别针对手机端、PC端做了两套HTML。

以淘宝为例，桌面端浏览器窗口输入www.taobao.com，毫无疑问，跳转的就是www.taobao.com指向的网站首页，桌面端的。手机呢，可以发现，url重定向成了www.m.taobao.com，没错，这个网址指向的网站的首页是专门为移动端设计的。

怎么实现的呢？很简单， 服务器通过识别用户发送的http请求头 user-agent来识别用户访问的设备信息，根据该值判定设备为PC或移动客户端，并根据结果跳转到与之对应的网址。

通过识别请求头user-agent分流客户，一方面更准确的为客户提供与之对应的服务，节省了带宽资源，增加了网站的个性化，可维护性。另一方面，还对性能有所提升， 这种分流策略类似于 ngnix，还减轻了服务器压力。

响应式现状

响应式这种方式在国内很少有大型企业的复杂性的网站在移动端用这种方法去做，主要原因是工作大，维护性难，所以一般都是中小型的门户或者博客类站点会采用响应式的方法从web page到web app直接一步到位，因为这样反而可以节约成本，不用再专门为自己的网站做一个web app的版本。