React.memo + useMemo 不能直接缓存函数本身，因为 React.memo 仅浅比较 props 引用，而函数每次渲染都会生成新实例；useMemo 缓存的是函数返回值而非函数本身，需用 useCallback 配合稳定依赖来缓存函数引用。
为什么 React.memo + useMemo 不能直接缓存函数本身
React.memo 只浅比较 props，而函数每次渲染都会生成新引用，导致子组件误判为“props 改变”，从而触发不必要重渲染。你写的 handleClick 或 getDerivedValue 即使逻辑不变，只要没手动缓存，就不是同一个函数实例。
常见错误现象：React.memo(Child) 包裹的组件仍频繁更新，控制台看到 useEffect 多次执行或 console.log 打印多次；用 React DevTools 的 Highlight Updates 功能会高亮该组件。
- 正确做法是：把函数定义在组件外部（全局/模块级），或用
useCallback包裹并稳定依赖项 - 若函数依赖 props/state，必须把所有参与计算的变量列进
useCallback的依赖数组，漏一个就会缓存失效或闭包 stale -
useCallback(fn, deps)本质是“带依赖的 memoized 函数”，不是魔法开关——deps 变，fn 实例就变
useMemo 缓存的是值，不是函数调用行为
很多人误以为 useMemo(() => heavyCalc(a, b), [a, b]) 是在“缓存函数”，其实它缓存的是函数执行后的返回值。如果 heavyCalc 有副作用（比如发请求、改 DOM），useMemo 不会阻止它执行——它只保证“相同依赖下返回同一值”，不控制执行时机或次数。
使用场景：适合缓存派生状态（如过滤后数组、格式化字符串、计算后的对象），不适合替代 useEffect 或封装副作用。
- 性能影响：过度使用
useMemo可能增加内存占用和比对开销，尤其当依赖项是大型对象时，浅比较成本上升 - 兼容性注意：服务端渲染（SSR）中，
useMemo返回值可能与客户端不一致，若依赖了window或document等客户端独有对象，会触发 hydration mismatch - 简单示例：
const filteredList = useMemo(() => list.filter(item => item.active), [list]);—— 这里缓存的是数组，不是filter调用本身
高频渲染下真正需要 memoize 的是纯计算函数（非 React Hook）
如果你有一组参数频繁变化、但计算逻辑昂贵的工具函数（比如坐标转换、正则匹配、树形结构扁平化），应该用独立的 memoization 工具函数，而不是靠 React Hook。React 的 useCallback/useMemo 是为协调渲染生命周期设计的，不是通用缓存方案。
容易踩的坑：直接在组件内写 const memoizedFn = memoize(fn)，但没处理好清理逻辑，导致闭包捕获过期 state；或者用第三方库（如 lodash.memoize）却没限制缓存容量，内存持续增长。
- 推荐轻量方案：
const memoizedParse = useCallback((str) => { /* 纯解析逻辑 */ }, [])—— 无依赖，函数实例永远稳定 - 带参数缓存：用
useMemo包一层工厂函数，例如：const getParser = useMemo(() => createParser(options), [options])，再在事件中调用getParser(input) - 复杂场景建议用
useRef+ 手动实现 LRU 缓存（如ref.current = ref.current || new Map()），可控性强，避免第三方依赖
useCallback 依赖数组为空数组时的陷阱
写 useCallback(fn, []) 看似稳妥，但如果 fn 内部读取了 props 或 state，就会捕获初始值，形成“stale closure”。高频渲染中这类 bug 极难定位，因为 UI 表现可能暂时正常，直到某次 state 更新后逻辑突然错乱。
典型错误现象：点击按钮始终提交旧表单数据、搜索框输入后筛选结果不更新、定时器回调里访问的 count 值卡在 1 不变。
- 解决思路分两种：要么把所有用到的变量加进依赖数组（哪怕导致函数重创建），要么改用
useRef同步最新值并在函数内读取ref.current - 不要为了“保持函数引用稳定”而牺牲正确性——React 设计哲学是“可预测的重渲染”优于“虚假的性能优化”
- 检查技巧：在
useCallback内部加console.log({ a, b })，看打印值是否随 state 更新而变化，就能快速验证闭包是否 stale
实际项目里最常被忽略的，是把“避免冗余计算”和“避免冗余渲染”混为一谈。前者靠函数级 memoization，后者靠 React 的引用稳定性机制——两者目标相似，但作用域、生命周期和失效条件完全不同。
