UI=f（state）

这个公式是react声明式编程的核心

它意味着UI是状态的纯函数映射

虚拟dom

核心工作流：

当组件状态发生变化时 react会启动Reconciliation（协调）过程其核心就是diff算法

触发更新：调用setState或者props变更 react知道需要更新
创建新树：根据最新状态在内存中创建一颗新的虚拟dom树
差异化比较：将新树与旧树进行diff
计算最小变更：diff算法找出两棵树之间的最小差异
批量更新真实dom：将所有差异打包一次性有针对性地应用到真实dom上

最核心的优势

避免不必要的DOM操作，只更新变化的部分
合并多次变更为一次有效减少浏览器的重排和重绘次数
保证流畅性即使在数据频繁更新的复杂场景中也能保持良好的响应速度

高阶组件 hooks

HOC高阶组件使用技巧


function(conponentA){
    return componentB
}
纯函数 没有副作用

抽离重复的代码实现组件的复用
条件渲染渲染拦截
拦截组件的生命周期

属性代理


function HOC(WrappedComponent){
    const newProps = {type:'hoc'}
    return props => <WrappedComponent {...props} {...newProps}/>
}

条件判断


function HOC(WrappedComponent){
    return props =>{
        props.isShow? WrappedComponent : <p>empty</p>
    }
}

反向继承


const HOC = (WrapperComponent)=>{
    return class extends WrapperComponent{
        render(){
            return super.render()
        }
    }
}

jsx 虚拟dom以及react编译原理

在 React 里渲染一个组件/元素，大体可以分三层：

JSX（语法糖）
虚拟 DOM 对象（JS 对象）
真实 DOM（浏览器 DOM）

流程是：

JSX → React.createElement → 虚拟 DOM 对象 → ReactDOM.render → 真实 DOM

jsx到虚拟dom的转化

JSX 不是浏览器能识别的原生语法，比如：


const element = <div className="box">Hello</div>;

编译后会变成：


const element = React.createElement(
  "div",
  { className: "box" },
  "Hello"
);

这里就用到了 React.createElement

它的核心作用是：

把 JSX 转换成一个虚拟 DOM 对象（JS 对象）

返回值不是 DOM 节点
是一个普通对象，形如：


{
  type: 'div',               // HTML 标签或组件
  props: { className: 'box', children: 'Hello' },
  key: null
}

这个对象就叫 虚拟 DOM
后续 React 会根据这个对象来更新真实 DOM

统一表示元素

不管是 HTML 标签还是组件
都用同一个 JS 对象格式表示

便于 Diff

React 后续 diff 对象，决定哪些 DOM 更新
不用每次直接操作真实 DOM，提升性能

支持递归嵌套

children 可以是数组或者其他虚拟 DOM 对象
React 可以统一管理整个树结构

ReactDOM.render 或 React 18 的 createRoot 才会：

拿到 React.createElement 返回的对象
遍历虚拟 DOM 树
调用浏览器 API（document.createElement）生成真实 DOM
挂载到页面上

总流程


// JSX
<div className="box">Hello</div>

编译后：


React.createElement("div", { className: "box" }, "Hello");

返回对象：


{
  type: 'div',
  props: { className: 'box', children: 'Hello' },
  key: null
}

ReactDOM.render：

遍历对象
创建真实 DOM
插入页面

手写creatElement


function createElement(type,props,...children){
    //核心逻辑不复杂 讲参数都塞到一个对象上返回就行
    //children也要放到props里 这样在组建里就能通过this.props.children拿到子元素
    return {
        type,
        props:{
            ...props,
            children
        },
         key: null                // 用于 diff
    }
}

手写render（）


ReactDOM.render(<APP/>,document.getElementById('root'))
 
function render(vDom,container){
    let dom;
    //检查当前节点是文本还是对象
	if(typeof vDom!=='object'){
		dom = document.createTextNode(vDom)
    }else{
        dom = document.createElement(vDom.type);//<p>
    }
    
    //将vDom上除了children外的属性都挂载到真正的dom上去
    if(vDom.props){
        Object.keys(vDom.props)
        .filter(key=>key!='children')
        .forEach(item=>{
            dom[item] = vDom.props[item];
        })
    }
    
    //如果还有子元素 递归调用
    if(vDom.props&& vDom.props.children&&vDom.props.children.length){
        vDom.props.children.forEach(child=>render(child,dom))
    }
    container.appendChild(dom)
}

Fiber是什么 —为什么需要Fiber

避免大组件树阻塞浏览器

支持用户交互实时响应

为后续异步渲染（Concurrent Mode）打基础

问题出在哪里

React 16 以前，更新是 同步的：


function App() {
  return (
    <div>
      <BigList />
      <Input />
    </div>
  );
}

假设 BigList 组件渲染上千个子节点
React 会一次性递归整个树生成虚拟 DOM
浏览器在这期间完全被阻塞
用户在输入框输入字符就会卡顿

这就是同步渲染的问题。

Fiber 的作用

拆分任务（Unit of Work）

React 会把组件树拆成 Fiber 节点，每个节点对应一个组件或 DOM 元素
更新变成一个 一个个小任务，而不是一次性跑完


App Fiber
 ├─ BigList Fiber
 │    ├─ Item1 Fiber
 │    ├─ Item2 Fiber
 │    ...
 └─ Input Fiber

每个 Fiber 都有 next 指针指向下一个 Fiber
React 执行时可以做 增量渲染
浏览器可以在两次 Fiber 执行间处理用户交互

可中断渲染

当浏览器有高优先级任务（比如用户输入、动画）时
React 可以暂停渲染 BigList 的 Fiber，先更新 Input

结果：输入框不卡顿，页面响应流畅

副作用标记（Effect Tag）

每个 Fiber 有一个 effectTag：
- Placement → 新增节点
- Update → 更新节点
- Deletion → 删除节点
React 可以把所有变化 收集起来再统一更新 DOM，避免多次操作 DOM 提升性能
以前：一次性搬运一整车砖块 → 房子盖不完就卡住
Fiber：一块一块搬砖，搬一块就让你呼吸一次 → UI 可以保持响应

总结

Fiber 是虚拟 DOM 的升级版，它：
1. 拆分任务 → 支持增量渲染
2. 标记副作用 → 精准更新 DOM
3. 支持优先级 → 高优先级任务可以先执行
4. 支持异步 / 可中断渲染 → 避免 UI 卡顿

什么是合成事件-与原生事件的区别

合成事件的特点

跨浏览器一致性：不同浏览器对事件的实现和处理方式各不相同 react封装了这些差异使得在所有浏览器中事件的行为是一致的。通过合成事件，react减少了因浏览器差异引起的问题
事件池化：react在合成事件对象的实现中采用了事件池化的策略这意味着当事件处理完成后 react会将事件对象重新放入池中而不是保留每个事件的实例从而减少内存开销事件池化的实现意味着事件对象的属性值只能在事件对象回调函数中访问 而在回调执行后属性会被清空
统一的接口：合成事件封装了标准的原生事件接口并提供了一致的API来访问事件的属性，如 event.target、event.stopPropagation()、event.preventDefault()等

区别：

浏览器的兼容性
事件池机制
性能优化考虑
事件委托

suspense use

react的严格模式解决了哪些潜在问题

过时的生命周期方法
副作用的检查

react的严格模式会在渲染过程中启用双重渲染这意味着组件的渲染和副作用函数会被执行两次以帮助开发者识别副作用问题在生产环境中 react只会渲染一次但在严格模式下 react会主动触发两次渲染来确保副作用函数是纯粹的不会影响后续的渲染过程
findDOMNode 推荐用ref来获取domnode
异步渲染问题
不稳定的context

函数式组件闭包问题

闭包本身没问题，只是函数捕获创建时的变量。
会出 bug 的条件：
- effect 内有“未来才执行的回调”（定时器、事件、Promise.then 等）
- 回调用到可能变化的 state/props
- effect 没有把这些变量写入依赖数组
安全场景：
- effect 内同步读取 state/props
- state/props 不会变化或你不关心更新
- 依赖数组可控（空也行）
判断口诀：

“回调会未来执行且用到会变的值，依赖没加，就有闭包 bug。”

说人话就是状态变化之后因为useEffect没加回调函数中的依赖所以useEffect没重新执行但是函数组件重新render了状态已经变化了但是因为useEffect没重新执行导致闭包捕获到的还是旧的状态会出现非预期的bug

函数式组件和类组件的区别

维度	类组件	函数组件（Hooks）
状态存储	存在组件实例上，通过 `this.state` 管理	每次 render 独立，状态通过 `useState`/`useReducer` hook 内部管理，形成闭包捕获
更新方式	`this.setState()`，会合并更新	`setState` 函数，完全替换状态，需要自己合并对象
生命周期	明确生命周期方法（componentDidMount、componentDidUpdate、componentWillUnmount 等）	通过 `useEffect`、`useLayoutEffect` 实现生命周期逻辑，统一处理副作用
this 指向	必须注意 `this` 指向	没有 `this`，闭包捕获当前 render 的状态，避免 this 混乱
逻辑组织	状态和副作用分散在生命周期方法里	hook 内聚逻辑，把状态、事件、副作用都聚在同一地方，更清晰
复用逻辑	高阶组件 HOC / Render Props	自定义 Hook，复用逻辑更自然，组合更方便
性能优化	`shouldComponentUpdate` / `PureComponent`	`React.memo` + `useCallback` / `useMemo`

合成事件

完整流程

用户点击按钮触发原生click事件
原生事件在DOM树中冒泡
React根节点的监听器捕获该事件
React从事件池中获取一个合成事件并且用原生事件的信息填充他
关键步骤：React模拟事件冒泡在组件树中逐级调用对应的事件处理函数
执行我们定义的事件处理函数如onclick
事件处理完毕事件对象被回收到事件池清空属性等待下一次使用

涉及到的两次冒泡

原生事件冒泡：在真实DOM树中从target到root ---被root节点的react监听器捕获分出事件对象同步事件信息
合成事件分发（模拟冒泡）：在虚拟组件树中从源组件到其所有父组件---执行事件的回调

总结

性能：通过在根节点进行事件委托 极大减少了在真实DOM上的监听器数量，优化了内存和性能

兼容性： SyntheticEvent（合成事件）作为核心对象磨平了浏览器差异提供了统一的稳定的W3C标准接口

事件池： SyntheticEvent对象被复用以提升性能导致不能在异步任务中直接访问事件如需持久化使用e.persist（）

受控组件和非受控组件

核心：表单的数据到底由谁管理

受控组件

— 在受控组件中表单元素的值由React的state完全控制 React state是表单数据的‘‘唯一来源’’

工作流程

组件state中存储着表单的当前值
state值通过value prop传递给表单元素
用户交互（如输入）触发onchange事件
onchange事件处理器更新组件的state
state更新导致组件重新渲染表单显示新值

优势：

即时验证与格式化—由于每次输入都会更新state 我们可以在onChange中轻松实现实时的数据校验格式化或者字符限制
条件化逻辑— 可以根据输入框的值动态地禁用提交按钮或显示提示信息
单一数据源 — 表单状态集中在组件的state中管理使得调试和状态追踪变得更清晰可预测

非受控组件

— 与受控组件相反非受控组件的表单数据由DOM自身管理

React不再直接控制表单元素的值而是使用ref来获取对DOM节点的直接引用

在需要时（例如表单提交时）拉取当前值

工作流程：

使用useRef创建一个引用
通过ref prop将其附加到DOM元素上
使用defaultValue设置初始值而不是value
在需要时通过ref.current.value读取值

优势：

代码更简洁—对于简单的表单无需为每个输入框都编写onChange和useState 代码量更少
更接近原生HTML—其工作方式与传统HTML表单类似学习成本较低
集成方便 — 在与一些直接操作DOM的第三方库集成时可能更方便
性能（理论上）— 避免了每次输入都出发React的重新渲染但在绝大部分应用中这点性能差异可以忽略不计

useState是异步的吗

结论：是“延迟处理” 而非异步

useState的更新机制可以总结为以下几点

同步提交，延迟执行：setState本身是同步的但他出发的状态更新和组件重渲染会被React延迟处理并进行批量合并
性能最优化：通过将多次状态更新合并为单次渲染避免不必要的计算和DOM操作最大化应用性能
状态一致性：保证在一次事件处理流程中所有状态修改能够同步生效防止出现不完整的中间ui状态提升应用健壮性

useState函数式更新和直接更新的区别

如果新的state依赖于旧的state 必须始终使用函数式更新


//计数器
setCount(prev=>prev+1)
//布尔值切换
setToggle(prev=>!prev)
//数组操作
setItems(prev=>[...prev,newItem])
//对象操作
setUser(prev=>{
    ...prev,
    name:'newName'
})

如果与旧的state完全无关可以直接传入新值


//表单输入
setName(e.target.value)
//重置状态
setCount(0)
//设置从api获取的数据
setData(Data)

结论：

函数式更新并非可有可无的语法糖而是react提供的强大工具用于编写更健壮、更可预测的组件