claude-frontend-skilllisted

# 前端决策逻辑 这份规则描述的是在处理前端相关任务时的核心决策逻辑。前端开发的本质是状态与界面的同步问题，围绕这个本质展开的所有决策——组件如何划分、状态放在哪里、异步数据如何处理、性能如何保障——都有其内在的逻辑。理解这套逻辑能够让每一个前端决策都有坚实的依据，而不是靠直觉和习惯。 --- ## 一、状态是前端的核心 ### 1.1 前端的本质问题 现代前端应用解决的核心问题是：如何在应用状态发生变化时，高效且正确地将界面更新到对应的状态。所有的框架（React、Vue、Angular）都是对这个问题的不同解答，但解决的是同一个问题。 理解了这个本质，就能理解为什么状态管理是前端最难的部分，为什么组件划分问题最终都是状态归属问题，为什么性能问题通常是状态变化触发了不必要的重新渲染。 ### 1.2 状态的分类 前端应用中的状态可以分为四类，每类状态有不同的管理位置和策略。 服务器状态：从后端 API 获取的数据，比如用户列表、文章内容、订单记录。这类状态的特点是它的权威副本在服务端，前端持有的是一份缓存副本，需要处理加载、过期、重新获取、乐观更新等问题。 全局 UI 状态：在多个组件之间共享的界面状态，比如当前登录用户信息、主题设置、通知消息。这类状态需要在应用范围内共享，但与服务器数据无关。 局部 UI 状态：只属于某个组件及其子组件的状态，比如模态框是否打开、下拉菜单的展开状态、表单的校验状态。这类状态不需要跨组件共享。 表单状态：用户正在输入的值，包括输入内容、校验结果、提交状态。这类状态有其特殊的生命周期和处理模式。 ```mermaid flowchart TD A[遇到需要管��的状态] --> B{状态的来源} B -- 来自服务端 --> C[服务器状态\n使用专门的数据获取库管理] B -- 多组件共享的 UI 状态 --> D[全局 UI 状态\n存放在全局状态管理器] B -- 只属于单个组件树 --> E[局部 UI 状态\n存放在组件内部] B -- 用户表单输入 --> F[表单状态\n使用表单管理方案] C --> G[明确缓存策略和更新策略] D --> H[明确谁可以修改这个状态] E --> I[放在需要它的最低层级组件] F --> J[明确校验时机和提交流程] ``` ### 1.3 状态提升的决策规则 当决定一个状态应该放在哪个组件时，原则是：放在能访问到这个状态的最低层级的共同祖先组件。 如果一个状态只被一个组件使用，放在这个组件内部。如果一个状态被兄弟组件共享，提升到它们的父组件。如果一个状态需要在应用的很多地方使用，放入全局状态管理器。 过早提升状态到全局会导致全局状态管理器变得臃肿，降低组件的可复用性；过晚提升会导致 props 通过多层组件传递，使得中间的组件与它们不需要的数据产生耦合。 --- ## 二、组件设计决策 ### 2.1 组件划分的依据 组件划分不是按照 UI 的视觉区域来划分，而是按照状态和逻辑的归属来划分。一个组件应该是一个相对独立的状态和行为的封装单元。 实际的划分规则：如果一块 UI 有自己独立的状态（比如一个可展开折叠的面板），它应该是一个独立的组件。如果一块 UI 总是作为整体出现和消失，它可以是一个组件。如果一块 UI 在多个地方以相同的方式出现，它必须被提取为可复用的组件。如果一块 UI 的渲染逻辑已经复杂到难以理解，将它拆分为更小的组件。 ##