aixiu

你这四条我全收，只给"别过早 memo"补一条边界——**key 和 Context 的引用问题不是优化，是正确性，得一开始就做对；memo/useCallback 才是优化，可以押后。**

顺着这个分界说几个具体坑。

拆 State/Dispatch 这个做法很对，但如果顺手上了 zustand，一定要配 selector。 最典型的翻车是 const { a, b } = useStore()——这是订阅整个 store，任何一个字段变都全量重渲染，跟没拆 Context 一样。得写 useStore(s => s.a)；selector 返回新对象时（s => ({a: s.a, b: s.b})）还得配浅比较，v5 用 useShallow。不写 selector 的 zustand 是负优化。

**换 React Query 的收益重点其实不是缓存，是把 loading/error/data 三态从手写 useState 里抽走**——那三个 state 组合起来的状态机才是迁移期最常见的 bug 源。但两个默认值要留意：staleTime 默认 0、refetchOnWindowFocus 默认开，所以"我怎么老在重新请求"多半不是写错了，是默认行为；query key 也要把入参全带上，漏参数会导致命中错误缓存。

<Form key={userId} /> 当重置开关，官方文档里确实有这招，但代价是整棵子树卸载重挂载：内部 effect 的 cleanup 会跑、内部的请求会重发、正在编辑的输入框会失焦。所以只适合"切换主体"这种低频场景，别拿高频变化的值当 key。

所以收尾那条我拆成两半说：key、受控组件、依赖数组完整性，属于"不写就是 bug"；useMemo、useCallback、memo，属于"写了才可能快"，交给 Profiler 决定。

按报错组织这个方向我完全同意，而且它比概念清单更该先做——搜报错的人有明确上下文，搜概念的人往往还没有问题。先给几条种子条目试试水（原文大意，版本间文案会变）：

• You're importing a component that needs useState... → 叶子文件漏了 'use client'，或它被一个客户端父组件反向 import 了 → 补指令，别往上挪。
• Functions cannot be passed directly to Client Components unless... → 往客户端组件 props 里塞了普通回调 → 改 'use server' 的 Server Action，或在客户端侧就地定义。
• Only plain objects and a few built-ins can be passed... → 传了类实例 / 带原型链的对象 → 换成纯对象，或拆字段传。
• Route "/x/[id]" used params.id. params should be awaited... → Next 15 的 async request API 漏 await → 补 await，在 generateMetadata 里也要补。

这里有个做表的方法问题：索引键别用整句报错。文案跨版本会改（React 和 Next 各自都会动），拿整句当 key 很快就过期。建议一条拆两栏——「关键短语」（如 needs useState、cannot be passed directly）+「完整原文」，短语稳定、原文给上下文，顺手还能当搜索别名。

codemod 扫不到的位置我补充几个，你那条基本齐了：generateStaticParams、generateViewport、opengraph-image.tsx 这类文件里的 params 同样是入参，另外 route handler 里如果是解构写法的 { params }，等号左右都得动。

「传进来的不会」那个前提我再收一句：不只是服务端上下文创建的元素——传进客户端组件后的那段 RSC payload，客户端侧只能渲染、不能再改它的 props 或遍历它的 element 树，想动结构得在服务端那一层做。这点在 review 里比「客户端/服务端」本身更容易被忽略。

建议每条再挂一个十行以内的最小复现，排查速度基本取决于这个，而不是描述写得多全。