本文主要总结了web前端常见的问题，通过具体的内容向大家展现，希望对大家web前端的学习有所帮助。

在网上也看了很多bug汇总，都写的比较细，那么我们是否可以宏观的思考，为什么会造成错误。

简单的归纳了几个点：

代码逻辑错误

产品需求错误

场景缺失错误

异步错误

概念理解错误

接下来展开讨论一下。

代码逻辑错误

「 人很容易发现别人的错误，而对自己的错误视而不见 」

要想发现代码逻辑的问题，最简单的办法就是看老代码或者看别人的代码。代码逻辑体现的是你对需求的理解，以及你对整个产品逻辑的把控。

比如一个列表的渲染。每一次请求我们都会标记返回的数据列表，记作now_list，然后把列表拼接到现有的列表上面，记作list。当列表底部到页面底部的距离大于一定数值的时候会自动触发请求，加载loading。然后判断当now_list为空的时候，停止自动触发。这是正常的逻辑。

接下来，骚操作来了，把loading的开启条件放在了触发条件里，我们可以记作这个触发的方法为onEndReached，把关闭loading的方法放在了请求方法里。这样导致的结果就是当起始数据量小(比如列表长度为1的时候)的情况下，会不断触发loading，关闭loading，然后进入死循环。然后又一个骚操作来了，因为每次请求的列表数量为4，所以在onEndReached方法里，添加里一个判断条件，当now_list的长度小于4的时候，不开启loading。很简单的问题绕了一个大圈。而且像这种以数字为条件的的代码逻辑，一定要引起警惕。因为这预示着你的代码逻辑不严谨。关于代码逻辑的问题还有多层判断条件的问题，比如报告的生成与查看，查看报告的按钮除了不能在状态1和8展示，其余状态都可以展示;而下载报告的按钮只能在状态5或6展示，分享报告的按钮只能在6展示。无论查看、下载、分享都操作的是同一个按钮。像这种逻辑判断条件多的情况，极易产生错误。

产品需求的错误

「 需求评审，都是一场辩论会，不是说服别人就是被说服 」不要太相信产品，因为他们也会犯错误。总结了一下已知产品需求的错误，分两类：

无用的需求

不合理的需求

先说一下无用的需求，为什么说是无用的，比如上一版做的功能，下一版全部推翻。也就是说，在上一段时间内，你在做无用功，没有对产品产生任何价值。一群人白白耗费了一段时间去做了一件毫无意义的事情。再讲一下不合理的需求，比如买一赠N，在列表中折叠。不管是赠送的订单还是正常的订单，在订单列表中是平铺的。为了解决订单之间的关联关系，给用户呈现层级的展示效果，前端需要做的是把平铺的数据整合成树状结构，然后折叠起来，方便用户查看。列表请求数据条数是一定的，比如4条数据就可以填满屏幕，我们一般会请求5条，以便上拉加载。那么我们可以假设一下场景，比如买一赠7，当我们首先加载完5条数据，并整合成树状结构，折叠起来就变成了一条数据，就会再次触发请求加载，这次我们又加载了5条，不巧的是下一次的正常订单也是买一赠7，前3条数据还是上一条的赠送单，那么我们继续重组数据，现在订单中有两条数据，第一条数据折叠了7条，第二条数据折叠了一条，还会继续触发请求加载，直到屏幕上放满了正常的订单。这个过程会不断的重组数据，并不断的加载loading，关闭loading。专业点的术语可以叫"闪屏"。当然可以把折叠的数据默认展开，这也不失为一个好方法。我承认我们做的一些需求不一定合乎规范，并确实解决了一些问题。但是后期的维护实在太困难，而且不可预料。

场景缺失的错误

「 改bug，最忌讳的就是改一处，制造两处 」

场景缺失的问题，也可以简单的归为两类：

同样问题，只改了一处，其他处没有考虑到

关联问题，只改了有问题的地方，后续产生的问题没有考虑到

前端时间的地址问题确实困扰了一段时间，侧面反应了处理问题不严谨，也反应设计之初没有考虑周全。

省市区的问题，会伴随着传值、回显、提交拼接。问题就出现在了拼接。老数据是直接拼接在一起的，中间没有任何特殊标记，而现在的需求是第三方拿到这个数据无法解析。旧有的逻辑有自己的一套解析机制，但也存在一定的问题，不严谨。所以在已经存在问题的基础修改，注定还是会存在问题。最好的解决办法就是推翻重新制定规则。

当我们在解决问题的时候，一定要考虑此处修改的方案是否会对后续逻辑产生影响，尤其是改别人的代码逻辑，很多问题预料不到，推翻重写成本太大，所以在以后写业务代码的时候一定要解耦，堆在一起的代码，看的实在头疼。

异步错误

代码执行的时机一直以来是一个比较严重的问题，比如我们常常发现的，数据已经请求到了，为什么页面没有显示。

比如react中的setState，更新DOM树是一个很耗时的工作，setState会等一个时机做批量的更新，而不是直接更新。

再比如很多同学想在forEach或map中使用async异步函数，但是不要忘了，你接受的结果也是异步的。

概念理解错误

还有一些错误的因为你对事物本身不了解。

比如前几天面试，有一个女孩说「 我刚用vue3写了一个项目 」，那我就问「 那你vue3常用的语法有哪些 」，她的回答「 vue add、vue ui... 」。我当时脑子就大了。

还有群里哥们问的一个问题：

['1','2','3'].map(parseInt)

// [1, null, null]

['1','2','3'].map(Number)

// [1, 2, 3]

['1','2DDDD','3'].map(parseFloat)

// [1, 2, 3]

问：「 为什么parseInt不可以实现转化 」

map接受方法参数是固定，只能减少，不能修改，parseInt接受的两个参数，第二个参数直接被改成了map规定的索引值，再执行parseInt的逻辑，返回的肯定不对了。

换句简单的理解就是parseInt接受的参数被map强行改为了索引：

parseInt('2',1)

// NaN

parseInt('3',2)

// NaN 

我是小职，记得找我

✅ 解锁高薪工作

✅ 免费获取学习教程，开发工具，代码大全，参考书籍