Recent Posts
记一次被AI坑的有趣经历
最近在 Cursor 的帮助下,我顺利完成了一个纯前端的小工具。 从开始到 demo,全程和 AI 对话,一路点击 “Accept” 即可,非常顺利。 但在最后优化核心数据处理时,踩了个小坑。
这个坑开始于如下需求:
将前端渲染的数据保存到 url 内,以便用户可以通过分享链接直接访问到这个页面。为了节省 url 长度,我们需要将数据进行压缩, 并对压缩后的数据进行某种 url safe 的编码。
对于 url safe 的编码,我了解的很少,只是大概知道 Bas64 或者 urlEncode 大概适合这种场景的,也知道经过编码后,数据会产生一定程度的膨胀。
于是我和 AI 之间有了如下对话:
AI 的回复条理通顺,数据齐全,我没多想,直接采用了 AI 生成的如下编解码函数:
// 添加编码/解码工具函数 const urlSafeChars = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-_"; function bytesToUrlSafe(bytes) { let result = ''; for (let i = 0; i < bytes.length; i++) { result += urlSafeChars[bytes[i] & 0x3F]; // 取低 6 位 if (i < bytes.
read more
避免 Intellij IDEA 远程 debug 卡顿的三个技巧
为什么远程 debugger 可能卡顿? Intellij IDEA 的远程 debugger 使用 jdwp 协议与 JVM 通信。发生在打断点,查看变量内容,执行代码等 debug 操作后面的,实际上是一系列 jdwp 指令。 跨越公网进行远程 debug 时,受限于网络延迟,一个指令从发出到收到响应,可能需要几十毫秒甚至更长时间。虽然 jdwp 协议本身支持异步通信,但部分 debug 操作仍然只能通过一系列同步的 jdwp 指令完成, 连续多个同步指令的延迟叠加在一起,就会导致肉眼可见的 debug 操作的卡顿。
所以,从原理上来说,为了避免操作卡顿,我们应该尽可能减少不必要的 jdwp 指令。
三个技巧 1. 关闭 toString 对象是图和集合类替代视图 在 IDEA 的 debug 配置 “调试器/数据视图/Java” 中,有两个默认开启的功能,”toString() 对象视图”和 “集合类替代视图”。这两个功能方便在 debug 时直接查看对象内容,但代价是需要执行大量 jdwp 指令。 远程 debug 时,为了避免单步执行等操作卡顿,最好关闭这两个功能。
2. 避免在非挂起(suspend)状态查看 threads 面板 IDEA debugger 的 threads 面板能直观地展示出当前 jvm 内每个线程的名称和状态。在渲染这个面板的过程中,IDEA 会向 jvm 发送一个指令获取所有线程 ID,然后为每个线程 ID 发送两个指令获取线程名称和状态。 如果 jvm 内线程较多(几十个足矣),则需要执行的 jdwp 指令非常多。且 threads 面板会在每次线程开始或退出时完全重建,如果 jvm 内线程频繁变动,该面板可能还处于数据收集状态就触发了重新渲染。
read more