React 数据获取后的状态重置别靠巧合
前端页面一旦有异步数据流,状态重置就是迟早要面对的问题。筛选条件变了、数据源切了、详情页返回了,看似只是一次普通交互,但如果旧状态还残留在组件里,界面很容易表现出“偶现错乱”。
前端页面一旦有异步数据流,状态重置就是迟早要面对的问题。筛选条件变了、数据源切了、详情页返回了,看似只是一次普通交互,但如果旧状态还残留在组件里,界面很容易表现出“偶现错乱”。

React 18 上线后,不少项目第一次在开发环境里看到副作用执行两次,直觉都会觉得“框架是不是出问题了”。但我自己的经验是,StrictMode 暴露的往往不是框架 bug,而是我们本来就没处理好的副作用和初始化假设。
只要页面里有中大型列表,性能问题迟早会出现。很多人这时会本能地去加 memo、useMemo、useCallback,但我越来越觉得,真正决定列表是否好维护的,往往不是有没有做缓存,而是渲染边界有没有拆清楚。
React 18 的并发能力第一次接触时最容易让人兴奋,但真正写进业务后,我觉得最难的不是 startTransition 这个 API,而是你到底知不知道哪些更新应该立刻响应,哪些更新可以稍微“让一下”。
Vue3 推出 composable 之后,很多原本散落在组件里的逻辑终于有了更自然的抽离方式。但用得久了我越来越觉得,composable 最大的风险不是不好复用,而是“什么都想塞进去”,最后边界比 mixin 时代还模糊。
TypeScript 很容易给人一种安全感,好像只要类型定义得足够完整,系统就自然稳定了。但只要项目和接口、配置文件、第三方返回值发生交互,很多问题其实都发生在运行时,而不是编辑器里。
Vue3 上手一段时间后,很多人都会说一句“组合式 API 更自由了”。这句话没错,但自由的另一面是,响应式 bug 也更容易藏起来了。
2021 年如果还在做前端,几乎不可能绕开 Vue3。真正让大家开始认真讨论它的,不只是性能,而是组合式 API 终于给复杂页面的逻辑组织带来了一种更顺手的写法。