这是我参与「第五届青训营」笔记创作活动的第二十天
Bug是不可避免的，只要你写代码，bug就一定会产生，但你可以通过Debug来解决它
前端开发调试之 PC 端调试
Chrome DevTools
Elements页
- 当然这个Tab中的功能远不止这些，比如我们还可以利用该Tab中的功能实现对特定元素的截屏并下载
Console页
打印日志的界面
- 我们可以给日志添加样式
- 不同类型的值输出的颜色是不一样的，比如
console.log("123");和console.log(123)的输出颜色是不同的 - 不要只会使用console.log, 比如
console.table和console.dir在展示一些特定的数据的情况下，很好用！ - 同样该页面的内容也远不止这些，比如还有
console.time(); console.timeEnd();常用来计时一段代码的运行时间等
Source页
-
打断点有两种方式：
- 在代码的相应位置添加debugger关键字
- 在代码预览区域的相应行号位置可以设置断点
-
XGR/fetch breakpoints: 所有请求的断点
- Any XHR or fetch: 所有请求发生时记录断点
- URL contains {PH1}：部分符合条件的请求发生时记录断点
-
DOM breakpoints: 当HTML中的某个元素发生变化时，记录断点，可能在开发静态页面和动态效果时比较有用
-
当然还有很多功能没有介绍
SourceMap
这种情况下就需要使用到SourceMap (当然除了压缩，还有一种是加密，这里就不介绍了)
SourceMap起到的是一个映射的作用，从压缩混淆后的代码映射到未经压缩混淆的源码
-
version: 使用的SourceMap版本 -> 目前常用的是V3
-
file: 对应映射的文件
-
mappings: 映射规则，是经过Base64编译过后的数字，原本表示的行号和列号
-
sources: 源文件地址
-
sourcesContent: 源文件内容 (即源码)
-
SourceMap的大小是比源码大的 -> 带来两个问题
- SourceMap如果上线的话，体积会变得比较大
- 如果为了追求体积的优化，不带SourceMap上线，则如果线上出了问题，经过压缩混淆的代码又会给调试带来问题 (不可调试)
上述问题的解决办法： 这里通常对应的是上线或工程领域经常会去处理的问题, SourceMap通常运用的场景是监控，在监控的时候，整个代码上线的时候，为了安全和体积，是不上SourceMap的。那具体是怎么解决的呢，打包的时候是带sourceMap的，但我们单独把SourceMap上传到另一个平台，比如说我们的监控平台，然后上线的时候不带SourceMap (把SourceMap删除掉，然后把它部署上线)，这个时候，线上运行，别人看到的就是压缩混淆之后的代码，是不可阅读的，如果出了问题，线上监控平台会收集错误，然后会拿平台上对应的SourceMap文件，然后去展示出对应的源码位置
拿Webpack为例，启用或关闭SourceMap是通过配置Webpack配置文件达成的, devtool: 'source-map'
NetWork页
除了基本用法，这个页面在前后端协作时也很好用，可以快速定位到问题 (包括但不限于判断到底是前端还是后端的锅)
Application页
存储相关的信息
实战
利用代理解决开发阶段的跨域问题
本地解决方法：
- Webpack 启一个devServer
- 使用代理工具
部署到线上后：
- 也是通过代理来实现，不过通常是通过Nginx配置来解决
启用本地SourceMap
可以利用代理工具使线上环境访问本地SourceMap
