前端达人-CSDN博客

原创为什么绝大多数前端仍在用“笨办法“做懒加载？一次性搞懂IntersectionObserver

你想啊，用户打开你的页面，他的视口（viewport）可能只能看到整个页面的15%，剩下85%的内容和图片远在下方。浏览器在底层使用了优化的机制（不需要你频繁计算），只在元素的"可见性状态"真正改变时才触发你的回调。当页面加载了1000张图片，每张都忘记unobserve，观测器会一直持有这些引用。开发者精心做了图片压缩、加了CDN，结果还是卡顿，最后才发现是scroll事件的锅。IntersectionObserver在现代浏览器中支持得很好，但如果你需要兼容IE11...那我建议你升级用户的浏览器😄。

2026-02-05 21:27:19 236

原创为什么绝大多数前端仍在用“笨办法“做懒加载？一次性搞懂IntersectionObserver

你想啊，用户打开你的页面，他的视口（viewport）可能只能看到整个页面的15%，剩下85%的内容和图片远在下方。浏览器在底层使用了优化的机制（不需要你频繁计算），只在元素的"可见性状态"真正改变时才触发你的回调。当页面加载了1000张图片，每张都忘记unobserve，观测器会一直持有这些引用。开发者精心做了图片压缩、加了CDN，结果还是卡顿，最后才发现是scroll事件的锅。IntersectionObserver在现代浏览器中支持得很好，但如果你需要兼容IE11...那我建议你升级用户的浏览器😄。

2026-02-05 21:27:19 188

原创 PostgreSQL还是MongoDB？选错数据库，你的Node.js应用可能快不了

想象一下，如果有 100 个请求同时到达你的服务器，每个请求都要建立一个到 PostgreSQL 的连接。很多初学者拿到需求时，看到数据就直接上MongoDB（"啊，JSON格式多省事啊"），或者看到关系就无脑PostgreSQL（"这是大厂标配"）。但这样做的代价，在系统真正承载数据压力时，才会显现出来。即使你写的 SQL 不是最优的，它也能想办法给你一个不太差的执行计划。：PostgreSQL 有接近 30 年的发展历史，查询规划器能在你写出烂SQL的时候，仍然想办法给你一个不至于太糟糕的执行计划。

2026-02-04 21:31:07 330

原创为什么你的异步代码总是不按套路出牌？深入揭秘JavaScript事件循环的真相

从系统设计的角度讲，微任务代表的是"我需要在下一帧渲染前执行"的事项，而宏任务代表的是"安排在某个时间点执行"的事项。处理它们的工作被转移到了浏览器的其他线程（比如定时器线程、网络线程），当这些线程完成了工作，它们才会把结果"归档"到一个等待队列里，等待JavaScript主线程来处理。问题在于，所有10000个Promise.then都会进入微任务队列，在事件循环清空微任务队列时一口气执行，导致主线程被占用，浏览器无法进行渲染。如果你在微任务里无限创建新的微任务，宏任务队列里的任务永远都排不上队。

2026-02-03 20:36:47 221

原创我被Hoisting“坑“过无数次，才搞明白JavaScript这个致命陷阱

更糟糕的是，即使工作三五年，他们对Hoisting的理解仍然停留在"var会提升，let不会"这样的模糊概念上。但菜单上有个特殊规则：有些菜（var）会先上一份"空盘子"给你，直到你真的点到那道菜的"烹饪指令"才会做好；这看起来是小问题，但在高频调用的情况下（比如列表滚动、实时搜索），每次调用都会保留这些临时变量在内存中，导致垃圾回收效率降低。这些"灵异事件"的幕后黑手，就是JavaScript的。TDZ的哲学是：与其悄悄给你undefined这个"地雷"，不如直接告诉你"这个变量还没准备好"。

2026-02-02 21:47:53 706

原创我被Hoisting“坑“过无数次，才搞明白JavaScript这个致命陷阱

更糟糕的是，即使工作三五年，他们对Hoisting的理解仍然停留在"var会提升，let不会"这样的模糊概念上。但菜单上有个特殊规则：有些菜（var）会先上一份"空盘子"给你，直到你真的点到那道菜的"烹饪指令"才会做好。JavaScript引擎在代码执行前，会对代码做一次预编译扫描，把所有的声明（变量、函数）登记到内存中。这看起来是小问题，但在高频调用的情况下（比如列表滚动、实时搜索），每次调用都会保留这些临时变量在内存中，导致垃圾回收效率降低。这些"灵异事件"的幕后黑手，就是JavaScript的。

2026-02-02 21:47:53 309

原创我被Hoisting“坑“过无数次，才搞明白JavaScript这个致命陷阱

更糟糕的是，即使工作三五年，他们对Hoisting的理解仍然停留在"var会提升，let不会"这样的模糊概念上。但菜单上有个特殊规则：有些菜（var）会先上一份"空盘子"给你，直到你真的点到那道菜的"烹饪指令"才会做好；这看起来是小问题，但在高频调用的情况下（比如列表滚动、实时搜索），每次调用都会保留这些临时变量在内存中，导致垃圾回收效率降低。这些"灵异事件"的幕后黑手，就是JavaScript的。TDZ的哲学是：与其悄悄给你undefined这个"地雷"，不如直接告诉你"这个变量还没准备好"。

2026-02-02 21:47:53 645

原创我被Hoisting“坑“过无数次，才搞明白JavaScript这个致命陷阱

更糟糕的是，即使工作三五年，他们对Hoisting的理解仍然停留在"var会提升，let不会"这样的模糊概念上。但菜单上有个特殊规则：有些菜（var）会先上一份"空盘子"给你，直到你真的点到那道菜的"烹饪指令"才会做好；这看起来是小问题，但在高频调用的情况下（比如列表滚动、实时搜索），每次调用都会保留这些临时变量在内存中，导致垃圾回收效率降低。这些"灵异事件"的幕后黑手，就是JavaScript的。TDZ的哲学是：与其悄悄给你undefined这个"地雷"，不如直接告诉你"这个变量还没准备好"。

2026-02-02 21:47:53 102

原创我被Hoisting“坑“过无数次，才搞明白JavaScript这个致命陷阱

更糟糕的是，即使工作三五年，他们对Hoisting的理解仍然停留在"var会提升，let不会"这样的模糊概念上。但菜单上有个特殊规则：有些菜（var）会先上一份"空盘子"给你，直到你真的点到那道菜的"烹饪指令"才会做好。JavaScript引擎在代码执行前，会对代码做一次预编译扫描，把所有的声明（变量、函数）登记到内存中。这看起来是小问题，但在高频调用的情况下（比如列表滚动、实时搜索），每次调用都会保留这些临时变量在内存中，导致垃圾回收效率降低。这些"灵异事件"的幕后黑手，就是JavaScript的。

2026-02-02 21:47:53

原创 1GB大文件不再卡顿？揭秘JavaScript Streaming和背压的工作原理

在ByteDance、Alibaba、Tencent这样的大厂，Streaming和背压早就是标配方案了。因为UTF-8的字符可能由多个字节组成，如果一个chunk在字符中间被切割，直接decode会得到乱码。很多开发者会犯的错误是，流来一条数据就写一条数据库，这样会造成大量I/O。：学会Streaming和背压，你就掌握了大数据处理的密钥。今天，我想带你深入理解这两个概念背后的原理，以及它们如何能让你优雅地处理大数据量。这就像自助餐厅一样，菜一上来就吃，吃完一盘释放盘子，永远只占用一个位置。

2026-02-01 12:55:25 1003

原创为什么你的代码能力越强，反而在公司越“不存在“？

"我识别出瓶颈在于重复的 DOM 序列化操作（占 CPU 时间的 34%），通过引入 Virtual Buffering 缓存，减少了 87% 的序列化调用，实现了从 340ms 到 42ms 的改进。一个月后，上级对 A 的认知可能还停留在"这哥们好像在做优化"，而对 B 的认知是"这位定位并解决了性能瓶颈，影响整个业务线"。代码质量顶级，日更无虚，issue 秒杀，但升职加薪的时候，却始终轮不到他。你可能是团队里最会写代码的人，但如果你的工作成果只能在 Git log 里被看见，那你就不过是一个。

2026-01-31 20:53:48 557

原创为什么你的代码能力越强，反而在公司越“不存在“？

"我识别出瓶颈在于重复的 DOM 序列化操作（占 CPU 时间的 34%），通过引入 Virtual Buffering 缓存，减少了 87% 的序列化调用，实现了从 340ms 到 42ms 的改进。一个月后，上级对 A 的认知可能还停留在"这哥们好像在做优化"，而对 B 的认知是"这位定位并解决了性能瓶颈，影响整个业务线"。代码质量顶级，日更无虚，issue 秒杀，但升职加薪的时候，却始终轮不到他。你可能是团队里最会写代码的人，但如果你的工作成果只能在 Git log 里被看见，那你就不过是一个。

2026-01-31 20:53:48 371

原创为什么你的代码能力越强，反而在公司越“不存在“？

"我识别出瓶颈在于重复的 DOM 序列化操作（占 CPU 时间的 34%），通过引入 Virtual Buffering 缓存，减少了 87% 的序列化调用，实现了从 340ms 到 42ms 的改进。一个月后，上级对 A 的认知可能还停留在"这哥们好像在做优化"，而对 B 的认知是"这位定位并解决了性能瓶颈，影响整个业务线"。代码质量顶级，日更无虚，issue 秒杀，但升职加薪的时候，却始终轮不到他。你可能是团队里最会写代码的人，但如果你的工作成果只能在 Git log 里被看见，那你就不过是一个。

2026-01-31 20:53:48 194

原创为什么你的代码能力越强，反而在公司越“不存在“？

"我识别出瓶颈在于重复的 DOM 序列化操作（占 CPU 时间的 34%），通过引入 Virtual Buffering 缓存，减少了 87% 的序列化调用，实现了从 340ms 到 42ms 的改进。一个月后，上级对 A 的认知可能还停留在"这哥们好像在做优化"，而对 B 的认知是"这位定位并解决了性能瓶颈，影响整个业务线"。代码质量顶级，日更无虚，issue 秒杀，但升职加薪的时候，却始终轮不到他。你可能是团队里最会写代码的人，但如果你的工作成果只能在 Git log 里被看见，那你就不过是一个。

2026-01-31 20:53:48 304

原创为什么你的代码能力越强，反而在公司越“不存在“？

"我识别出瓶颈在于重复的 DOM 序列化操作（占 CPU 时间的 34%），通过引入 Virtual Buffering 缓存，减少了 87% 的序列化调用，实现了从 340ms 到 42ms 的改进。一个月后，上级对 A 的认知可能还停留在"这哥们好像在做优化"，而对 B 的认知是"这位定位并解决了性能瓶颈，影响整个业务线"。代码质量顶级，日更无虚，issue 秒杀，但升职加薪的时候，却始终轮不到他。你可能是团队里最会写代码的人，但如果你的工作成果只能在 Git log 里被看见，那你就不过是一个。

2026-01-31 20:53:48 136

原创你写代码越来越多，为什么成长反而停滞了？

"我每天都在 GitHub 提交代码，Leetcode 也在刷，加班改 bug，业务迭代赶得飞快，但总感觉自己没有进步。同时期，别的组用同样时间，改进了主流程的用户体验，影响了 80% 的用户。反而另一个同事，代码量中等，却在业务架构、性能优化、技术选型上频频给出有价值的建议，升级快得多。但后来发现，这个操作的用户占整体的 2%，而且是高级用户，他们根本不在意这 2.5 秒。我们这个行业最需要的，不是更多的代码，而是更多有系统思维的工程师。但很有趣的是，他升级慢，大会议发言少，技术方案评审时声音小。

2026-01-30 21:22:35 798

原创 AI 生成 80% 代码，那剩下的 20% 才是你的价值

当我在审阅同事提交的 Pull Request 时，我发现，这份代码的 80% 是由 Claude 和 Sonnet 生成的。Code Review 的标准也在调整，从"代码写得漂不漂亮"转向"架构思路合不合理"。真正的价值是知道什么时候说"不需要"、"太复杂"、"这会卡你未来的手脚"。一个初级开发者的答案是"行"或"不行"。**差别不是"会不会用 AI"，而是"有没有能力有效地利用 AI 的输出"**。如果你只会用 AI 来"加"，完全不知道怎么"减"，那你生成的代码会越来越臃肿。

2026-01-29 20:53:38 242

原创＜span class=“js_title_inner“＞AI 生成 80% 代码，那剩下的 20% 才是你的价值＜/span＞

当我在审阅同事提交的 Pull Request 时，我发现，这份代码的 80% 是由 Claude 和 Sonnet 生成的。Code Review 的标准也在调整，从"代码写得漂不漂亮"转向"架构思路合不合理"。真正的价值是知道什么时候说"不需要"、"太复杂"、"这会卡你未来的手脚"。一个初级开发者的答案是"行"或"不行"。**差别不是"会不会用 AI"，而是"有没有能力有效地利用 AI 的输出"**。如果你只会用 AI 来"加"，完全不知道怎么"减"，那你生成的代码会越来越臃肿。

2026-01-29 20:53:38 801

原创为什么你的认证系统选错了？JWT vs OAuth 背后的真相

用户A在服务器1登录，他的Session存在服务器1的内存里。许多大厂的解决方案是维护一个"黑名单"（Token Blacklist）——这完全抵消了JWT的无状态优势。那么在这1小时内，如果Token被盗，攻击者有完整的时间窗口进行操作。如果你有不同的想法或踩过其他的坑，欢迎在评论区分享你的经验——这些真实场景的故事往往比任何教程都更有价值。这是O(1)的操作，看似没问题，但在日活百万的系统中，这些查询聚合起来就是显著的性能开销。你的应用现在使用的认证方案，真的是为你的场景量身定制的吗？

2026-01-28 20:26:37 611

原创你的表单代码为什么一团糟？深度剖析大规模表单架构的终极秘密

一旦你用这种方式思考，会发现表单不再是代码中最复杂、最容易出 bug 的部分，而是变成了一个可靠的、可扩展的、令人满意的用户交互系统。注册的输入字段用 ref 维护状态，只有当相关的验证或提交状态改变时，才会触发按钮的重新渲染。这样在表单规模变大时，不需要特殊的映射逻辑，就能自动处理所有复杂的字段结构。最核心的想法是：用 React ref 存储表单状态（不触发重新渲染），然后让每个字段只订阅它关心的状态片段。突然有一天，你打开那个"简单"的表单代码，发现它已经变成了你 React 项目中最复杂的地狱。

2026-01-26 20:40:47 556

原创请求批处理与缓存：为什么你的Web应用比想象中更慢？

GraphQL就是这个模式的标准实现——一个请求可以指定任意字段，服务器精确返回需要的数据，缓存在字段级别工作。五趟来回，每趟都要等门卫查一遍工作证（DNS查询）、排队进门（TCP连接建立）、报数说自己是谁（HTTP头信息）、等待管理员找东西（服务器处理）、拿着东西回来（响应解析）。看看微信、抖音的网络请求就知道了——用Network面板，你会发现请求数量少得可怜，但数据量反而很大。你有没有这样的疑惑？Service Worker是一个躲在浏览器里的"代理"，它可以拦截所有的网络请求，给你最高的控制权。

2026-01-25 18:05:49 646

原创为什么聪明的工程师都在用TypeScript写AI辅助代码？

2026年，AI编程工具已经不是"锦上添花"，而是"基础设施"。在这个背景下，TypeScript从"个人偏好"变成了"理性选择"。团队里有人坚持用JavaScript开发新项目，理由很硬气："我们用AI工具啊，代码自动生成，还需要什么类型系统？很多人听了上面的理由，就想把整个项目从JavaScript改成TypeScript，结果改到一半就放弃了。这种场景下，JavaScript的"动态性"就是一个优势。简单说，TypeScript是"长期投资"，JavaScript是"短期收益"。

2026-01-24 21:00:38 665

原创 Agent Skill到底是什么？一份写给开发者的技术本质科普

"我的项目用PostgreSQL，不要建议MongoDB" "我们所有图表都用D3.js，不要用Chart.js" "部署前一定要运行pulumi refresh""我能做什么"（Core Capabilities） "我应该怎么做"（How to Use） "什么时候最有用"（When to Use）有人说它是"AI工具的插件系统"。既然Agent Skill是"知识的通用容器"，你想到了什么可以编码成Skill的知识呢？Agent Skill代表了从"无状态AI助手"向"有状态知情伙伴"的进化。

2026-01-22 23:19:26 620

原创 Agent Skill真的能统一AI编码工具吗？一场被低估的标准化革命

它用Markdown写，而Markdown是跨平台的——任何支持Agent Skill Standard的工具，都能读懂同一份Markdown文件。比如，你说"我想追踪项目的决策"，而某个Skill的description里说"track decisions"，AI能够理解这两句话的语义相似，从而激活这个Skill。这意味着，即使哪天你想换工具，这些Skill都能带走。今天，我想从一个程序员的角度，拆解Agent Skill Standard到底在做什么，为什么它真的有可能改变我们的工作方式。

2026-01-21 22:50:01 724

原创流处理的内功修炼：Node.js Web Streams 真的值得学吗？

你是否遇到过这样的困境：读一个100MB的日志文件卡顿，处理用户上传的大视频内存爆炸，实时推送10万在线用户数据被挤爆？就像 HTTP/2 比 HTTP/1.1 更优但不是必须升级一样，Web Streams 比传统 Stream 更优雅但也不是强制要学的。：在 Node.js 用 Web Streams，在浏览器用 fetch/Response 的 stream 能力。如果你的数据很小（< 10MB），一次性加载反而快。关键是：当你遇到需要的场景时，别再被老方法的局限所困扰，有新的解决方案就在那里。

2026-01-20 20:46:21 594

原创直播带货、实时游戏、远程协作都在用它—WebRTC到底凭什么这么火？

从小的一对一通话，到大的实时游戏、直播互动、协同编辑，WebRTC的应用场景正在爆炸式增长。如果你在互联网大厂工作过，肯定听过这样的技术圆桌讨论："我们考虑用WebRTC做实时互动功能，但是NAT穿透这个坎太难了，不如上TURN服务器。本文就带你从源码级别理解WebRTC的核心机制，看看它如何通过SDP、ICE、DTLS这些听起来复杂的东西，在你的浏览器里实现真正的点对点通信。在我国，如果你做一个连接Symmetric NAT和严格防火墙的用户（比如校园网、公司网络），直连成功率会很低。

2026-01-19 20:33:32 615

原创 2026年了,你的聊天应用还在用轮询?深度拆解WebSocket、SSE和实时通信的前世今生

但问题是,当你的用户量从100涨到10万时,服务器每秒要处理5万次无意义的请求,云服务器账单能让你的老板想砍人。当我问他为什么不用WebSocket时,他理直气壮地说:"轮询简单啊,而且也能用!*注:WebSocket和SSE的"0次"指没有轮询请求,只有初始握手和实际消息传输。终于,你和快递员达成协议:"我们保持通话,你到了直接说话,我有事也能随时问你。想象你在等快递,你每隔2分钟就给快递员打一次电话:"到了吗?你学聪明了,给快递员打电话说:"我在这等着,到了你再挂电话告诉我。快递员松了口气:"行!

2026-01-18 12:08:33 621

原创 Promise.all和await有什么区别？为什么HTTP/2时代必须这样写Fetch？

去年我在做性能优化时,发现了一个令人震惊的现象:同样的代码,在HTTP/2环境下比HTTP/1.1快了3倍,但90%的开发者还在用老方法写Fetch。这就像你去麦当劳点餐,明明可以一次性说"我要汉堡、可乐、薯条",你却分三次排队,每次只点一样。你的代码可能还在用HTTP/1.1时代的思维写Fetch,而HTTP/2早已改变了游戏规则。这就像你去银行办业务,明明有5件事要办,却要排5次队,每次都要重新取号。从HTTP/1.1到HTTP/2,不仅是协议升级,更是。

2026-01-17 11:06:23 629

原创浏览器能直接写文件了！一文深入 File System Access API 的工作原理与实战应用

说起浏览器沙箱，它就像一个"监狱"——保护系统安全，但也限制了 Web 应用的能力。想象你有一个在线代码编辑器，用户辛苦写好了 50kb 的代码文件，关掉浏览器一切就烟消云散。这个 API 不仅打破了浏览器 30 年来的沙箱隔离，还通过精妙的权限设计在"能力"与"安全"之间找到了平衡。句柄就像一把"智能钥匙"，它代表了用户授予的对某个特定文件或目录的访问权限。有了这把钥匙，你可以：。它不仅让 Web 应用获得本地文件读写权限，还通过"用户主动授权"这个机制，在开放能力的同时守住了安全底线。

2026-01-15 21:57:35 630

原创 WebSocket vs SSE深度对比分析

最近我看到一个现象：很多开发者（特别是在有些大厂）在做实时通信时，往往选择WebSocket作为"万能方案"，结果反而用重了。这不是一个"选哪个都行"的问题——选错了，会直接影响你的应用性能、服务器成本，甚至用户体验。SSE就是"你们之间装了个单向的水管，水只能从服务器流向客户端"— 有没有用WebSocket做SSE的活儿的？

2026-01-14 23:31:27 627

原创你真的理解 File 和 Blob 吗？

如果用现实中的比喻，**Blob（Binary Large Object）就像一个"已经打好的包裹"**——它包含了原始的二进制数据，但对这份数据的来源、用途、名字都一无所知。掌握这两个 API 的细节差异，能让你用纯前端完成：大文件断点续传、客户端图片处理、完全离线的数据导出、甚至 P2P 文件传输。这是字节跳动、阿里云那样的平台常见的需求——用户点击"导出数据"，前端直接生成 CSV、JSON、甚至 PDF，File 和 Blob 的本质差异、内存管理的陷阱、以及在生产环境中真正的应用设计。

2026-01-13 21:47:47 679

原创 2026年React数据获取的第六层：从自己写缓存到用React Query——减少100行代码的秘诀

本篇是对前面所有内容的整合——我们用React Query将之前手写的所有复杂逻辑浓缩成几行代码。很多初级开发者被困在自己写缓存的泥沼里，而不知道React Query这样的库能简化90%的工作。React Query是数据同步层，让你的React应用自动和服务器保持同步，不用手写缓存逻辑。查询键决定了缓存的范围。这是React Query中最容易被误用的概念。第七部分：React Query vs 自己写的对比。React Query处理了所有的边界情况。第八部分：生产级的React Query配置。

2026-01-12 22:22:13 651

原创 2026年React数据获取的第五层：并发和缓存——让你的应用快到飞起

而且，仪表板开了一整天，这些数据被重复加载了100次，每次都是从服务器获取一样的数据。——并发控制和缓存策略。本篇涉及多并发请求控制和缓存——这两个是让应用从"可用"变成"好用"的最后一公里。这一篇，我们要解决的问题就是：如何并发加载多个请求，以及如何用缓存让应用快到飞起。第二部分：Promise.all vs Promise.allSettled。Promise.allSettled：等所有请求完成，再看结果。"仪表板加载太慢了，有时候需要等一秒。Promise.all：一个失败，全部失败。

2026-01-10 20:46:48 966