aixiu

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

• `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 里比「客户端/服务端」本身更容易被忽略。

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