组件性能经验怎样变成团队规则React 性能问题往往不是缺少复盘而是复盘无法进入日常开发流程。一次分析若能沉淀为可检索的决策记录、测量方法和有边界的检查规则下一次评审才有依据可循。1. 让复盘能被再次使用很多团队在遇到严重性能问题后都会组织复盘会。大家坐在一起拆解 React DevTools 导出的 Profiler 图表最后在 Wiki 上留下一篇标题宏大的组件渲染调优总结。但这种复盘往往存在三个硬伤只有定性描述没有定量指标写着“避免了不必要的重新渲染”却没记录具体是哪几个 Props 变化引发的也没写优化前后的 Frame Rate (FPS) 变化。知识离散无法融入日常 Workflow文档保存在 Wiki 的某个角落工程师在 VS Code 里敲代码时根本不会主动去翻。缺少自动化拦截硬约束依赖工程师的自觉性去记忆“不要在 JSX 内部传匿名函数对象”只要新人一时疏忽坏代码立刻溜进主干。将经验转成可复用规则前先保留复现路径、基线、React 与浏览器版本以及优化的副作用。能稳定由 AST 判断的问题可以交给 ESLint需要业务语义的部分再作为代码审查提示。2. 知识增强型 React 渲染诊断与上下文编排架构我们把 React 渲染优化治理流程拆成三步故障诊断与 Profile 抓取 - 提取工程决策记录 (ADR) - 编排 AI 规则集并融入 CI/CD 拦截。这套流程让复盘记录与提交检查关联起来但规则需要定期回看避免把一次特定问题泛化成不适用的限制。3. React 状态切片示例下面的示例将状态放在外部 Store并通过选择器订阅。它适合确实存在跨组件高频更新、且 Profiler 已确认 Context 广播是原因的场景状态较少时普通 Context 往往更易维护。import React, { createContext, useContext, useRef, useSyncExternalStore, useCallback } from react; // 1. 定义高频变动的复杂 Context 状态结构 interface UserDashboardState { theme: light | dark; unreadNotifications: number; userProfile: { name: string; avatar: string }; } type Listener () void; // 2. 避免 Context 全量广播构建外部 Store 订阅机制 class StoreT { private state: T; private listeners: SetListener new Set(); constructor(initialState: T) { this.state initialState; } public get () this.state; public set (partial: PartialT | ((prev: T) PartialT)) { const nextState typeof partial function ? partial(this.state) : partial; this.state { ...this.state, ...nextState }; this.listeners.forEach((listener) listener()); }; public subscribe (listener: Listener) { this.listeners.add(listener); return () this.listeners.delete(listener); }; } const DashboardStoreContext createContextStoreUserDashboardState | null(null); export const DashboardProvider: React.FC{ children: React.ReactNode } ({ children }) { const storeRef useRef(new StoreUserDashboardState({ theme: dark, unreadNotifications: 0, userProfile: { name: 谭锐, avatar: /avatar.png } })); return ( React.createElement(DashboardStoreContext.Provider, { value: storeRef.current }, children) ); }; /** * 3. 智能 Context 细粒度 Selector Hook * 当 getSnapshot 返回值保持 Object.is 相等时组件不会因其他字段更新而重新渲染。 */ export function useDashboardSelectorK(selector: (state: UserDashboardState) K): K { const store useContext(DashboardStoreContext); if (!store) { throw new Error(useDashboardSelector 必须在 DashboardProvider 内部使用); } const getSnapshot useCallback(() selector(store.get()), [store, selector]); return useSyncExternalStore( store.subscribe, getSnapshot, getSnapshot ); } // --- 4. 消费组件示范只消费 unreadNotifications --- export const NotificationBadge: React.FC React.memo(() { // 当 unreadNotifications 未变化时theme 或 userProfile 的更新不会触发本组件重新渲染。 const unreadCount useDashboardSelector(state state.unreadNotifications); return ( React.createElement(div, { class: badge }, 未读通知: ${unreadCount}) ); });4. 可复制的项目复盘模板与 AI 规则映射当你在项目里完成一次类似的重构后请立即使用下面的ADR (Architecture Decision Record) 模板归档并将规则存入.ai-rules/react-render.md供智能审查 Agent 自动化提取。ADR 决策模板范例# ADR-20260821-01: React 顶层 Context 状态切片与选择器重构 ## 1. 现象与测量条件 - **现象**填写受影响路由、交互步骤以及 React DevTools Profiler 中观察到的提交记录。 - **基线**记录设备、浏览器、React 版本、采样次数和优化前后的提交耗时分位数。 ## 2. 根因剖析 - 顶层 GlobalProvider 中包含了 likeCount 与 userAvatar 等不相干状态。 - 未使用状态选择器子组件通过 useContext(GlobalContext) 触发无差别广播。 ## 3. 团队强制约束规则 (AI-CR 匹配准则) - **Rule 1**高频状态进入全局 Context 前说明订阅范围和测量依据。 - **Rule 2**当 Profiler 确认 Context 广播造成无关更新时评估状态拆分或选择器订阅。 - **Rule 3**向依赖引用稳定性的 memo 化子组件传入对象、数组或回调前检查是否会破坏 memo 的收益。把规则文件放在仓库中并在 PR 模板或审查提示中引用它。不要把“内联函数”设为一律禁止的规则只有子组件依赖引用稳定性、且测量显示这会造成问题时才值得改用稳定回调。5. 结语React 性能治理应从测量开始。把复现条件、结论和适用边界写入 ADR将确定性问题编成规则把需要判断的部分留给评审。规则能帮助团队减少重复试错也应随项目演进调整。