shadcn/ui 不发 npm 包、直接把组件源码装进你的仓库。聊聊这种 copy-in 模式的好处、维护成本、和传统组件库（Antd/MUI）的取舍。

用过一段时间 TanStack Router 后的复盘：文件式与代码式路由、search params 的类型校验、loader 数据预取，以及它和 React Router 的取舍。

记录把 React Compiler 接入一个真实项目的过程：它替我做了哪些手动 memo 化、哪些写法会让它直接放弃优化、以及上线前怎么验证它没改坏行为。

Context 混放状态会让一次输入拖着半个页面重渲染——问题不在 Context 本身，而在状态该放在哪一层、归谁管，拆分职责、区分 state 和 actions 才是根本解法。

表单值、字段状态、错误状态、流程状态混在一个对象里迟早会失控——拆开这四类状态，异步校验的竞态和多阶段提交才有地方安放。

把主题、语言这类值塞进依赖数组，会让连接跟着无关状态反复重建；useEffectEvent 把“同步条件”和“事件里读最新值”这两层拆开，比 useRef 的写法更直接。

评论接口耗时不稳定，手搓临时评论、失败回滚这些边角逻辑很快就绕不清楚——useOptimistic 把“用户看到的状态”和“服务端确认的状态”彻底拆开了。

React Server Components 语法不难，难在判断哪些组件该留在服务端、哪些交互必须下放到客户端，数据获取、缓存和错误处理都要跟着这条线重新划分。

把几十个字段都塞进一个 `useState` 对象，短期顺手，字段一多就会失控——字段状态、校验分层、联动逻辑和提交错误各自该放在表单架构的哪一层。

React 组件为什么会被牵连着重新渲染：状态边界怎么划、memo 和 useCallback 什么时候真的有用、长列表和 Profiler 排查该按什么顺序来，而不是页面一卡就到处加缓存。

Next.js 到底该在什么项目上用：纯中后台为什么大概率不划算、`'use client'` 边界怎么画、App Router 缓存分几层、以及静态生成和流式渲染在内容型站点里的实际取舍。

列表页的筛选条件到底该放在组件 state 还是 URL 里，判断标准很直接：能不能分享、刷新后要不要保留、需不需要被搜索引擎理解。梳理参数分类、URL 解析防御、push/replace 的选择，以及几个真实会踩的编码坑。

接口明明返回了新数据，页面却还是旧的——App Router 里叠着 Request Memoization、Data Cache、Full Route Cache、Router Cache 好几层，不分清楚各自的作用域和失效方式，只会越加 `no-store` 越乱。

手动维护 isSubmitting、error、formValues 这套状态组合，是表单代码变臃肿的根源。React 19 的 Actions、useActionState、useFormStatus 和 useOptimistic 把提交状态、乐观更新和错误处理从组件状态里拆出来，本文梳理具体的写法取舍和并发提交下的坑。

React Hydration 为什么要把整个组件重新执行一遍，Qwik 的 Resumability 又是怎么绕开这次重复执行的：从两者的底层机制差异，拆到 mismatch 排查和第三方脚本对主线程的争用。

组件从能复用到真好用，差的是抽象边界、受控状态和组合 API 的取舍。什么时候该抽、什么时候该忍住重复，业务表格越抽越大是最直接的反例。

Next.js 14 该不该跟，要看 Turbopack、Server Actions、部分预渲染背后 App Router 改变了哪些默认认知，而不是新特性列表。我们主用 Vue，这篇是隔壁生态的一次评估。

Hooks 难的不是记 API，而是理解闭包和依赖数组：请求重复发、按钮读到旧状态、effect 死循环，背后都是同一套渲染机制。这篇整理了我验证这几个问题时留下的笔记。

一个子组件抛错就能让整棵 React 树卸载、整页白屏。Error Boundary 怎么让错误只炸自己那一块、它捕获不到哪些错误、边界放在哪几层，以及 fallback 与错误上报该带什么。

同一份状态该进 store、进 URL 还是交给 React Query，判断依据是它的生命周期和归属，而不是写起来方不方便；这篇把 Zustand 的拆分、选择器、派生和持久化这几个取舍讲清楚。

服务端状态和本地状态是两回事：缓存新鲜度、mutation 后的失效范围、错误结构统一，这些 React Query 要解决的问题，手写 loading/data/error 很难兜住。