Js-News

你有没有遇到过这种情况：Node.js服务器跑得越来越慢，用户抱怨页面卡顿，但你又不想大动干戈重写整个项目？ 别慌，我今天要分享一个"偷懒但有效"的优化方案——中间件重构。用这个方法，我的服务器性能直接提升了40%，而且代码还变得更清爽了。 什么是中间件？先搞清楚这个概念 简单来说，中间件就像是餐厅的传菜员。你点了一份菜（发起请求），厨房做好了（处理逻辑），但在菜端到你面前之前，传菜员要做很多事： 检查菜品是否完整（数据验证） 确认你的身份（用户认证） 记录这次服务（日志记录） 处理特殊要求（错误处理） 在Node.js里，中间件就是这些"传菜员"，在请求和最终响应之间处理各种任务。 如果你用过Express.js，那你肯定已经在用中间件了，只是可能没意识到而已。 问题出在哪？大多数人都犯的中间件错误 我之前的代码就像这样： // 每个路由都要跑一堆中间件 app.get('/users', logRequest, authCheck, loadUserData, getUsers); app.get('/products', logRequest, authCheck, loadUserData, fetchProducts); app.get('/public/info', logRequest, authCheck, loadUserData, getPublicInfo); 看出问题了吗？就像让每个顾客都要经过VIP包间的安检，即使他们只是去普通大厅吃个快餐。 这样做的结果： 冗余执行：相同的中间件在每个路由都要跑一遍 不必要的开销：public页面也要加载用户数据 调试噩梦：出了问题根本不知道是哪个环节卡住了 解决方案：分层中间件架构 我把中间件重新组织成了四层结构，就像机场安检一样： 全局中间件：所有人都要过的基础检查（解析请求、记录日志） 路由组中间件：特定区域的检查（比如只有国际航班才需要的额外安检） 上下文中间件：根据具体情况的检查（商务舱有专门通道） 处理器：最终的业务逻辑（登机） 具体实现起来是这样的： // 全局中间件 - 所有请求都需要 app.use(express.json()); app.use(logger); // 公开路由组 - 最简单的处理 const publicRouter = express.Router(); publicRouter.get('/info', getPublicInfo); publicRouter.get('/docs', getDocs); app.use('/public', publicRouter); // 私有路由组 - 需要认证 const privateRouter = express.Router(); privateRouter.use(authCheck); // 只有这个组需要认证 privateRouter.use(loadUserData); // 只有这个组需要用户数据 privateRouter.get('/profile', getUserProfile); privateRouter.get('/settings', getUserSettings); app.use('/private', privateRouter); 为什么这样做能快40%？ 减少不必要的中间件执行：公开页面不再需要加载用户数据，直接省掉了数据库查询 降低I/O瓶颈：把耗时的操作（比如数据库查询）推到真正需要的时候才执行 更好的缓存利用：相同类型的请求可以共享缓存，避免重复计算 就像高速公路的ETC通道一样，不同类型的车走不同的通道，整体通行效率自然就提高了。 我是怎么测量这40%提升的？ 数据不会撒谎，我用了这些工具： Apache Benchmark (ab)：模拟高并发请求 New Relic：实时性能监控 ...

JavaScript 字符串 substr() 已被废弃：为什么会踩坑？替代用法详解 想快速答案？结论是：不要再使用 substr()。它已被标准标记为弃用，未来存在移除风险；推荐统一使用 slice()（必要时再用 substring()）。 下面是详细解释与迁移清单。 那个90%前端还在踩的坑：substr()，一个早已被浏览器“拉黑”的API！ 你有没有经历过这样的场景：一段代码在你的电脑上跑得好好的，一上线就出了岔子？或者，你在维护一坨“上古代码”时，总感觉哪里不对劲，却又说不上来？ 小心，你可能踩中了一颗早已被埋下的“地雷”。而这颗雷的名字，很可能就是 substr()。 没错，就是那个我们用来截取字符串，熟练得像每天吃饭喝水一样的 substr()。可是一个残酷的事实是：这个API已经被现代浏览器标准给“拉黑”了。它就像一个过期的罐头，虽然暂时吃不坏肚子，但随时可能让你“中毒”。 更惊人的是，据不完全统计，可能还有90%的开发者在项目中无意识地使用它。 一场“家族内斗”：为什么 substr() 被踢出群聊？ 要理解 substr() 为何失宠，我们得认识一下它的两位兄弟：slice() 和 substring()。这三位都干着截取字符串的活儿，但脾气秉性却大不相同。 想象一下，String 是一个大家族，这三兄弟是家族里最擅长切分家产（字符串）的。 slice(起点, 终点) substring(起点, 终点) substr(起点, 长度) 发现问题了吗？ 老大 slice 和老二 substring 早就商量好了，切分家产的规矩是“从几号位置切到几号位置”，简单明了。 唯独老三 substr，天生“反骨”，非要自己搞一套：“从几号位置开始，数几个单位再下刀”。 这种不合群的设计，就是它被废弃的根本原因。这就像你开车导航，所有地图都告诉你“从人民广场开到世纪大道”，突然一个导航非要说“从人民广场出发，向东 5 公里”。在快节奏的编码中，这种思维模式的切换极易导致混乱和 bug。 代码不仅是给机器执行的，更是给人读的。这种不一致性，就是程序员世界的“万恶之源”。 王者之选：为什么 slice() 是你的最佳伴侣？ 既然 substr() 不推荐用了，那我们该用谁？首选，也是我的唯一推荐：slice()。 slice() 不仅严格遵守“起点-终点”的约定，它还有一个独门绝技——支持负数索引！ 这简直是神来之笔！想取字符串末尾的几个字符？在过去，你可能需要 str.substr(str.length - 4)，又臭又长。 现在用 slice() 呢？ const str = "你好，梦兽编程！"; // 想从后面取 4 个字？一个负数搞定！ str.slice(-4); // "编程！" // 从第 4 个字开始，切到倒数第 2 个字 str.slice(3, -1); // "梦兽编程" 看到没？slice() 的负数索引就像给你开了一扇后门，操作起来优雅又高效。它就像一个经验丰富、做事滴水不漏的专业人士，指令清晰，从不让你猜。 ...

LocalStorage 终极指南：5个致命陷阱，99%开发者踩过坑 嘿，各位前端战友们！ 提到 LocalStorage，你是不是觉得它就像个老实巴交的工具人？一个随叫随到、任劳任怨的浏览器仓库管理员？我们天天用它存点数据，感觉熟悉得就像左手摸右手。 但说真的，你这位“老朋友”，其实藏着不少秘密。它有些怪癖，有些“黑料”，你要是不知道，关键时刻它就能给你来个背刺，让你加班到夜深人静，对着电脑屏幕怀疑人生。 今天，我就来当一回“扒皮先锋”，揭露 LocalStorage 的 5 个惊天“黑料”，带你看看它不为人知的一面。 黑料一：它是个“路霸”，一人干活，全家罚站 你可能觉得 localStorage.setItem('key', 'value') 这行代码快如闪电，但真相是，它是个不折不扣的“路霸”！ LocalStorage 的所有操作都是同步的。这是什么概念？ 打个比方，你的代码是条繁华的单行道（浏览器的主线程），各种车辆（渲染、动画、用户交互）都在有序通行。突然，localStorage 这辆大卡车要停车卸货（读写数据）。它不管三七二十一，直接把路一横，大喊一声：“都别动，等我搞完！” 于是，整条路都堵死了。动画卡住了，页面点击没反应了，用户以为电脑死机了。虽然对于小数据，这个过程快到你感觉不到，但如果你尝试存入一个稍微大点的 JSON 字符串，那画面的卡顿感，绝对酸爽。 // 想象一下，如果这个 aBigObject 序列化后有几MB大 // 当执行这行代码时，你的页面可能会瞬间“冻结” try { localStorage.setItem('massiveData', JSON.stringify(aBigObject)); } catch (e) { console.error("哎呀，仓库满了，放不下了！", e); } 避坑指南： 别用它来存储需要频繁更新或体积庞大的数据。对于那些大家伙，请把它们交给异步的 IndexedDB 或者干脆交给后端。 黑料二：它是个“大嘴巴”，能跨窗口“隔空喊话” 你以为每个浏览器标签页都是一座孤岛？LocalStorage 告诉你：天真了！ 它其实是个隐藏的“情报大师”。当你在一个页面（比如 a.com/page1）修改了 localStorage，所有同源（也就是同一个网站 a.com 下）的其他页面，都能立刻收到“风声”。 这个“隔空喊话”的功能，是通过 storage 事件实现的。 // 在你的另一个同源标签页里监听 window.addEventListener('storage', (event) => { console.log('隔壁老王家好像有动静了！'); console.log(`键：${event.key}`); console.log(`旧值：${event.oldValue}`); console.log(`新值：${event.newValue}`); console.log(`搞事情的页面：${event.url}`); }); 这个特性酷毙了！你可以用它来实现多标签页之间的状态同步。比如，用户在一个页面登录后，其他打开的页面可以自动“刷新”成登录状态；在一个页面把商品加入购物车，其他页面的购物车图标也能实时更新。是不是瞬间感觉格局打开了？ 黑料三：它是个“偏食怪”，只吃字符串 这是新手最容易踩的坑，没有之一。LocalStorage 表面上看起来什么都能存，但它的胃口极其挑剔，只认一样东西——字符串。 你兴高采烈地丢给它一个对象： const user = { name: '梦兽编程', level: 99 }; localStorage.setItem('userInfo', user); 然后你去取： ...

HTML推测规则(Speculation Rules)实战：6行代码实现网页秒开效果 摘要：本文详细介绍HTML5推测规则(Speculation Rules)技术，通过6行HTML代码实现网页预加载和预渲染，显著提升网站加载速度90%以上。包含完整的Chrome 121+实现方案和跨浏览器兼容性解决方案。 你是否有过这样的体验？在某个网站上点击一个链接，页面“唰”地一下就出现了，没有丝毫的白屏和等待，仿佛不是在跳转，而是在进行“瞬间移动”。 你可能会以为那是什么复杂的单页应用（SPA）框架或者烧钱的服务器优化。但如果我告诉你，这种丝滑到令人发指的体验，可能仅仅是因为网站主在 <head> 标签里，悄悄放了 6 行看似平平无奇的 HTML 代码呢？ 这不是魔法，但胜似魔法。这背后，是 Chrome 浏览器正在推广的一项名为“推测规则（Speculation Rules）”的新技术。它就像是给你的网站配备了一位能够“读心”的超级管家，能预判用户的意图，并提前把一切准备就绪。 什么是HTML推测规则(Speculation Rules)？ HTML推测规则是HTML5的一项新特性，允许浏览器智能预加载和预渲染用户可能访问的页面。这项技术通过Chrome 121+版本实现，能够显著提升网站性能表现。 核心技术原理：推测规则如何工作？ 想象一下，你的网站就是一座宏伟的庄园，而用户就是来访的贵宾。在没有这位管家之前，贵宾想去哪个房间（页面），都得自己走到门口，推开门，等里面的灯亮起来（加载完成），才能看清房间内的景象。 现在，你把下面这段“咒语”放进了网站的“大脑”（<head>标签）： <script type="speculationrules"> { "prerender": [{ "where": { "href_matches": "/*" }, "eagerness": "moderate" }], "prefetch": [{ "where": { "href_matches": "/*" }, "eagerness": "moderate" }] } </script> 实战代码：6行HTML实现网页秒开 这段代码就是实现网页秒开的核心配置，支持prefetch预加载和prerender预渲染两种模式： 1. Prefetch预加载模式 作用机制：当用户鼠标悬停在链接上超过200毫秒时，浏览器会提前下载目标页面的HTML文档，但不执行任何脚本或样式渲染。 性能提升：可减少页面加载时间30-50%，特别适用于内容型网站和博客。 使用场景：新闻网站、博客、文档站点等以内容为主的页面。 2. Prerender预渲染模式 作用机制：不仅下载HTML文档，还会完全渲染整个页面，包括CSS样式执行、JavaScript脚本运行和图片资源加载。 性能提升：可实现零延迟页面跳转，用户体验接近原生应用。 使用场景：电商网站、Web应用、需要极致用户体验的场景。 配置说明：代码中的 "eagerness": "moderate" 参数设置了200毫秒的触发延迟，避免误触发造成资源浪费。 浏览器兼容性分析：Chrome 121+专属技术 支持情况： ✅ Chrome 121+: 完全支持推测规则API ✅ Edge 121+: 基于Chromium，完全支持 ❌ Firefox: 暂不支持，需使用polyfill方案 ❌ Safari: 暂不支持，需使用传统预加载 版本支持统计：目前全球约有65%的用户可以使用这项技术，主要集中在桌面端Chrome用户。 ...

*面试官：“你的代码怎么测试？” 我笑了…（然后就挂了） 💡 本文亮点：从零开始掌握JavaScript测试与调试，包含单元测试、集成测试、E2E测试实战案例，以及专业的调试技巧，助你在面试中脱颖而出！ 正文 “代码写完了？很好。那么，你该如何测试它？” 当面试官云淡风轻地抛出这个问题，你的大脑是否瞬间一片空白？你感觉自己明明实现了所有功能，逻辑天衣无缝，但就是无法证明它真的“天衣无缝”。这种感觉，就像一个绝世高手，却被问到“你的剑，锋利否？”而无法自证。 朋友，欢迎来到真实的世界。在这里，能跑起来的代码只是“能用”，而经过测试的代码，才叫“可靠”。今天，我将赐予你一套心法，让你彻底告别“代码能跑就行”的侥幸心理，成为一名让面试官和同事都充满信赖的专业开发者。 第一章：思想钢印 —— 为何你的代码必须被测试？ 很多新手认为，测试是多余的，是浪费时间。大错特错！测试不是功能的附属品，它本身就是产品质量的基石。 把它想象成一位顶级大厨。他会在菜品上桌前，自己先尝一下味道。这个“尝”，就是测试。 它能确保代码按你的剧本演出，而不是随性发挥。 它能防止你在修复一个 bug 时，悄悄制造出十个新 bug（这叫“回归测试”）。 它能让你在未来大刀阔斧地重构代码时，心中有底，脚下有根。 它构建的是一种信心，一种你对你亲手创造的代码的绝对信心。 面试官问你为何要测试，他不是想听你背诵概念，他是想看你的眼睛里，有没有对“工程质量”这四个字的敬畏之心。 第二章：神兵利器 —— 掌握你的测试军火库 测试不是一锅乱炖，它分层级，有章法。就像组装一台超级跑车，你得先保证每个螺丝钉都合格，再看引擎能否发动，最后才把整辆车开上赛道。 第一层：单元测试 (Unit Test) - 拧好每一颗螺丝 这是最基础、最核心的测试。它只关心最小的功能单元，比如一个独立的函数。它就像一个洁癖患者，把函数关在一个“小黑屋”里，隔绝所有外部依赖（比如数据库、API），只看它在给定的输入下，能否吐出预期的输出。 比如，我们有一个平平无奇的 sum 函数： // sum.js function sum(a, b) { return a + b; } module.exports = sum; 它的单元测试（用流行的 Jest 框架）会是这样，像一个简单的数学验证： // sum.test.js const sum = require('./sum'); test('测试1加2是否等于3', () => { // 这就是“断言”，我断定 sum(1, 2) 的结果“toBe”(是) 3 expect(sum(1, 2)).toBe(3); }); 第二层：集成测试 (Integration Test) - 启动引擎 当零件都合格了，我们得把它们组装起来，看看引擎、变速箱、电路系统能否协同工作。这就是集成测试。它测试的是多个单元模块组合在一起时的表现，比如你的业务逻辑调用数据库模块，或者前端请求后端 API。 第三层：端到端测试 (E2E Test) - 赛道狂飙 ...

React要凉了？硅谷CTO们正在偷偷跑路… 嘿，老铁们！今天咱们聊点劲爆的——那些硅谷大佬们最近都在偷偷摸摸干啥。 主角你肯定熟：React，前端界曾经的扛把子。当年多风光啊，组件化概念一出，直接封神，多少开发者跪着喊爸爸。 但最近风向变了。我混进24家独角兽公司的CTO群（别问怎么进的），发现这帮大佬们正在搞事情——他们居然在密谋"叛逃"React！ 有个喝多了的CTO跟我掏心窝子：“React不是不好，是太好了…好到让人窒息。” 啥意思？我给你翻译翻译这帮大佬的真心话： 1. 性能这事儿，真的顶不住了 虚拟DOM当年多牛逼啊，现在就成了拖油瓶。有个做SaaS的哥们跟我吐槽：“我们团队都是React老炮了，该优化的都优化了，但该卡还是卡。” 数据量大起来，React就像穿了棉袄跑步——看着挺壮，跑起来喘成狗。内存蹭蹭往上涨，用户体验？呵呵。 2. 写代码还是写仪式？ 还记得2016年的React吗？那时候多单纯，现在？呵呵。 一个做医疗App的CTO给我算了笔账：“我手下70%的时间不是在写业务代码，是在伺候React大爷。” 各种Hooks规则、状态管理、服务端渲染…学不完，根本学不完。新手进来直接懵逼：“我是来写代码的，不是来参加React科举考试的！” 3. 人才？贵到离谱 现在找个会写React组件的一抓一大把，但找个真的能hold住大型项目的？对不起，年薪百万起跳。 2018年，新手两周能干活。2022年？三个月起步。为啥？React变复杂了，学习曲线陡得跟珠穆朗玛峰似的。 4. 生态折腾死人 今天用Redux，明天用Zustand，后天又来个新的。每次技术更新都跟拆迁似的，重构重构再重构。 有个CTO跟我抱怨：“我们前端预算40%花在跟上React节奏上了，正经功能没做几个。” 5. node_modules：当代程序员的恐怖片 随便打开个React项目，node_modules文件夹能吓死人。几千个依赖，一个漏洞能搞崩整个项目。 安全团队看到这玩意儿直接原地升天。 那他们都跑哪儿去了？ 有趣的是，没有一家独大的新框架，反而是百花齐放： 有人直接裸奔：原生JS+小工具 返璞归真，不用框架，直接原生JS+点小工具。效果？某流媒体公司页面加载速度提升60%，转化率涨14%。 Svelte和Solid：编译时魔法 这俩货直接在编译时就把活干了，运行时轻得跟羽毛似的。某云公司用Svelte重构，开发时间砍半，性能起飞。 Astro：静态为主，动态点缀 大部分页面静态生成，需要交互的地方才用React。React从主角变配角，戏份少了，毛病也少了。 WebAssembly：直接上Rust 性能要求变态的场景，直接Rust+WebAssembly。某数据分析公司说效果"不是提升，是革命"。 最后说句人话 React不会死，但确实不再是唯一选择了。 它从"默认选项"变成了"工具箱里的一个工具"。大一统的时代结束了，现在是战国时代。 对我们开发者来说，这其实是好事。技术多样性，选择更多，不用在一棵树上吊死。 所以，你们团队还在用React吗？有没有感受到我说的这些痛点？评论区聊聊？ 关注我，带你围观技术圈的八卦现场！

我拿 Bun 和 Rust 干了一架，结果 Bun 的血条直接被打没了… 哥们儿，我跟你讲，在咱们程序员这圈儿里，总有那么几个话题能吵翻天。比如 “PHP是不是最好的语言？”，再比如，今天的主角：JavaScript的新贵Bun，和性能界的老炮儿Rust，到底谁更快？ 光说不练假把式。很多人都觉得，这还用问？肯定是Rust啊！ 没错，但我就特别好奇，这个“快”，到底是快一点点，还是快到离谱？所以，我搭了个擂台，让它俩正儿八经地干了一架。 结果嘛……这么说吧，场面一度非常“残忍”。 先介绍下两位选手 红方选手：Bun (配Elysia框架) 你可以把它想象成JS圈儿里现在最火的“小鲜肉”，人长得帅（开发体验好），功夫还很全（自带一堆工具），号称速度超快，拳打Node.js，脚踢Deno，是无数前端和全栈开发者的“新宠”。 蓝方选手：Rust (配Actix框架) 这位就不是小鲜肉了，这是性能界硬核得不能再硬核的“重量级拳王”。没啥花里胡哨的，主打一个稳、准、狠。它的字典里就没有“内存泄漏”和“性能妥协”这几个字，是系统级、底层开发领域的绝对霸主。 擂台规则：不服跑个分！ 为了公平，我给它俩安排了同一个任务：做一个URL短链服务。这活儿特能考验一个后端框架的真实水平，因为请求量一上来，谁在“裸泳”就一清二楚了。 测试环境是我的M4 MacBook Air，数据库用的是PostgreSQL。 我让10个、50个、甚至100个虚拟用户同时对着它俩疯狂发请求，看看谁先撑不住。 战况揭晓：这哪是比赛，这是单方面吊打啊！ 第一项，比“出拳速度”（吞吐量RPS） 简单说，就是一秒钟能处理多少个请求。 我跟你说，当100个用户一起上的时候，我看到数据都惊了： Bun/Elysia：14,295 RPS Rust/Actix：143,514 RPS 你没看错，小数点也没点错。Rust的出拳速度，是Bun的整整10倍！ Bun同学在旁边累得呼哧带喘，Rust大哥在那儿跟没事人一样，甚至还想点根烟。这血条，基本上算是被打空了。 第二项，比“反应速度”（延迟Latency） 这项更要命，它决定了你的用户体验顺不顺滑。 就好比，你点个按钮，Rust那边“唰”一下就响应了，P99延迟才11.97毫秒，你根本感觉不到。 Bun呢？在高压下就有点“反应迟钝”了，P99延迟干到了111.95毫秒。这个延迟，用户是能明显感觉到的，就像网突然卡了一下。对于追求丝滑体验的应用来说，这挺致命的。 所以呢？咱是不是以后就不用Bun了？ 别急着下结论！技术这东西，从来不是非黑即白。 Rust是快，快到变态。但这玩意儿的学习曲线也一样“变态”，想写好它，得掉不少头发。 这就好比你出门，去楼下便利店买瓶水，你肯定不会开一辆F1赛车去吧？虽然F1贼快，但你光是启动、热车、停车就得折腾半天，人家骑共享单车的哥们儿早都买完水回家打游戏了。 这次对决，真正告诉我们的是“看菜下饭”： 啥时候用Bun？ 当你需要快速把产品做出来的时候！搞个创业项目、做个MVP、快速迭代功能，Bun和它背后的整个JS生态，能让你爽到飞起。开发效率高，社区庞大，遇到问题分分钟就能找到解决方案。在绝大多数场景下，它的性能都绰绰有余。 啥时候必须上Rust？ 当你的项目是那种“公司命脉”级的核心业务时！比如交易系统、支付网关、或者任何预见到未来会有毁天灭地般流量的场景。这时候，你牺牲一点开发速度，换来的是极致的性能、铁一般的稳定性和晚上能睡得踏实的安心感。 总之一句话： 用Bun，图的是今天爽；用Rust，为的是明天稳。 想看更多这种用大白话聊技术的干货？来我这儿坐坐。 关注梦兽编程微信公众号，解锁更多黑科技。 原文参考：URL shortener service benchmarking: Bun (Elysia) vs Rust (Actix)