
12.8 Context 为什么全量重渲染
因为 Context 的订阅粒度是整个 value(而不是「value 里的某个字段」),且它的更新直接通知消费者、不经过 props 比较——所以 React.memo 也拦不住。

因为 Context 的订阅粒度是整个 value(而不是「value 里的某个字段」),且它的更新直接通知消费者、不经过 props 比较——所以 React.memo 也拦不住。

有用,但只在三个场景——「配合 React.memo 稳定 props 引用」「计算确实昂贵」「作为其它 Hook 的依赖」;其余情况是负担(比较依赖 + 保存缓存 + 维护成本),所以标准答案是「先测量,再优化」。

压缩、裁剪、加水印、抠图、拼接都在本地完成。不限张数、不限次数,图片不会传到服务器。

看「是否需要实时响应输入」——需要(实时校验、格式化、联动)就用受控;只需要「提交时的最终值」、字段很多、或集成非 React 控件就用非受控。

React 用三个假设——「只做同层比较」「type 不同直接重建」「用 key 标识同层元素」——把「树的最小编辑距离」的理论复杂度 O(n³) 降到了 O(n),代价是放弃「跨层复用」。

key 是 React 用来判断「新旧列表中的元素是否是同一个」的身份标识——它决定组件是「复用」(保留 DOM 与状态)还是「重建」(状态丢失);用 index 会在列表增删排序时造成状态错位。

两者唯一的区别是执行时机——useLayoutEffect 在「DOM 更新后、浏览器绘制前」同步执行(会阻塞绘制),useEffect 在「绘制后」异步执行;需要「测量 DOM 并立即修正以防闪烁」时用前者。

setState 的「调用」是同步的,「应用更新并重新渲染」是批处理延后的——所以事件处理里读不到新值;React 18 起所有场景都自动批处理(不再有「异步回调里同步渲染」的例外)。

因为 React 用「链表 + 调用顺序」把每个 Hook 的状态存起来——Hook 的身份由「第几次调用」决定,一旦顺序或数量变化,状态就会「张冠李戴」。
最新评论
读过书不知道欧·亨利的人少。教科书上选文有
这小生活不错呀
不错,必须顶一下!
看着你还在坚持,很好
看来忙了也没时间更新博客了
NIce。学习了。。。。
网站不错!!!!
简洁实用,好文章!