1. “caveman”不是项目名，而是React开发中一个被严重误用的性能陷阱代号

你可能在某个深夜调试 React 应用时，突然在控制台看到一行不起眼但令人困惑的 warning：Warning: React has detected a change in the order of Hooks called by caveman. This will lead to bugs and errors...。或者更常见的是，在 CodeSandbox 或团队代码评审中，有人随手写了个叫caveman的自定义 Hook，结果整个组件树开始随机崩溃、状态错乱、useMemo 缓存失效——而没人能立刻说清为什么。

这不是一个开源库，不是某个新框架，也不是某次技术大会发布的概念。“caveman”是 React 社区里自发形成的一个黑色幽默式术语，专指一类完全违背 React Hooks 规则、却因表面“能跑通”而被误传为“技巧”的反模式写法。它和token热词高频共现，并非偶然：当开发者试图绕过 token 刷新逻辑、硬编码凭证、或在条件分支中动态调用useMemo/useEffect以“优化”登录态管理时，“caveman”就悄然上线了。

这个词本身带着强烈的讽刺意味——就像原始人用石头砸开坚果，看似解决了问题（拿到了果仁），实则完全无视了杠杆原理、材料应力、能量守恒等底层规则。在 React 中，“caveman”式写法正是对Hooks 调用顺序一致性（Call Order Consistency）这一铁律的粗暴践踏。它不报错，直到你切换路由、触发重渲染、或在 CI 环境下跑测试时才突然爆发；它不警告，直到你把useMemo放进if语句里，让缓存键在不同渲染周期间跳变，导致画布（Canvas/Flowork）反复重绘、token 用量激增却毫无感知。

我第一次踩中这个坑，是在重构一个基于 React 的 AI 智能体前端时。为了“节省 token 请求次数”，我把useMemo包裹的 JWT 解析逻辑，放在了一个根据isAuthenticated状态动态决定是否执行的if块里。本地开发一切正常，直到 QA 同学在低网速模拟下连续点击登录按钮三次——UI 直接卡死，控制台爆满Invalid hook call。回溯发现，useMemo的调用位置在某些渲染路径中被跳过，导致后续所有 Hook 的序号全部偏移。这不是 bug，是设计层面的自杀式操作。

提示：“caveman”不是 React 官方术语，但它精准概括了一类高发、隐蔽、且后果严重的实践误区。它的存在，恰恰暴露了当前 React 开发中一个被严重低估的断层：大量开发者能熟练写出useState和useEffect，却对 Hooks 的编译时契约（Compile-time Contract）缺乏敬畏。而所有与 token 管理、登录态同步、权限校验强相关的场景，都是“caveman”最活跃的温床。

2. 为什么npx、useMemo和token会共同指向同一个底层故障点？

表面上看，npx是包管理命令，useMemo是性能优化 Hook，token是认证凭证——三者风马牛不相及。但当你把它们放进真实开发流水线，就会发现它们在执行时机、依赖确定性、以及错误传播路径上，形成了一个致命的三角闭环。这个闭环，正是“caveman”得以藏身并扩散的技术土壤。

2.1npx不是魔法棒，它是环境不确定性的放大器

很多团队习惯用npx create-react-app@5或npx playwright install初始化项目或安装工具。这看似便捷，实则埋下第一颗雷：npx默认从 npm registry 拉取最新版包，而不同版本的create-react-app对 React 版本、Babel 配置、甚至eslint-plugin-react-hooks的规则检查严格度，存在显著差异。

举个真实案例：某团队在 CI 流水线中执行npx @playwright/test@1.40 install，本地npm run test通过，CI 却报Cannot find module 'playwright-core'。排查发现，@playwright/test@1.40依赖的playwright-core子版本在npx拉取时被解析为1.40.3，而该版本存在一个已知的require路径解析 bug。更糟的是，这个 bug 只在特定 Node.js 版本（v18.17.0）下触发，而本地开发机是 v18.16.0。npx的“即用即弃”特性，让环境差异被无限放大。

当这种不确定性蔓延到 React 生态，问题就升级了。比如，eslint-plugin-react-hooks@4.6.0引入了对useMemo依赖数组的更严格静态分析，能捕获部分“caveman”写法；而@4.5.0则完全放行。如果你的package.json中写的是"eslint-plugin-react-hooks": "^4.5.0"，npx安装时可能拉到4.6.0，导致 CI 报错，而本地因缓存仍用4.5.0无感。此时，开发者第一反应不是修正代码，而是加// eslint-disable-next-line——这正是“caveman”思维的典型外化：用临时补丁掩盖底层规则缺失。

2.2useMemo是双刃剑，它的“缓存”本质常被误解为“条件执行开关”

useMemo的核心契约是：在依赖数组未变更时，返回上一次计算的缓存值；其执行时机与组件渲染强绑定，且必须在每次渲染中以相同顺序被调用。但大量开发者将其误读为：“我只在需要时才让它运行”。

典型反模式如下：

// ❌ CAVE-MAN CODE: 条件调用 useMemo function UserProfile({ userId }: { userId: string }) { const [isAuthenticated, setIsAuthenticated] = useState(false); // 错误：只有在登录后才调用 useMemo，破坏了调用顺序 if (isAuthenticated) { const userToken = useMemo(() => { return getTokenForUser(userId); // 假设这是个昂贵的 token 解析操作 }, [userId]); return <div>Welcome, {userToken?.name}</div>; } return <LoginButton onLogin={() => setIsAuthenticated(true)} />; }

这段代码的问题在于：首次渲染时isAuthenticated为false，useMemo根本没被调用；而用户登录后第二次渲染，useMemo才首次出现。React 的 Hooks 系统依赖于“每次渲染都按固定顺序调用相同数量的 Hooks”这一约定来维护内部状态映射。一旦顺序改变（如第一次调 2 个 Hook，第二次调 3 个），React 就无法正确关联useState、useEffect等后续 Hook 与它们对应的状态槽位，必然导致状态错乱。

更隐蔽的变体是“伪条件”：

// ❌ CAVE-MAN CODE: 依赖外部变量的 useMemo function DataDashboard() { const authContext = useAuth(); // 假设这是一个提供 token 的 Context const shouldFetch = authContext.token && authContext.userRole === 'admin'; // 错误：useMemo 的执行与否取决于 authContext.token 是否存在， // 但 authContext.token 的变化不会触发重新渲染？不，它会！ // 问题在于：当 token 从 null 变为有效字符串时，此 useMemo 首次执行； // 当 token 失效变为 null 时，此 useMemo 被跳过 —— 顺序再次破坏。 const expensiveData = useMemo(() => { return fetchAdminData(authContext.token); }, [authContext.token, authContext.userRole]); return <Chart data={expensiveData} />; }

这里useMemo的依赖数组看似合理，但fetchAdminData的执行本身是条件性的（因为authContext.token为空时函数体可能抛错或返回默认值）。关键在于：React 不关心你的函数体里写了什么逻辑，它只机械地检查你是否在每次渲染中都调用了useMemo。只要authContext.token的变化导致useMemo在某次渲染中被“跳过”，灾难就已注定。

2.3token是状态敏感性的终极压力测试场

token（尤其是 JWT）天生具备三个特性：时效性（TTL）、敏感性（需安全存储）、以及上下文强依赖性（不同 API 需不同 scope 的 token）。这使得任何与 token 相关的逻辑，都成为检验 React Hooks 规则遵守程度的“高压测试仪”。

• 时效性 → 频繁的重渲染触发：token 过期检测通常通过useEffect+setTimeout实现。若检测逻辑与useMemo混用不当，极易造成useEffect依赖数组遗漏token，导致过期后仍用旧 token 请求，返回 403；或过度监听，引发不必要的重渲染。
• 敏感性 → 复杂的条件分支：登录成功后要存 token、刷新 token、清除 token、同步到多个子系统（如 WebSocket、Analytics SDK）。每个分支都可能引入if/else，若其中嵌套 Hook 调用，就是“caveman”的温床。
• 上下文强依赖 → 多层嵌套的 Context 消费：useAuth()、useApiConfig()、useFeatureFlags()等自定义 Hook 层层嵌套，每一层都可能因父 Context 的value变化而重新执行。如果某一层内部偷偷做了条件 Hook 调用，错误会像多米诺骨牌一样向下传导。

网络热词中反复出现的token exchange failed: error sending request、token endpoint returned status 403 forbidden，表面是网络或权限问题，深层原因往往是：前端 token 管理逻辑因“caveman”写法导致状态错乱，发送了格式错误、过期、或根本不存在的 token 字符串给后端。后端收到一个null或空字符串，自然返回 403；而前端开发者还在日志里疯狂打印console.log(token)，却没意识到token变量本身在某些渲染周期中压根没被正确赋值。

注意：npx带来的环境不确定性、useMemo被误用的条件执行幻觉、token自身的高敏感性——这三者叠加，构成了“caveman”陷阱最肥沃的滋生土壤。解决它，不能只盯着某一个点，必须从 React 的底层执行模型出发，建立一套防御性开发范式。

3. 从React 面经到React 画布 Flowork：真实项目中“caveman”的七种典型现身形态

面试官问“React Hooks 的规则是什么”，你能背出两条；但当项目里出现一个React 画布 Flowork（类似 Figma 的可拖拽流程图编辑器），或一个需要实时 token 续签的AI 智能体控制台时，“caveman”就会以极其具体、难以复现的形态钻出来。以下是我过去三年在十几个中大型 React 项目中，亲手定位并修复的七种最高频“caveman”现身形态，每一种都附带可直接复现的最小代码片段、错误现象、以及根因深度拆解。

3.1 形态一：useMemo被塞进&&表达式，伪装成“短路求值”

代码片段：

// ❌ CAVE-MAN CODE: 利用 && 的短路特性隐藏 useMemo function TokenDisplay({ token }: { token: string | null }) { // 错误：当 token 为 null 时，整个表达式为 false，useMemo 不执行 const parsedToken = token && useMemo(() => parseJwt(token), [token]); return <div>{parsedToken?.exp ? new Date(parsedToken.exp * 1000).toLocaleString() : 'Invalid'}</div>; }

错误现象：组件首次渲染（token=null）正常；用户登录后token变为字符串，组件重渲染，控制台立即报Warning: React has detected a change in the order of Hooks called by TokenDisplay，且parsedToken为undefined，即使token已存在。

根因拆解：token && useMemo(...)是一个表达式，其值为false（当token为 falsy）或useMemo的返回值。但useMemo本身是一个 Hook 调用，它必须在每次渲染中无条件执行。此处，当token为null时，useMemo根本没有被 JavaScript 引擎执行，相当于这次渲染中少调用了一次 Hook。React 内部的 Hook 链表因此断裂。

正确解法：将条件判断移到useMemo的函数体内，确保 Hook 总是被调用：

// ✅ CORRECT: useMemo 总是执行，内部做条件判断 const parsedToken = useMemo(() => { if (!token) return null; return parseJwt(token); }, [token]);

3.2 形态二：useEffect里动态注册/注销事件监听器，却忘了清理逻辑的执行顺序

代码片段：

// ❌ CAVE-MAN CODE: 在 useEffect 中根据条件决定是否添加监听器 function WebSocketManager({ isConnected }: { isConnected: boolean }) { useEffect(() => { if (isConnected) { const handleMsg = () => console.log('msg'); window.addEventListener('message', handleMsg); // 错误：cleanup 函数只在 isConnected 为 true 时定义 return () => window.removeEventListener('message', handleMsg); } }, [isConnected]); return <div>WS Status: {isConnected ? 'Connected' : 'Disconnected'}</div>; }

错误现象：切换isConnected状态多次后，控制台出现Warning: An effect function must not return anything besides a function，且事件监听器泄漏，同一消息被处理多次。

根因拆解：useEffect的 cleanup 函数必须是一个函数，且必须在每次useEffect执行时都返回（即使返回undefined也算隐式返回undefined）。当isConnected为false时，useEffect回调体为空，没有return语句，因此返回undefined；当isConnected为true时，返回一个函数。这违反了“每次渲染返回相同类型值”的隐含契约，React 无法安全地执行 cleanup。

正确解法：始终返回一个函数，内部做条件判断：

// ✅ CORRECT: cleanup 函数总是存在 useEffect(() => { const handleMsg = () => console.log('msg'); if (isConnected) { window.addEventListener('message', handleMsg); } return () => { if (isConnected) { window.removeEventListener('message', handleMsg); } }; }, [isConnected]);

3.3 形态三：useCallback用于“记忆”一个条件创建的函数，却让依赖数组失效

代码片段：

// ❌ CAVE-MAN CODE: useCallback 的依赖数组漏掉了条件变量 function DataGrid({ rows, onRowClick }: { rows: any[]; onRowClick: (row: any) => void }) { const auth = useAuth(); // 错误：依赖数组只写了 [rows]，漏掉了 auth.token // 导致当 token 变化时，onRowClick 函数不会更新，仍用旧 token 发请求 const handleClick = useCallback((row) => { if (auth.token) { api.updateRow(row, auth.token); // 使用旧 token！ } }, [rows]); // ❌ 漏掉 auth.token return <Table rows={rows} onRowClick={handleClick} />; }

错误现象：用户登录后，点击表格行，API 请求失败，返回401 Unauthorized；但console.log(auth.token)显示 token 是有效的。

根因拆解：useCallback的目的是避免函数引用变化导致子组件不必要的重渲染。但它的核心价值在于保证函数的“行为”与依赖项一致。此处handleClick的行为（是否调用api.updateRow）直接依赖于auth.token，因此auth.token必须出现在依赖数组中。漏掉它，就制造了一个“幽灵依赖”（Ghost Dependency），函数体里的逻辑与依赖声明严重脱节。

正确解法：严格遵循“函数体中用到的所有响应式值，都必须出现在依赖数组中”原则：

// ✅ CORRECT: 依赖数组完整 const handleClick = useCallback((row) => { if (auth.token) { api.updateRow(row, auth.token); } }, [rows, auth.token]); // ✅ 包含 auth.token

3.4 形态四：在useMemo中调用setState，制造不可预测的状态更新链

代码片段：

// ❌ CAVE-MAN CODE: useMemo 中触发状态更新 function SearchBox({ query }: { query: string }) { const [suggestions, setSuggestions] = useState<string[]>([]); // 错误：useMemo 不是副作用的执行场所！ // 它的目的是返回一个值，而不是触发状态变更 const debouncedQuery = useMemo(() => { const timer = setTimeout(() => { if (query.length > 2) { fetchSuggestions(query).then(setSuggestions); // ❌ 在 useMemo 中 setState } }, 300); return () => clearTimeout(timer); }, [query]); // 错误：debouncedQuery 是一个函数，但这里把它当成了值使用 return <input value={query} onChange={(e) => {}} />; }

错误现象：输入框输入时，suggestions状态更新延迟、重复、甚至丢失；控制台频繁报Warning: Cannot update a component while rendering。

根因拆解：useMemo的执行时机是在 React 的“渲染阶段”（Render Phase），此时 React 正在计算 DOM 结构，绝对禁止在此阶段触发状态更新（setState）。这会导致 React 渲染器陷入混乱，因为它正在构建一棵树，而你却在中途修改了驱动这棵树的数据源。正确的副作用执行场所是useEffect（Commit Phase）。

正确解法：将副作用逻辑移至useEffect，利用useRef保存 debounce timer：

// ✅ CORRECT: 副作用在 useEffect 中执行 const [suggestions, setSuggestions] = useState<string[]>([]); const timerRef = useRef<NodeJS.Timeout | null>(null); useEffect(() => { if (query.length > 2) { if (timerRef.current) clearTimeout(timerRef.current); timerRef.current = setTimeout(() => { fetchSuggestions(query).then(setSuggestions); }, 300); } else { setSuggestions([]); } return () => { if (timerRef.current) clearTimeout(timerRef.current); }; }, [query]);

3.5 形态五：useContext返回的对象被解构后，再用于useMemo依赖，导致隐式依赖丢失

代码片段：

// ❌ CAVE-MAN CODE: 解构 useContext 返回值，破坏响应式追踪 const AuthContext = createContext<{ token: string; user: User } | null>(null); function ProfileCard() { const { token, user } = useContext(AuthContext); // ❌ 解构！ // 错误：useMemo 只监听 token 和 user 的“值”，但 React 无法追踪解构后的属性变化 // 如果 AuthContext.Provider 的 value 对象被全新创建（即使 token/user 值相同），useMemo 也会重新执行 const displayName = useMemo(() => { return user?.name || 'Guest'; }, [token, user]); // ❌ 依赖的是解构后的值，而非 context 对象本身 return <h1>{displayName}</h1>; }

错误现象：user.name没变，但只要AuthContext的value对象被重新创建（例如父组件重渲染），displayName就会重新计算，造成不必要的性能损耗；更糟的是，如果user对象是memo包裹的，解构会破坏其===相等性判断。

根因拆解：React 的依赖追踪是浅比较（shallow comparison）。useContext返回的是一个对象引用。当你解构const { token, user } = contextValue，你得到的是两个独立的变量，它们的值来自原对象的属性。useMemo的依赖数组[token, user]会分别比较这两个值的引用或值。但如果contextValue对象本身被替换（即使新对象的token和user属性值完全一样），token和user变量的值可能仍是相同的（对于基本类型），但对于对象user，其引用已变，导致useMemo误判为依赖变更。

正确解法：直接依赖useContext返回的整个对象，或使用useMemo对 context 值进行稳定化：

// ✅ CORRECT: 依赖整个 context 对象，或使用稳定化 const auth = useContext(AuthContext); // 方案A：直接依赖 auth 对象（推荐，简单直接） const displayName = useMemo(() => { return auth?.user?.name || 'Guest'; }, [auth]); // ✅ 依赖 auth 对象本身 // 方案B：在 Provider 层稳定化 value（更优，减少重渲染） // AuthProvider.tsx function AuthProvider({ children }) { const [authState, setAuthState] = useState(initialAuthState); const stableValue = useMemo(() => ({ ...authState, login: (creds) => { /* ... */ }, logout: () => { /* ... */ } }), [authState]); return <AuthContext.Provider value={stableValue}>{children}</AuthContext.Provider>; }

3.6 形态六：npx安装的eslint-plugin-react-hooks版本过低，对“caveman”零提示

现象描述：项目中存在大量形态一、二的代码，但eslint完全不报错，开发者以为代码“合规”。

根因拆解：eslint-plugin-react-hooks的exhaustive-deps规则在v4.0.0之后才开始对useMemo/useCallback的依赖数组进行更严格的静态分析；而v3.x版本对此类问题几乎不检查。npx安装时若未指定精确版本，极易拉取到过时的插件。

验证方法：在项目根目录执行npx eslint --version和npx eslint --print-config src/App.tsx | grep -A 10 "react-hooks"查看实际加载的插件版本和规则配置。

正确解法：在package.json中锁定插件版本，并启用严格规则：

{ "devDependencies": { "eslint-plugin-react-hooks": "^4.6.0" }, "eslintConfig": { "plugins": ["react-hooks"], "rules": { "react-hooks/exhaustive-deps": "error" } } }

3.7 形态七：React 画布 Flowork类应用中，useMemo被滥用为“节点状态缓存”，却忽略画布重绘的全局性

代码片段：

// ❌ CAVE-MAN CODE: 为每个节点单独 useMemo，导致画布状态碎片化 function FlowNode({ id, data }: { id: string; data: NodeData }) { // 错误：每个节点都独立 useMemo，但节点间的连接关系、全局 zoom level、 // 甚至 token 权限（影响节点可编辑性）都未纳入依赖 const nodeStyle = useMemo(() => { return computeNodeStyle(data.type, data.status); }, [data.type, data.status]); return <div style={nodeStyle} className="flow-node">{data.label}</div>; } // FlowCanvas.tsx function FlowCanvas({ nodes, edges }: { nodes: Node[]; edges: Edge[] }) { const [zoom, setZoom] = useState(1); const auth = useAuth(); // 错误：这里没有将 zoom 和 auth.token 传递给每个 FlowNode // 导致当 zoom 变化时，所有节点样式不更新；当 token 失效时，节点仍显示编辑控件 return ( <div className="canvas" style={{ transform: `scale(${zoom})` }}> {nodes.map(node => <FlowNode key={node.id} {...node} />)} </div> ); }

错误现象：画布缩放时，节点大小不变；用户登出后，画布上仍显示“删除”按钮，点击即报401。

根因拆解：FlowNode是一个高度复用的原子组件，其表现（样式、交互能力）不仅取决于自身data，更取决于全局画布状态（zoom）和应用级上下文（auth）。将useMemo的粒度限定在单个节点内，是一种典型的“只见树木不见森林”的局部优化，它割裂了组件与全局状态的响应式连接。

正确解法：将全局状态提升，由父组件统一计算并注入：

// ✅ CORRECT: 全局状态由 Canvas 统一管理 function FlowCanvas({ nodes, edges }: { nodes: Node[]; edges: Edge[] }) { const [zoom, setZoom] = useState(1); const auth = useAuth(); // 在 Canvas 层统一计算所有节点的最终样式和权限 const nodeProps = useMemo(() => { return nodes.map(node => ({ ...node, style: computeNodeStyle(node.data.type, node.data.status, zoom), isEditable: auth.token && auth.permissions.includes('edit_flow'), isDeletable: auth.token && auth.permissions.includes('delete_node') })); }, [nodes, zoom, auth.token, auth.permissions]); return ( <div className="canvas" style={{ transform: `scale(${zoom})` }}> {nodeProps.map(props => <FlowNode key={props.id} {...props} />)} </div> ); } // FlowNode.tsx: 简化为纯展示组件 function FlowNode({ id, data, style, isEditable, isDeletable }: NodeProps) { return ( <div style={style} className="flow-node"> {data.label} {isEditable && <EditIcon />} {isDeletable && <DeleteIcon />} </div> ); }

4. 构建“防 caveman”开发工作流：从npx初始化到React 面经的全链路防御

识别“caveman”只是第一步，真正的工程效能提升在于建立一套自动化、可审计、且融入日常开发节奏的防御性工作流。这套工作流不依赖开发者自觉，而是通过工具链、规范、和团队协作机制，让“caveman”式写法在诞生之初就被拦截。以下是我为多个团队落地的、经过生产环境验证的四层防御体系。

4.1 第一层防御：npx初始化即设防——定制化脚手架与预提交检查

npx的便利性是一把双刃剑。我们不能禁用它，但可以改造它，让它从源头就输出“防 caveman”基因。

方案：创建团队专属的npx初始化脚手架

不使用官方create-react-app，而是维护一个私有脚手架@our-team/create-react-app-pro。它在npx @our-team/create-react-app-pro my-app执行时，自动完成以下动作：

• 强制安装最新版eslint-plugin-react-hooks并启用strict模式：脚手架模板的.eslintrc.js中包含：

  module.exports = { plugins: ['react-hooks'], rules: { 'react-hooks/rules-of-hooks': 'error', 'react-hooks/exhaustive-deps': ['error', { additionalHooks: '(useMemo|useCallback)' }] } };

  注意additionalHooks选项，它将useMemo和useCallback也纳入exhaustive-deps的严格检查范围，这是官方默认不开启的。

• 内置useToken自定义 Hook 的标准实现：脚手架生成的src/hooks/useToken.ts文件，提供一个经过充分测试的、符合最佳实践的 token 管理 Hook：

  // src/hooks/useToken.ts import { useState, useEffect, useCallback } from 'react'; // ✅ 这是一个“防 caveman”的标准 token Hook export function useToken() { const [token, setToken] = useState<string | null>(null); const [isLoading, setIsLoading] = useState(true); const [error, setError] = useState<string | null>(null); // ✅ 所有逻辑都在 useEffect 中，无条件执行 useEffect(() => { const loadToken = async () => { try { setIsLoading(true); const storedToken = localStorage.getItem('auth_token'); if (storedToken) { // ✅ 验证 token 有效性，避免存储无效 token const isValid = validateJwt(storedToken); if (isValid) { setToken(storedToken); } else { localStorage.removeItem('auth_token'); setToken(null); } } } catch (err) { setError(err instanceof Error ? err.message : 'Unknown error'); } finally { setIsLoading(false); } }; loadToken(); }, []); // ✅ useCallback 确保函数引用稳定，依赖数组完整 const login = useCallback(async (credentials: Credentials) => { try { const newToken = await api.login(credentials); localStorage.setItem('auth_token', newToken); setToken(newToken); } catch (err) { throw err; } }, []); const logout = useCallback(() => { localStorage.removeItem('auth_token'); setToken(null); }, []); return { token, isLoading, error, login, logout }; }

• 集成pre-commit钩子，运行针对性 lint：脚手架自动安装husky和lint-staged，并在package.json中配置：

  "husky": { "hooks": { "pre-commit": "lint-staged" } }, "lint-staged": { "*.{js,jsx,ts,tsx}": [ "eslint --fix", "prettier --write" ] }

  更关键的是，eslint配置中增加一条专门针对“caveman”的检查规则（需自定义 ESLint 插件或使用eslint-plugin-react-perf）：

  // .eslintrc.js rules: { // ✅ 自定义规则：禁止在条件语句中调用 useMemo/useCallback/useEffect 'no-conditionally-called-hooks': 'error' }

效果：新成员npx初始化项目后，第一天写的代码就天然符合规范；git commit时，任何“caveman”苗头都会被pre-commit钩子当场拦截并提示修复。

4.2 第二层防御：React 面经升级为React 实战考卷——将防御知识转化为可测量的能力

面试中问“useMemo 和 useMemo 有什么区别”毫无意义。真正有效的是，让候选人现场解决一个真实的、嵌套了 token 管理和画布渲染的“caveman”问题。

方案：设计一套React 实战考卷，包含三个递进式题目

题目一：基础识别（15分钟）

给出一段包含useMemo和if语句的代码（形态一），要求候选人：

• 指出代码中的 Hooks 规则违反点；
• 解释为什么它会导致Invalid hook call；
• 写出修正后的代码。

题目二：场景诊断（25分钟）

给出一个简化版的Flowork画布组件（形态七），其中FlowNode组件存在useMemo依赖不全的问题。提供一个React DevTools的截图，显示在 zoom 变化后，节点样式未更新。

• 要求候选人分析问题根因；
• 修改FlowCanvas和FlowNode的代码，使其能响应 zoom 和 auth 状态变化；
• 解释为何将计算逻辑上提到父组件是更优解。

题目三：架构设计（30分钟）

设计一个useApi自定义 Hook，用于封装所有 API 请求，要求：

• 自动携带当前token；
• 在token过期时，自动触发刷新流程（refreshToken）；
• 刷新成功后，重试原请求；
• 刷新失败时，跳转到登录页。
• 关键约束：useApi必须 100% 符合 Hooks 规则，不能有任何条件 Hook 调用。

评估标准：不仅看代码是否“能跑”，更看重候选人是否能清晰阐述：

• 为何useEffect是处理 token 刷新副作用的唯一正确场所？
• 如何利用useRef来保存refreshPromise，避免竞态条件（race condition）？
• 为何useCallback必须将token和refreshToken都作为依赖？

效果：面试不再考察死记硬背，而是直接评估候选人能否在复杂业务场景中，本能地规避“caveman”。通过此考卷的候选人，入职后几乎零概率写出此类代码。

4.3 第三层防御：React 画布 Flowork的自动化健康检查——CI/CD 中的“caveman”扫描器

在 CI 流水线中，除了