开始阅读本文之前，请务必做好心理准备。因为我写的90%都是抱怨，只有最后10%左右是关于CSS技巧的最佳实践。提前给你打好疫苗。前端工程师在职业发展中可能会遇到以下困境：到了某个阶段，觉得工作（自己做的）不难，为团队创造的价值越来越低。每个人都可以做他们做的事。请同意。举起你的手。如果你这样做，（恭喜）你是大多数人。老实说，CSS真的很简单。另外我可以保证，即使是白痴也能写出下面的代码：p{color:red;}所以你在抱怨什么？堆纯CSS代码，无需任何技巧。而在不考虑其他CSS的情况下，给单个元素添加全局样式当然是非常简单的。那么CSS的难点在哪里呢？后端开发工程师：“虽然我完成了新功能的开发，但是我把前端搞砸了，不过你放心，我已经修复了大部分，所以你的前端只需要微调一下详细信息，时间不应超过30分钟”所以我打开HTML文件，（令我惊讶的是）发现到处都是弃用的HTML标签，没有考虑响应式设计。深吸一口气，（给自己提示），他们一定有写的稍微好一点的CSS，但是打开CSS文件后，发现（也）到处都是固定定位，清除左浮动，右浮动，!important之类的代码，所以我慢慢地把鼠标绕在脖子上。（Don'tstopme,letmedie）（安慰自己），也许他们写的代码不会一直那么烂，但是（现实中）我几乎没见过后端工程师写出能用的前端代码，还好吧，写前端代码不是后端工程师的职责，但是请不要随便写一堆前端代码，n指望前端工程师给你擦屁股。那么好的CSS是什么样子的呢？（项目的）组织结构。尤其是当你做过大型项目的时候，你会发现项目的组织架构真的很重要。举个正例——StevenBradley写的[](https://link.juejin.im/?target...很好维护代码的目录结构，这篇文章是为SCSS项目写的，但是也适用于普通的CSS项目，重点是如何将CSS文件模块化成可维护的文件规范。这大概是我每天遇到的最大问题了。不幸的是，大多数工程师对[](https://link.juejin.im/?target...CSS规范一知半解，正因为如此，糟糕的CSS代码（如!important）才会变得糟糕。那么如何避免呢，这里有很多值得参考的命名约定，旨在减少硬编码（非常依赖文档结构）的CSS选择器。假设你对此不感兴趣，我还是想建议你如下：不必要，避免超过3层的CSS类/元素选择器。命名约定。恕我直言，命名约定是任何大型CSS项目的标准。没有命名约定，CSS变得困难维护不可靠。命名约定允许我们方便的复用项目中的CSS，必要时还可以帮助我们剔除项目中多余的CSS。这里仅举几个比较流行的命名约定，如：[](https://link.juejin.im/?target...BEM,[](https://link.juejin.im/?target...OOCSS,[](https://link.juejin.im/?target...SMACSS和我自己的[](https://link.juejin.im/?target...hiccup.test。此时其他大部分工程师可能还没有发现做后端工程师有多酷.因为后端工程师的开发工作只需要让一个环境（网站所在的服务器）正常即可。作为前端工程师你知道最痛苦的事情是什么吗？5个以上的浏览器，上千个ofmobileEquipment...好的前端测试其实是一件苦差事，需要很长时间。我见过很多项目因为没有考虑到前端测试而延迟，而且往往前端测试的时间比普通人预期的要长。所以如何扭转这种对CSS的幼稚看法？在以后的工作中，后端工程师不能再侥幸了。作为前端工程师，我们不会随便丢一堆没有响应的CSS代码给后端工程师，然后放手不管。那么为什么他们可以写无用的蹩脚代码并让我们修复他们的CSS代码？我不是说是让后端工程师写好CSS代码，但是我们应该告诉后端工程师，如果写CSS很难，就不要写。不要让其他工程师觉得前端很简单，其实前端并不简单。
