为什么开发做不出一致的界面
前端开发做的界面和设计稿不一致，90%以上的情况并不是因为代码实现不了而做的妥协，绝大多数情况都是想做做得出来，但是没有投入足够的精力和时间。所以，这里就要具体问题具体分析，为什么开发没有投入应有的精力和时间。
问题 1：前端的工作重心
在前端工作中，正常包含三个层，架构层、样式层、行为层。结构层就是以 HTML 组织起来的页面框架，样式层是以 CSS 为主的界面样式设置和美化，行为层则是以 JavaScript 脚本为基础的动态指令执行和数据处理。
其中，HTML 即服务样式也满足行为层的实现，所以前端的工作核心可以简化成样式层（HTML+CSS）和逻辑层（HTML+JavaScript）两个部分。
如果没有前端的基础可以不用纠结它们具体的内容和作用，但需要知道的一点是，前端工程师的工作，并不仅仅是把界面的样式给写出来，而是要兼顾很多逻辑问题的处理，数据的收发，以及和后端的联调（前后端代码能接通并运行）等。
对于所有前端工程师而言，逻辑层的价值和权重远远高于样式层。因为样式仅仅涉及页面好看和不好看，最多影响了用户的体验，但行为层的实现直接决定了产品的功能能不能用。产品先能用再谈好用，是基本常识，一切业务需求的满足都以功能实现为先决条件，所以前端的首要目标必然是考虑怎么实现逻辑层的内容。
所以前端工作的顺序通常是最低限度实现样式层的内容（需要用于操作和显示），然后投入逻辑层的工作中，后面有空再优化样式的内容。
但很显然，项目预留的时间永远都是不够的，往往满足逻辑层的内容就疲于奔命了，哪有空管设计长什么样。产品可用性没有实现，是要实打实要被问责的，KPI 会受到影响，而界面做的和设计稿不同，又不是什么大事，自然后面再说。
这就是所有前端界面还原度差的根源，有非常客观的原因。但这并不代表逻辑层的内容重要样式层就完全可以随便乱做或放弃治疗，因为前面样式做的太随意往往会导致后续的修复和调整要投入大量的精力。
所以我们必须找到合理的解决方案，平衡两者所要投入的时间，与其浪费时间在后续的修复，不如通过提升样式层的实现效率来提高交付的质量。
具体的方法我们会在后面解释。
问题 2：前端开源框架的应用
前端开源框架在今天的项目中已经完全普及了，很少有独立开发完成所有前端代码的项目。虽然前端框架可以极大的提高逻辑层的实现效率，但并不代表它在样式层面能提供一样的效果。
如果有下载和引用官方组件库文件并用它们做设计的经历，应该都知道这些文件用起来非常的麻烦，里面的组件、自动布局、响应式相互套娃，做个小改动就要调整一大堆文件和样式，往往有修改它的功夫不如重新做个新的出来。
对于前端来说同理，开源框架虽然提供了丰富的默认样式，但同样也在样式中应用了各种“套娃”，改起来远远比设计困难。
这就导致，如果前端开发使用了一款前端框架，那么设计稿中使用的组件是这套框架中带的，那就直接调用这个样式，只要功能实现出来，样式上能不改那就尽量不改。包括图表也是，图表也基本使用第三方的框架，所以实现出来和设计稿最多就是颜色接近，其它哪里都不像，比如下面的真实案例。
只有组件库中不包含的内容，才另外写新的。但这又导致，新写的东西会偏向设计稿（虽然实现得也不到位），但是实现的效果又和原来的开源框架效果相差甚远，看起来非常的违和。
所以，这就是整个项目团队都没想清楚使用开源框架后怎么落实界面，以及匹配对应的工作流程，从而产生很多不必要的损失和内耗。
问题 3：细节部分的实现繁琐
虽然用开源框架改起来很困难，但不代表把开源框架拿掉实现样式也很容易。前端工程师还原设计稿，约等于用代码把设计稿 “临摹”一遍。即使是设计师自己临摹一遍网上的飞机稿，也会发现临摹完的结果差别很大，而代码的临摹远远比用设计软件复杂，就更不是那么容易实现的了。
很多同学会有疑问，不是现在的设计软件都支持标注中包含前端样式代码了，直接复制就行，为什么还会出错？
这就是一直建议设计师也要学习 HTML+CSS 代码的原因，用前端代码布局实现样式的过程和设计软件操作有很大差异，上下层级和间距的控制逻辑是不等同于设计稿。想要和设计稿的参数完全一致，就一定要脱离设计标注，手动对特定的标签做参数的微调。
这个问题不在这里做太详细的讲解，只要你们根据自己的设计稿去写一个静态页面，就会理解为什么你每个参数好像都跟着原设计的标注做，但最后做出来的样式就是不一致。
要解决这个问题不仅仅是指望前端工程师用超乎寻常的责任心和毅力去完成，而是需要设计师本身理解这个转化过程的阻力，并能在这个基础上发挥主观能动性来提供有效的设计思路和工作流。
换句话说，经验丰富的设计师不是使用魔法让自己的设计稿完美落地，而是在一开始就直面开发阻力来规范自己的设计方式和文件格式，让它们能被最简单的转化成代码样式并落地。我称这个过程叫——面向开发设计。
当然，具体的方法我们也会在后面的分享中说明。
问题 4：样式的复用和冲突
还有个非常常见的问题，就是样式复用导致的冲突。在设计软件中，我们可以定义一个字体、图形的标准样式，并运用到不同的图层中去，只要我们修改该样式，那么所有引用这个样式的图层都会同步更改。
在前端实现中同理，样式层中 CSS 样式表就是用来控制页面样式的中心，可以在不同页面，不同标签（约等于图层）中使用这个样式。
科学的前端管理必然是定义好一些通用的样式，然后在不同的页面和元素中复用，让效率和统一性最大化。但问题是，很多时候前期定义的样式不够完整，比如间距、字号、色彩、透明度等等。
当前端工程师完成了第一阶段的样式表制定，那么在页面开发过程中，出现了很多和前期样式不匹配的新细节，最好的做法是停下来做统计和梳理，更新一波样式再做下去。但这个过程显然很麻烦，所以前端工程师就会挑个顺手的样式（Class 类）替代，即使它实现的效果和设计稿并不一致。
这种操作导致的后果必然是和原设计页面差距越来越大，并且在后期修改中，因为被合并的样式细节太多，想要修改就得把错误的对象样式分离出来创建成新的，光是识别哪些标签需要分离出来做合并，就需要耗费大量的精力，这也是项目完成度越大，前端工程师越不想改文件的原因。
但又因为很多还原度的测试是留在项目结尾，在流程中直接固化了这种矛盾，同时又挤入了大量逻辑层的问题需要修复，就更导致前端开发不会愿意修复样式的错误，将这些问题保留到最终上线。
只是简单的丢一份设计规范的标注给前端等结尾验收最后的界面效果，是绝对不可能获得满意的结果的。
这就同样需要优化设计和开发的协作流程，样式的验收环节必须前置化，需要有独立的流程来消化样式定义中的问题，而不是留到已经快发版的测试阶段再急着解决。
所以设计师需要在满足前面所说的面向开发设计的思路外，还要结合前端工程师本身的工作顺序和习惯，创建一个便捷高效的敏捷型验收模式，来提升前期样式层开发的质量，减轻测试阶段的压力。
除此之外，还原度问题还包含切图格式、投影样式、动画效果等众多细节，我就不一一例举，这些问题都是在可以建立有效的设计和前端协作方式后可以被轻松解决的问题。
而设计师要做的，就是必须站在开发的角度，从不同层面来思考为什么他们不能实现和设计稿一致的效果！
