在学习JavaScript的过程中，我们不难发现一件事，类型判断在我们日常的开发中是最基础也最容易踩坑的知识点之一，我们有时会产生一些困惑

1. 明明被判断的那个数据是一个数组，但 typeof 却返回了 object

2. 使用 instanceof 判断基本类型时得到了一个 false

3. 不知道该用什么方法能够精准的判断一个值的类型

别急，本系列文章中我将带你重新复习一遍 JavaScript 中类型判断的各种方法，从 typeof 到 Object.prototype.toString.call()这些使用场景及底层实现原理，以及开发过程会遇到的难题，让你能够 回归基本功 ，再一次重新认识我们的老朋友 --JavaScript

一、学会类型判断首先我们来了解一下JS中的各种数据类型

1.1 基本类型（原始类型）

• string : 字符串类型，如： "hello world"
• number : 数字类型 "123" , "1.1"
• boolean : 布尔类型 ,true 或 false,
• undefined : 未定义类型，变量声明但为赋值时的类型
• null : 空类型，表示一个空对象指针
• symbol ：符号类型，表示唯一且不可变的值
• bigint: 大整数类型，用于表示超过 number 范围的整数

1.2 引用类型

• Object ：普通对象
• Array：数组对象
• Function：函数对象
• Date：日期对象

1.3 基本类型与引用类型的区别

• 基本类型存储在栈的内存中，值不可改变。
• 引用类型存储在堆内存中，变量存储的是指向堆内存的引用地址
• 基本类型的比较是值的比较，引用类型的比较是引用的比较

二、了解了各种数据类型后，让我们来了解一些常用的类型判断方法

js中的类型判断方法有：

1. typeof
2. instanceof
3. Object.prototype.toString.call()
4. constructor
5. Array.isArray

三、本篇文章着重要讲的就是 typeof 这一类型判断方法，typeof 是 JavaScript 中最基础的类型判断操作符，传入一个数据后，它会返回一个表示该传入数据类型的字符串。

typeof的工作原理

1. typeof 的判断基于 JavaScript 引擎内部的类型标签，每个值在内存中都有一个类型标签：

0: undefined

1: null

2: boolean

3: number

4: string

5: symbol

6: bigint

7: object

8: function

这就能解释为什么 typeof（null） "object" ,因为在js中，null的类型标签为 0 ，于是返回了"object" ,这是一个远古的 bug ，为了向后兼容一直保留至今没有进行修改

2. 什么时候选择使用typeof，为什么？

1. 对于基本类型进行判断时（null与array除外），如：string、number、boolean、undefined、symbol 或 bigint 类型时，优先使用 typeof。

原因：typeof 对这些基本类型的判断精准且可靠，语法简单，可读性高，且由于typeof 能直接访问 js 引擎内部的类型标签，是最快的类型判断方法

2. 当你需要判断一个值是否为函数类型时

原因： typeof 可以精确识别所有函数类型 ，包括普通函数，箭头函数，生成器函数，异步函数和类，相比于instanceof等其它判断方法，typeof 不需要考虑原型链的问题，且语法更简洁

3. 当你需要检查一个变量是否已经被声明，避免抛出 ReferenceError时

原因：typeof 是唯一可以安全检查未声明变量的方法，不会抛出 ReferenceError ，这是 typeof 独有的特性，是其它的类型判断方法都不具备的

4. 当遇到性能敏感的场景时，即需要进行频繁的类型判断且对性能要求高的时候时

原因：typeof 对这些基本类型的判断精准且可靠，语法简单，可读性高，且由于typeof 能直接访问 js 引擎内部的类型标签，是最快的类型判断方法

3. 什么时候我们不使用typeof ？

1. 当需要对 null 类型进行判断时

2. 当需要对不同类型的对象进行区分时

四、总结一下typeof该类型判断方法

1. 优先用于基本类型判断（除了null 以外）
2. 用于函数类型判断
3. 用于检查变量是否已经声明
4. 性能敏感场景时优先使用
5. 避免在对复杂对象类型判断时使用（优先使用 instanceof 或 Object.prototype.toString.call()）

我们为什么说组件通信是 React 的核心

1. React 这门框架的核心是组件化，任何一个完整的 React 应用，都是由多个独立组件协同工作构成的，组件之间的协同，其本质就是数据传递，共享与同步，这也就是我们常说的 组件通信
2. React严格遵循单向数据流原则：数据只能自上而下从父组件传递到子组件，状态的修改只能由持有该状态的组件完成。

在本文中，我将从基础到高阶再讲到一些特殊场景，来聊一聊 React 组件间通信的所有方案，可供新手入门及老手查缺补漏 （本文我所使用的技术栈为 React19 + 函数组件 + Hooks）

一、基础入门篇 父子组件间的通信 （为 React 中最常用的一种方式）

父子组件是 React 中最常见的组件关系，所有通信方式的底层逻辑，都基于父子通信的规则延伸而来

1.1 父向子传值

实现原理： 父组件直接在子组件的标签上绑定属性值，子组件通过参数props接受 ，此时该数据在子组件中仅为可读状态，不可修改，但该数据状态对象的属性值可以进行修改

代码实现：

若子组件直接修改父组件传递的状态对象，会报错

父向子传值的使用场景：

1. 适用于所有父子组件之间的数据传递，是 React 组件通信的第一选择
2. 当子组件的渲染内容完全由父组件决定时
3. 当需要父组件向子组件传递事件处理函数

父子组件传值注意点：

1. 禁止直接修改props，props是只读的，直接修改对象/数组类型的props，会破坏单向数据流，且不会触发组件重新渲染
2. 需要避免透传地狱：不要为了给孙组件传值，让中间所有层级的组件都接力传递props，后文我会讲解解决方案
3. 引用类型 props 注意重新渲染： 如果 props 传递的是对象/数组/函数，父组件每次重新渲染都会生成新的引用，导致子组件不必要的重新渲染，可以通过使用useMemo/useCallback优化

1.2 子向父传值 （通过回调函数使子组件与父组件同步）

实现原理：利用 props 可以传递函数的特点，父组件可以通过将状态修改函数把 props 传递给子组件，而子组件触发该函数并传入参数，可实现子组件向父组件同步数据，但其本质仍为单向数据流的延伸

代码实现：

----------------通过简单的子向父传值实现通过改变子组件来改变父组件的内容---------------

子向父传值的使用场景：

1. 当子组件需要向父组件传递事件触发信息时
2. 当子组件需要修改父组件的状态时
3. 当需要实现表单类子组件的输入值同步时

父子组件传值需要注意的点

1. 闭包陷阱：回调函数中如果依赖父组件的状态，则需要注意闭包问题，可通过 useCallback + 正确的依赖数组来解决 （具体解决方法将在后续更新文章中提到）

2.避免频繁触发回调：例如当使用onChange实时触发回调时，可能会导致父组件频繁重渲染，可以通过添加防抖来优化性能 3. 不要在子组件内修改回调函数的返回值： 为了保持单向数据流，请让子组件只负责触发回调，而不处理状态的修改逻辑，以便增加代码的可读性

1.3 父子直接通信：Ref 转发

实现原理：

1. 让子组件"打开后门"：使用 forwardRef 把父组件的 ref 传进来

2. 子组件"提供菜单"：用 useImperativeHandle 告诉父组件 ："你可以调用我的这几个方法"

3. 父组件"发号施令"： 通过 ref.current.方法名() 直接调用

代码实现：

让我通过实现点击父组件内的一个按钮，使得子组件内的输入框自动聚焦，并获得子组件输入框内的值这一功能来体现该方法的作用

父子直接通信的使用场景：

例如：

1. 在父组件里有一个按钮，点击后，想要直接命令子组件的输入框"自动聚焦"，或者让子组件里的弹窗"打开" 此时使用 props 便有些别扭 （此时父组件不需要给子组件传递数据，只是想"命令"它一下），此时便可使用 Ref + useImperativeHandle ，使父组件能够直接调用子组件内部的某些方法
2. 控制DOM元素的行为：如聚焦，播放视频，滚动到某个位置
3. 控制子组件的状态切换：如打开/关闭弹窗，展开/收起折叠面板

父子直接通信需要注意的点：

1. 尽量不用，优先使用props和回调函数
2. 若不使用 useImperativeHandle 则父组件能通过 ref 拿到子组件所有的东西，这是一个很危险的行为

结语

基于篇幅限制，本文需要让我们分为上中下上篇

传送门：让我带你迅速吃透React组件通信：从入门到精通（中篇）

传送门：让我带你迅速吃透React组件通信：从入门到精通（下篇）