React

最近Code Review的时候，我看到我们组一个很聪明的年轻同事，用观察者模式，写了一个极其复杂的全局状态订阅系统，就为了在一个组件里，响应另一个不相关的组件的点击事件。 比较常见的场景：点击 Bu

每次我们团队开一个新项目，或者面试新同学时，总有一个问题会反复出现： 这个问题背后：能不能只用React全家桶，不引入任何第三方库，就搞定这一切？ 毕竟，Context是官方的，Redux太重，Zus

作为组长，我在Code Review里，最常跟新人强调的一句话就是：“不要忘了提交lock文件！ ” 为什么？因为lock文件是保证我们团队成员、测试环境、线上服务器，能安装完全一致的依赖版本的“契约

干了8年前端，有时候回头看，感觉就像看了一部浓缩的科技史。我刚入行那会儿，简历上写“精通jQuery”还是个很重要的加分项；而现在，面试时聊的都是React Hooks、Vue Composition

提到现代前端框架，比如React、Vue，你一定听过“虚拟DOM”（Virtual DOM）这个词。它被认为是提升性能的关键所在，是框架设计的核心思想之一。 但是，虚拟DOM到底是什么？它为什么能带来

我们都听过那个段子：每个程序员在接手一个老项目时，内心都会循环播放一句话：“这TM是谁写的破代码！” 然后，当他翻看git提交记录时，赫然发现既然是半年前的自己。 这个段子很真实。在日常开发中，我们常

不是说因为我们写得多牛，而是我们从第一天就立了 5 个基本工程约束，这些规则不是高深技术，而是**工程底线**。坚持这几个点，不一定能写出完美代码，但至少能避免那种“越写越乱、越维护越痛苦”的局面。

过去五年，我面试过不下 80 个前端应聘者，代码能力千差万别，但有一件事惊人一致： 不是 Angular、不是 Svelte、不是 Qwik、不是 Web Components，甚至连 WebGL、T

我不是第一次用 CSS Module，但这次是真的被坑麻了。 写这篇不是为了教你怎么用，而是想提醒一下——别轻信“模块化样式管理更高级”这种话，现实比你想象得复杂多了。 起因：领导说“咱们不要用 st

首先说下，我是真的试过开 concurrent 模式。 不是云试，是线上的业务真上过。然后被劝退了，半夜 2 点 rollback，连个背锅侠都没找着。 你问为啥没人敢用？不是大家不学，是你学了也用不

你写 Web 页面用 React，做桌面用 Electron + React，写原生应用用 React Native，做三维交互用 React Three Fiber，写状态管理要用 Redux，动画

01. 页面卡顿的问题到底出在哪？ 我们先抛开 Concurrent Mode，看一个大家都见过的 React 性能问题： 你输入一个字母，页面就卡顿 300ms，CPU 一直飙高。这并不是 Reac

在 React 的世界里，我们享受着组件化开发、声明式 UI、Hooks 的优雅设计。但当项目日益复杂，用户量暴增时，很多开发者会发现：明明用了 React 18，性能优化也做了，但页面依旧卡顿，交互

前言：90% 的性能问题，都不是代码写得不优雅，而是机制没理解透 很多人写 React 写了几年，一看项目性能拉垮就开骂“React 慢”、“虚拟 DOM 垃圾”。但其实问题大多数出在下面几个地方：

从 Redux 到 Zustand，从 React Context 到 React Server Component，前端开发者在过去五年中见证了一场「数据分发机制」的革命。如果说过去我们用 Redu