前言 有一个礼拜没发quarku+graalvm相关的内容了,因为博主在忙一个新的前端项目去了,从element-ui切换到antdv,也有很多新的东西需要一边啃文档一边输出,程序出现bug自是在所难免的 在Run/Debug Configurations中,找到JavaScript Debug运行时,新建一个JavaScript Debug运行项,界面如下图所示: 序号1、输入jsdebug启动项目的名称 序号2、复制前端项目浏览地址到这里,这里需要说明下,jsdebug并不是帮你启动了一个前端项目,前端项目该怎么启动还怎么启动 序号3、选择一个你本地安装好的浏览器,我这里选择的就是360极速浏览器 会帮你在新的浏览器窗口里打开刚刚设置的URL地址,现在你可以在这个新打开的窗口里操作,当遇到你打断点的代码,IDEA的断点就会激活,这个时候就可以愉快的Debug起来了,效果如下图: 结语 IDEA的这个前端调试工具非常好用 ,却没有得到很好的普及,网上搜到的那种方式大多是安装一个IDEA的浏览器插件配合使用,相比来说,博主发现的这个调试工具简直太好用了,而且注意哦,此法不仅可以调试VUE的项目,而是适合所有的前端项目
这些都能帮助我们调试前端问题。本手册将以Chrome浏览器控制台为例进行讲解。 下图1为Chrome浏览器控制台,图2为Firefox控制台。 3代理 前端代理是指用本地文件替换网络文件的一个动作,代理可以用来调试问题。比如在本地文件中加上alert弹框弹出关键节点的信息,这可以有利于调试。特别是前端调试。 4移动端debug技巧 移动端调试指在安卓机/iphone/ipad等手持设备上调试前端页面逻辑的概念。这里将针对几种典型的情况给出最合适的debug方法。 TBS Studio是QQ浏览器X5内核前端调试平台,支持断点调试,抓取网络请求,查看DOM结构,console控制台等,功能非常丰富。 具体的操作方法见 https://x5.tencent.com/ 4.2安卓其它环境/ios环境 安卓其它环境下,或者ios环境下调试前端问题很难进行断点调试,只能采用最原始的打log,即alert弹框
如何在 VSCode 断点调试 js 代码 1 单文件调试 可以直接使用 Code Debugger 插件,免配置 launch.json 如果配置 launch.json 则是 { // 使用 launch", "skipFiles": [ "<node_internals>/**" ], }, ]} 2 调试 visual studio code - run vscode chrome debugger with its extensions - Stack Overflow 默认情况下,调用 chrome 启动调试 如果想要用日常使用的 chrome 调试,则设置 userDataDir 为 false。但非常不建议。 考虑到需要安装插件以辅助调试等,可以设置 userDataDir 到项目目录(别忘记添加 gitignore),或者添加到本机电脑的用户目录。
前端开发调试知识 参加字节跳动的青训营时写的笔记。这部分是秃头披风侠老师讲的课。 1. 前端 Debug 特点 多平台:浏览器、NodeJs、小程序 多环境:本地开发环境、线上环境 多工具:Chrome devTools、Whistle 多技巧:Console、BreakPoint、sourceMap debugger 或代码预览区域点击行号设置断点 代码执行到断点处,代码暂停执行 展开 Breakpoints 列表可以查看断点列表,勾选可以激活对应断点 鼠标放在变量上可以查看变量的值 在调试器 Watch 可以添加监听变量 Scope:展开 Scope 可以查看作用域列表(包含闭包) Call Stack:展开 Call Stack 可以查看当前 JavaScript 代码的调用栈 压缩后的代码调试 :通过 Source Map 映射源码实现调试,Source Map 文件不跟着部署上线,从而实现安全调试。
作者:enoyao,腾讯工程师 背景 随着我们项目越来越大,我们有可能需要维护很多的模块,我们腾讯文档 Excel 项目大模块有 10 几个,而每个大模块分别有 N 个小模块,每个大模块下的小模块都有主要的负责人在跟进模块问题 ,让他去慢慢定位问题,这样的每个新同学对模块的熟悉,学习和维护的成本就会变得越来越大,项目越大这种情况就会越严重! 方案 由于上面的问题真的很痛,我们在爬滚中逐渐摸索了一套方案,我们暂且叫它为基于断点调试的共享化和复用化的实践方案吧,这里有个关键词是断点,相比作为每一个开发者都不陌生,在我们前端,模块定位问题的时候, debugger 位置 pasteFromInter 2 行 4 列 isShapePasteFromOuter 256 行 89 列 isImgPasteFromOuter 867 行 12 列 对于大型项目来说 () => { debugger } this.xxx = () => { debugger } class xxx { xxx = () => { debugger } } 虽然大部分情况匹配函数对项目下发的调试代码能覆盖大部分的场景
在前端的开发过程中,免不了进行各种调试和测试。 在不同的平台,不同的环境下的调试方法也不尽相同,这个系列文章将探索常见的一些前端调试场景,较为系统地整理出一些调试方法。 主要包含在 PC上的 IE、FireFox、Chrome、Safari、Edge浏览器开发工具调试,远程真机 安卓微信页面、安卓常见浏览器、WebView环境、iPhone微信页面、iPhone的Safari 调试 API测试工具Postman、抓包工具Fiddler,Charles,Packet Capture,HttpInterceptor、微信开发者工具、Node环境调试等 文章知识点可能是错乱交织在一起的 ,如果有断片的地方,还请多多包涵~ (更新中...)相关文章: Chrome开发者工具调试指南(Todo) Postman的API工具使用指南(Todo) Fiddler抓包工具使用指南(Todo) Charles 抓包工具使用指南(Todo) 安卓微信页面的调试 iPhone微信页面的调试 NodeJS基础调试(Todo)
前言 当我第一次知道这种东西,我也惊呆了,居然还有这种操作,实在强大到没朋友,从此爱上调试,按时下班。 无数次通过调试解决问题的经验告诉我,调试绝对是开发者最应该掌握的重要技能之一。 断点方式三 这种方式简单归为在编辑器中断点调试,是需要连接调试器(可以是远程调试器)或者附加进程,然后接收调试信息,就可以在编辑器源码进行断点调试。 :在vue文件组件你想调试的行的断点,通过命令npm start、npm dev或者npm serve其中一个命令(具体是哪一个可以查看package.json的scripts节点)运行项目。 远程调试Chrome 附加浏览器的方式,不同于上一种,修改代码后要刷新页面才能重新断点调试 待更新 断点方式四 这种方式归为调试nodejs,可以调试webpack配置,或者后端运行的node实例。 这种方式是在启动node的时候加上--inspect,开启V8 Inspector功能,通过WebSockets通信,调试器连接即可调试,更多调试器参考官方文档。
sourceMapPathOverrides": { "webpack:///*": "${webRoot}/*" } }] } 打断点,在 Debug 模块启动调试
网页调试(重点) 开发者工具对于开发者来说特别重要,只要你开发你就离不开它。一定要学会使用 作用:调试代码 检测代码的!! 审查元素/查看元素/检查)或者按F12,在右侧或下面会打开一个窗口,窗口最左边是查看html的结构,network是查看网页的http请求加载,console是控制台,查看网页中打印的信息,也可以自己写调试代码 主要掌握elements这个面板 右侧的style就是当前标签对应的css样式 我们可以通过这个来检查代码错误和调试代码!!
在前端开发中,Chrome 调试工具几乎是必不可少的利器。本文将详细介绍 Chrome 调试工具的使用方法和技巧,让大家更加高效地排查和解决网页开发中的问题。 Chrome 1. 2.1 Elements 面板的基本操作 Elements 面板 是前端开发中最常用的一个面板,它主要用于调试 HTML 和 CSS。 小结 Chrome 浏览器提供的调试工具是前端开发者不可或缺的工具,通过它我们可以深入了解页面的 HTML 结构、CSS 样式、JavaScript 代码以及页面的加载情况。 本文详细介绍了如何打开和使用调试工具、如何调试 HTML 和 CSS、如何使用 Console 面板以及其他一些实用的调试技巧。 熟练掌握 Chrome 调试工具,可以大大提高我们开发和调试网页的效率,让我们的前端开发之路更加轻松愉快。
本期精读的文章是:debugging-tips-tricks 编码只是开发过程中的一小部分,为了使我们工作更加高效,我们必须学会调试,并擅长调试。 2 内容概要 文中列举了常用调试技巧,如下: Debugger 在代码中插入 debugger 可以在其位置触发断点调试。 移动端控制台 Chrome远程调试 app 支持后,连接 usb 或者局域网,即可通过 Dev Tools 调试 webview 页面。 Weinre 通过页面加载脚本,与 pc 端调试器通信。 3 总结 虽然在抛砖引玉,但整理完之后发现仍然是块砖头,调试技巧繁多,里面包含了通用的、不通用的,精读不可能一一列举。希望大家能根据自己的业务场景,掌握相关的调试技巧,让工作更加高效。 讨论地址是:精读《前端调试技巧》 · Issue #17 · dt-fe/weekly
但模拟毕竟是模拟,当开发完毕,使用真机访问页面出现问题时如何调试呢? 下面介绍一种针对android机的调试方法 1. 在pc和android手机上都安装最新版本的chrome 2. 手机中打开“设置”->"开发人员选项"->"USB调试" ? ? 4. 点击上图中的inspect, 熟悉的调试界面出现! ? 注意图中右上角的手机图标,点击后,效果更加酸爽。手机打开的页面被直接拉到pc上显示了。调试更加事半功倍! ?
VSCode前端调试的几种场景 前言 看了神光的前端调试秘籍通关,以及查询一些资料后总结的。这本小册真的强烈推荐,非常有用,非常有用。 如果想要跳过node_modules则可以添加"${workspaceFolder}/node_modules/**" 调试脚本启动 有用过Vue的应该都知道,启动项目是通过npm run dev这种形式启动的 调试上线页面 使用Vue开发时,当我们部署打包项目用于上线时,代码会被打包混淆。这种情况下,这种情况下就很难调试。 比如: 这时候,就需要用到sourcemap来辅助调试了。 修改一下配置信息就可以了,下面用还是用Vue3的项目来搞一波。 想要调试Vue源码,就将runtime-core目录下的dist复制到vue项目的node_modules下的dist。
Apache arrow顶级项目调试 arrow官方从7.x版本开始提供了一个gdb工具,叫做gdb_arrow.py,可以在仓库里面下载下来。 调试原理可以阅读之前写的文章: 玩转C++调试之Python的GDB库增强 使用办法非常简单,直接: source /code/arrow/cpp/gdb_arrow.py 如果在gdb里面source 下面来看看使用脚本与不使用脚本调试的显示情况吧。 默认调试 (gdb) p *schema $2 = (std::__shared_ptr_access<arrow::Schema, (__gnu_cxx::_Lock_policy)2, false, 以后调试arrow又更加方便了。
C:\WINDOWS\system32\Macromed\Flash\Flash10b.ocx 程序调试需要安装9版本的,这是已经安装的10版本的,需要再下一个flashplayer_10_ax_debug.exe
alert('xxxxx'); alert的调试信息,必须在程序逻辑中添加类似”alert(xxxxx)”这样的语句,才能正常工作,并且alert会阻碍页面的继续渲染。 这就意味着开发人员调试完成后,必须手动清除这些调试代码,实在有些麻烦。 当然,为了代码整洁,在调试完成后,还是应尽可能删除这些与业务逻辑无关的调试代码。 浏览器控制台JS断点调试 即是在浏览器开发者工具中为JS代码添加断点,让JS执行到某一特定位置停住,方便开发者对该处代码段的分析与逻辑处理。
做前端也不是很久,也没做过什么特别大型或者是特别复杂需要很多前端配合开发的项目,所以对于前端的架构我并没有一个清晰的认识。 只是最近看着新公司的项目,实在有感而发,忍不住想说说前端项目最基础的一些架构。 现在几乎都是前后端分离了,所以前端项目都是前端自己搭建,整个项目的结构都把握在自己手里。 一个好的项目架构有什么好处呢,无外乎现在网上一直说的那几点,代码可读性、可维护性、可扩展性。当然,本人能力有限,说说基于本人认识上前端项目应该做的。 结构上,应该明确各种资源所放的位置。 组件,现在前端开发都是组件化开发,各个框架也提倡组件化开发,所以对于公共的组件封装,很重要,对于代码量减少的不是一点半点。对于维护和修改提高也很大。 不同人的敲代码的习惯都不一样,要是很多人开发一个项目或者是经很多手开发,那么这个项目在不同习惯下的代码,是很乱很杂的。
通常,前端调试输出一些日志信息可以使用alert或者console, 当然在Desktop机器上很容易,很多浏览器都支持,如果是在手机上,可能比较麻烦,怎么得到输出的console信息呢.
小东西快快学快快记,大知识按计划学,不拖延 今天介绍一款前端必备的调试工具,真的真的非常好用,起码能提高几倍以上的调试效率。 想想一般我们开发项目的痛点 ? 1.跨域问题。 后台接口没弄好,还要项目里面直接模拟数据 3.难以模拟请求多种情况。在不改动代码情况下,很难模拟请求的各种情况,加载超时,接口报错,接口各种状态响应,网络情况 等 4.请求重试成本高。 2、常用的请求拦截修改 3、规则说明 4、其他高级修改 5、请求快捷操作 1 项目开发的基本转变 我们先去右键新建一个规则合集,尝试一下最简单的规则 ? 我们肯定都遇到过,开发好好的,上线就一堆问题,根本原因就是没有在开发阶段充分模拟生产环境 1 项目开发的基本转变 上面已经使用 whistle 去解决本地开发调试了,下面我们将调试效率最高化 1简单数据 yysy,真的对我们的调试开发帮助太大了,让我们拜托界面刷新的调试方式,解放精力做更多事情 最后 其实我也是一直用着 whistle,却没有非常系统地学习过,所以导致开发的时候,碰到也是懵逼懵逼 这次终于给总结完了
在前端调试接口的过程中,我遇到了一些错误,现将它整理出来,大概有以下几种情况。