web前端面试题附答案024-线上样式出问题了，怎么快速解决？

在很长一段时间里，我么都遵循着本地开发，测试，上准生产，上线的线条，然后如果线上出问题了，再开始追责，测试同学和开发同学要责任共担，但如果是2个团队，最终还是要区分每个团队要扣掉多少分。

        但大的部门是由一个个小团队组织起来的，扣分其实都不愿意，所以几分钟以内可以解决，不造成重大损失，可以放过去，而且能够快速解决的这个人大家也会认为是那个团队必不可少人。就算问题是他搞出来的，至少他熟悉代码，熟悉流程，可以在最短的时间内解决问题，走个小测试，然后再上线。要知道，很多团队，上线也是个麻烦事，部署，编译，别说5分钟，一激动，半个小时都搞不好。那么大家一般都是怎么搞的呢？

1、老规矩

        什么是老规矩呢，就是出了问题，开始排查，拿到必现的步骤，找到那块CSS样式，发现是哪里不对了，是不是打包时候错了，还是就是开发流程缺失，还是就是开发的时候疏忽了，测试同学也没测到位。

        复现了以后呢，就开始改，觉得没问题了，赶紧测一测，开始走上线的那个流程。文件该覆盖的覆盖，版本号该升级的升级

2、新思路

        我的新思路就是css样式的可覆盖性，优先级高的css样式可以覆盖掉优先级低的css样式。

        首先我们需要一个配置平台，平台用来存放我们要写的优先级较高的CSS样式，这些样式平时是不需要的，而一旦发现线上有样式问题的时候，我们就开始在这个平台写样式较高的，或者缺失的那部分样式。

        既然有了高级样式，也有了平台，那么这就需要这个平台提供一个接口，供我们的HTLM落地页去调用这个接口。

        接口返回高级样式后，以模板语言的形式，填充到HTML的style标签内，填充后即可起到高级覆盖低级的作用。画个图吧

        

        更直白的描述就是，一旦发现有问题了，找到哪里样式错误了，比如color:red；不应该是红色，那么我们在配置平台编写color:blue !important;的样式，然后落地页发送请求，把color: blue !important;的样式请求回来，以覆盖错误样式的思路。 

3、2种方式对比

        对于第二种思路虽然成熟，但链条过多，而且HTML落地页很难知道什么时候线上出问题了，我们需要他去请求高级的样式。所以就需要添加定时任务，一直去请求，这就造成了配置平台的负担。而且还需要对应添加一个配置平台，这平台就需要开发，需要部署机器等问题。而且一旦有新人入职，还需要学习更多的东西，造成一定困扰。

        但第一种思路虽然费事，就很简单，无需添加任何东西，就是改，就是上，干就完了。