告别懵逼——前端项目调试与问题排查方法小结

在日常工作中，我们常常会遇到以下两类典型的挑战：

场景一： 接手无文档的老项目
1、情景描述： 你接手了一个历史久远的项目，项目文档缺失，前任开发者已经离开，而你对当前的业务逻辑和代码结构都不熟悉。然而，线上系统出现了故障，需要紧急解决。

2、挑战：

• 缺乏文档资料，难以快速了解系统架构。
• 不熟悉业务流程，难以迅速定位问题。
• 代码结构混乱，增加了调试难度。

场景二： 项目中出现难以复现的幽灵Bug
1、情景描述： 项目中出现了难以捉摸的Bug，相关反馈人员（如测试工程师、实施人员等）无法准确描述或复现问题，这使得问题的定位变得异常困难。

2、挑战：

• 问题出现的概率较低，难以捕捉。
• 相关人员提供的信息不完整，缺乏具体细节。
• 缺乏一致的复现步骤，难以进行有效的调试。

不管是哪种场景，我们要解决问题，关键的一点就是必须找到引发问题的地方，以及真正引发问题的原因。

查找定位错误文件的方法

我们首先可用通过以下方法，来找到和定位引发问题的文件：

1、通过页面路由路径查找： 此方法得基于规范得页面结构，如果一个项目得项目文件引用像蜘蛛网一样错综复杂，此法行不通
2、通过css样式查找： 浏览器上鼠标选中对应的html，查看css，然后全局搜索
3、通过菜单查找： （页面菜单管理或者菜单数据，结合页面路由路径，找到对应的文件地址，比如component配置）。对于采用动态配置菜单得项目可用
4、全局关键字搜索： 通过页面特殊关键字全局搜索，查找文件。前提是该关键字在项目中出现次数比较少，最好5次以下。另外，全局搜索时，应将打包后的文件删除或者排除在外，避免干扰
5、从逻辑上顺藤摸瓜： 根据路由文件的逻辑，比如先找到路由文件，然后根据“查看”按钮，找到详情页文件

页面调试的一些思路整理：

1、遇到页面出不来，第一反是看浏览器控制台，观察是否报错，如果报错，根据报错指定的文件去查找错位问题，改正侯继续观察页面情况
2、控制台如果没用报错，查看netWork对应的接口请求，看是否有数据
3、如果有，检查代码逻辑，是否获取到数据（一定得检查并打印或者debug查看，而不是空想）
4、遇到棘手的，无法定位错误的问题，可以使用注释部分代码，观察页面变化的方式、找到错误文件后，根据文档等定位代码逻辑，根据代码逻辑打印调试数据，并分析数据是否正确
5、还原真实的操作逻辑和使用场景。能准确复现的问题相对很难复现的问题，会比较好解决。如果是其他人发现的问题，尽可能的摸清楚对方的操作逻辑，在相同账号、相同数据下来查找问题
6、涉及硬件、设备的，做好关键步骤和逻辑的数据打印，然后分析日志

以下案例均为笔者之前亲身经历。

案例一：某单位取款机项目，部分客户登录跳转首页，客户取钞过程中莫名跳转首页问题排查。

该问题在公司测试时并没有发现，出差到现场时，开始的第一天也未出现此问题

排查方法

• 首先分析日志，从日志打印的顺序和时间上分析，发现钞票冠字号打印的顺序和取款批次不完全一致，有延后的情况

• 问题复现方式：模拟现场用户取款实际步骤流程情况来测试后复现了问题

  关键方法： 还原用户真实场景测试复现

案例二： vue-press打包报错error Error rendering /
该问题的难点在于，报错信息基本无用，从报错信息上几乎找不到报错的原因和引发位置

原因查找：

• 文档+已有知识：根据查阅官网示例文档，vue-press是服务端渲染。
• 本地搭建测试环境：结合项目本身需求和环境排查，采用本地建测试仓库，本地建测试组件库，本地建测试文档项目
• 统一测试流程：逐个移植原组件库的组件到测试组件库中（这里也可以采用二分法），发布到测试仓库后，更新测试文档，然后执行vue-press项目本地打包命令。

查找结果：

• 初步组件定位：最终找出影响打包的组件有弹窗、文件上传、文件预览、裁剪等组件。这些组件的共同点就是都直接或间接用到了document操作dom，或者使用了window对象调用api。
• 初步验证：锁定组件后，仅留下这些组件中的一个，然后去掉document相关调用，得到了正确的验证。
• 进一步验证：后又通过对其他组件使用注释/开启方式不断测试，确定了问题原因包括：在create生命周期中使用window、document或bom方法事件，import引入含有或间接调用含有window、document或bom方法事件的函数

关键方法： 逐渐注释和逐渐移植（或者二分法）

假设你是一个科学家——以科学探究的精神面对挑战

在面对复杂且难以一眼洞悉的问题时，你是否曾想过，或许可以借鉴科学研究的方法来寻找和解决问题？

1、提出猜想。当遇到一个未知的、暂时无法准确定位具体问题的bug时，可以先以自己当下知识，提出可能的假设原因
2、验证猜想。猜想必须要验证。这里要注意的是，提出的只是猜想，并非就一定是这个原因，所以要避免先入为主的观念，而是要用事实来证明猜想的正确性。

如何验证？

• 打印数据。打印数据时，注意浅拷贝问题。数组和对象的打印，建议使用JSON.parse(JSON.stringfy()),杜绝数据变化
• 注释特定地方代码
• 修改特定地方代码

3、问题未解决之前，不断提出猜想，反复验证

案例一： 某政府大屏项目——解决客户电脑(winserver2012政企版，蓝色chrome 83)浏览器布局出现混乱的问题。

• 出现场景：客户电脑和windowserve2012系统上，装客户的特供版chrome浏览器，会出现该问题。
• 原因推测：因开发电脑装了特供版chrome浏览器没复现，故只能推测原因。推测为界面使用flex布局，出现问题的时候，界面flex布局的row失效，混乱效果和直接使用block相同，可能是浏览器版本较低，加上该浏览器内核和通用chrome内核更新并不一致，最终对项目中的flex布局支持异常导致。
  解决： 加上百分比宽度布局兼容，给模块容器加上宽度100%显示，模块加上比例宽度兼容，测试后解决。

案例二： 某项目需要从第三方平台跳转，在开发者模式下模拟可以正常跳转，而在打包到客户生产环境下无法正确跳转
问题描述： 本该跳转到登录页面的地址，变成了ajax网络请求，页面显示404数据信息。

• 猜想一：
  原因推测： 前端路由地址和后端api地址冲突
  验证： 前端修改路由路径信息验证，失败，排除了前后端路由和api冲突的可能
• 猜想二：
  原因推测：nginx vue history模式必须的 try_files配置、即404重定向配置
  验证：加上后try_files配置问题未解决
• 猜想三：
  原因推测：nginx整体配置问题
  验证：尝试将后端api配置注释，操作后项目可以成功的跳转到前端页面，确定了跳转失败的原因所在，后由后端伙伴提供新的配置后，问题解决

知识深度和广度的影响

知识深度和广度，可以在一定程度上快速帮你解决问题、查找原因

• 知识深度：比如，一个vue2页面，你发现数据更新了，但是页面没有更新。从知识深度来讲，如果熟悉vue的$Set和vue对象在初始创建时没有对应的键名的坑，那看一下代码，就很快能联想到在赋值的地方需要用this.$set；又比如熟悉js基本类型和引用类型在存储上的区别，在处理数据莫名其妙发生变化的情况时，很容易就能想到是下游数据改变，影响了上游数据的原因
• 知识广度：比如用Uniapp写一个app，发现网页端视频可以播放，app视频无法播放，对安卓熟悉的很容易就会联想到权限问题

工具的运用

百度搜索——适合英文不好的，但是专业网站上的iss等基本搜不出来
谷歌搜索——如果需要搜索国外的方案，最好有一点英文基础，能看个大概也行，可以搜索到github上的issue，还有，很多新新技术，国外的解决方案比国内多
AI工具——ChartGpt、通义千问等智能型工具