把大项目切得“揉烂又擀薄”：React 模块实战心法 别让组件长成一个“巨人” 见过忒多项目，组件做得比用户想象的大。一个导航栏组件可能占了整个页面的 20%，点击它还得负责跳转、加载、过滤、分页，就连联动刷新整个列表。
这就好比想写一本长篇小说，结局把每一章都写成了整本诗集，排版时手机一开屏就爆表。 实际上，React 最了得的地方不在于最复杂的组件有多能，而在于能不能把大系统切得充足碎，碎到能落在各种不同尺寸的屏幕和交互场景里。
要是一个个组件都试图解决所有难题，那它们就只是“大组件”。真正的技巧，是用一个个细小的切片，把一个大系统还原成一个个可复用的原子。 比如，我想做一个“商品详情页”。
不要搞一个几百行的组件，从父组件传一个 ID，子组件接收 ID 去查数据库，再渲染图片、标题、价格、地址。
这行代码不够看了，更别提维护成本。
不如拆成三个：一个渲染布局的“骨架”，一个带标题的“封面”，还有一个带具体信息的“详情”。 框架里的 `Props` 和 `State` 就是这些切片之间的接口。父组件传给子组件的信息，子组件自己处理，要是需求更新，就更新子组件的状态。
要是两个子组件之间不需求数据交互，那它们能够彻底不认识彼此，各自运行各自的逻辑。
这种“无状态协同”的本事，才是组件解耦的灵魂。 样式是死，逻辑是活 在习惯了 CSS 之前，我们总认定样式是万能的。但在现代开发中，样式和逻辑一旦混在一起，代码就会变得面目全非。
比如一个按钮，本来想让它在这个状态下高亮，那个状态下禁用，结局 CSS 里写了 `:hover`, `:active`, `:focus`，逻辑代码里又写了 `disabled` 和 `active` 状态。写起来挺爽，但维护时就像在泥潭里找路。 后来我发现，最好办的方案是把样式和逻辑彻底分开。一个组件只负责展示，另一个组件负责交互。
哪怕它们共用一个 `div`，只要 HTML 结构里的类名不一样，要么 CSS 里用了不同的变量，逻辑就彻底解耦。 比如，把“点击按钮”的逻辑抽到一个独立的 Button 组件里，这个组件里有 `onClick` 事件监听，也有 `disabled` 状态管理，还负责把文字变换成图标。主页面里呢，只要调用这个组件的方式，要么给它传个 props 让它显示，就再也不用关心它内部到底是如何跑的。 这种“脚本管住显示，样式管住外观”的模式，在移动端特别好用。屏幕小，想换个背景色，改几个 CSS 类名；想换个按钮颜色，改几个样式变量，不需求动逻辑。并且，这种拆分让组件更好办被复用。
比方说，一个通用的“输入框”组件，有毛病提示逻辑，有键盘事件响应，有焦点样式，只要把输入框的 ID 传出去就行。 自然，彻底把样式剥离出来，在初期可能会带来一点“样板代码”的费事。但在项目后期，这种“样式化组件”变得贼优雅。
特别是当样式从 CSS 变成了 CSS-in-JS 要么 Tailwind 这样的工具链时，组件就像乐高积木，颜色、形状、动画全体在逻辑代码里，样式彻底隐形。 状态管理的边界与逃逸 说到状态管理，大量人一上来就想到 Redux 要么 Context API。但在真正做模块化的时候，我常发现一个陷阱：状态管理本身不是要用来“管理”状态的，它是用来“张罗”状态的。 要是项目忒大，整个页面上下所有数据都放在一个 Context 里，那这就是个单点故障，也是个性能黑洞。一旦路由变了，要么一个弹窗弹开了，整个状态都重新计算，页面会卡顿。更好的做法是根据“边界”来隔离状态。 比如，一个“用户中心”模块，只负责管理用户登录、个人资料、订单历史这些模块。
要是这个模块想和“订单模块”对账，那就让它们通过 props 传递数据，要么通过一个全局的"UserStore"来协调。 另一个例子是“搜索功能”。用户搜索，输入框状态变了，搜索结局显示也要变。
要是搜一次，结局再搜一次，中间状态不益处理。
不如让一个“搜索组件”专门负责这个逻辑，它监听输入框的 `onFocus` 和 `onChange`，自动触发搜索，更新结局列表，就连更新分享按钮的状态。 这种“局部状态”的设计，能让组件的依赖关系更清楚。一个组件只管自己那一小块区域的逻辑，不会去管其他地方。
这就像是在大工厂里，每个车间只负责自己造一种产品，不需求和隔壁车间说我的产量都高了。 自然，要是务必跨模块共享状态，就得引入一个“根”概念。
比如建立一个 `AppStore`，里面存放全局配置、用户基础信息、核心数据流。其他模块通过 `useContext` 要么 `store.subscribe` 来获取它。但切记，这个 Store 不要试图覆盖所有组件，只覆盖那些需求全局数据的模块。 命名就是契约，动保就是保险 在模块化的世界里，命名规范就是代码的契约。随意起个名字 `fn1`, `btn2`, `compA`，哪位都能猜这是干嘛的，哪位都能改，哪位都能加逻辑，这代码就废了。 对的做法是给每个模块一个清楚的 ID，像 `UserDetails`, `ProductList`, `HeaderLayout` 这样。语义化的名字，让阅读者能一眼明白这组件负责啥。
比方说，看到 `onSubmit` 就知道这肯定是提交表单，看到 `onDelete` 就知道是删除操作。 动保（动静保）也是模块化的核心。
要是一个组件只是响应数据变化，那它就是“纯函数”要么“副功能函数”，它的输出彻底依赖输入。
要是它自己形成了副功能，比如修改了 DOM 结构，那它就是“组件”。 划重点：要是一个组件的逻辑只依赖于外部输入（比如 props），那它就是“输入型组件”。
要是一个组件除了接收输入，还会主动去操作 DOM（比如渲染动画、修改状态），那它就是“组件”。 这种分类直接拍板了组件的复用策略。输入型组件能够作为“原子库”里的根本单元，随时被替换；组件型组件则能够作为“功能模块”，被组合到更大的工作流里。 比如，一个“搜索过滤器”组件，它接收 `shopId`, `status`, `sort` 三个参数，然后基于这个快照计算哪些商品应当显示。
要是没传参数，它就显示默认数据。它不关心用户进去之后到底形成了啥，只关心数据变了它如何变。 这种设计让代码写得极度简洁。在父组件里写： ```jsx const filters = useMemo(() => { return filtersByProps(user, product, status); }, [user, product, status]); function SearchList() { return