企业官网建设流程全解析

一、引言：为何关注 super 调用

1.1 React 类组件的构造函数背景

1. 在 React 开发中，类组件是通过 ES6 的 class 语法编写的，它必须继承自 React.Component。
2. 根据ES6 的语法规则，子类必须在 constructor 构造函数中调用 super 方法，否则在构造函数中使用 this 会报错。
3. 这是因为子类自己的 this 对象必须先通过父类的构造函数完成塑造，得到与父类同样的实例属性和方法，然后再对其进行加工，加上子类自己的实例属性和方法。

1.2 问题的提出：super()还是 super(props)

1. 在许多 React 教程和实际项目中，我们经常会看到两种写法：一种是只写 super()，另一种是传入参数 super(props)。
2. 这就引出了一个经典问题：在 React 中,superO和 super(props)有什么区别? (注: superO 通常为 super() 的输入笔误)。
3. 它们在功能表现上似乎都能让组件正常渲染，但在构造函数内部访问 this.props 时，行为却大相径庭。

二、核心剖析：super()与 super(props)的区别

2.1 语法层面的差异与 this 指向

1. 调用 super() 时，不传递任何参数，React.Component 的构造函数虽然执行了，但此时传入父类构造函数的 props 参数为 undefined。
2. 调用 super(props) 时，将组件的 props 属性传递给了父类的构造函数，此时父类构造函数内部可以正常接收到 props。
3. 只有在 super 执行之后，子类的 this 对象才算被完全初始化，之后才能在 constructor 中使用 this。

2.2 this.props 的可用性分析

1. 如果在 constructor 中调用了 super() 但没有传参，那么在 constructor 内部访问 this.props 会返回 undefined。
2. 如果调用了 super(props)，在 constructor 内部就可以直接通过 this.props 获取到外部传入的属性值。
3. 无论使用哪种方式，当 constructor 执行完毕后，React 内部机制都会将 props 挂载到 this 实例上，因此在 render 函数中 this.props 始终是可用的。

2.3 流程图：组件挂载与 props 初始化过程

1. 下面通过 mermaid 流程图展示 React 在实例化组件时，super 调用与 props 挂载的具体流程。

三、底层原理：React 源码中的 props 挂载机制

3.1 React.Component 的构造函数逻辑

1. 查看 React 的源码，你会发现 React.Component 基础类的构造函数非常简单，大致逻辑为function Component(props, context, updater) { this.props = props; this.context = context; }。
2. 当你在子类 constructor 中调用 super(props) 时，实际上就是显式地将 props 传递给了父类的构造函数，父类将 props 挂载到了 this 上。
3. 如果你不传 props，父类构造函数中的 this.props 就会被赋值为 undefined。

3.2 为什么外部不需要传 props 也能渲染

1. 尽管 super() 会导致 constructor 内部的 this.props 为 undefined，但组件依然能够正常渲染。
2. 这是因为 React 在实例化组件后，会在外部自动执行一个挂载操作，类似于instance.props = props。
3. 这就解释了为什么在 render 生命周期或其它自定义方法中，this.props 始终能获取到正确的值，而在 constructor 内部如果未传参则会缺失。

3.3 总结与最佳实践建议

1. 在 React 中,superO和 super(props)有什么区别? 答案在于 constructor 内部 this.props 的可用性。
2. 强烈建议在编写 React 类组件的 constructor 时，始终使用 super(props)，这样能避免构造函数内部因 this.props 未定义而引发的潜在 Bug。
3. 只有在构造函数中完全不依赖 this.props 的情况下，super() 才是安全的，但为了代码的一致性和可维护性，传递 props 是更佳的实践规范。