企业官网建设流程全解析

给组件写props默认值，在React里算得上最基础的技能之一。但如果你在部门里承担组件库维护的工作，很快会发现“属性默认值”远没有看起来那么单纯：明明给组件写了defaultProps，为什么上线后按钮的文案不按预期走？为什么React 19升级完，函数组件的默认值集体失效？为什么有人用||兜底，一传false就被吞掉？这篇是React系列第三篇，我把组件属性默认值从机制到实操完整拆一遍，希望你在自己的组件里写出更稳的默认值逻辑，也能在面试和代码评审里把这个问题讲透。

这篇文章适合三类人看：刚学React、准备搞清楚props细节的初学者；在写内部组件库、需要给公共组件设计可配置API的开发者；以及正在把老项目从React 17/18往新版本迁移的人。内容不绕弯子，该贴源码机制就贴源码机制，该给结论就给结论，你可以直接照着抄。

1. 属性默认值是用来解决什么问题的

1.1 调用方少写条件，组件内部少一次undefined判断

先想一个场景：你维护一个公共按钮组件，业务方有的地方想要大按钮，有的地方想要小按钮，但大部分地方不关心大小，直接用默认的普通尺寸就好。如果没有属性默认值，组件内部每次都要写：

const size = props.size || 'default';

这行代码写一次没感觉，写十个组件就有点蠢了。更关键的是，调用方也难受：为了保证组件正常显示，业务方得去翻文档，把size="default"补上，不然UI错乱。React提供defaultProps的初衷就是：让组件自己声明“你没传时我应该长什么样”，调用方只需要传关心的差异属性。

这就好比点外卖：商家把“默认不加辣”写在商品页里，你下单时不用每次备注“不要辣”，只有想吃辣的人才需要额外说一句。属性默认值就是React里的“默认不加辣”。

从代码角度说，默认值还顺带解决了渲染分支问题。没有默认值时，组件里经常出现这种防御代码：

const text = props.text ?? '确认';

如果默认值统一收口在组件入口处，业务逻辑里就不需要到处都是判空分支。这对可维护性的提升是实打实的，尤其是多人协作的组件库里，少一个??就少一次理解成本。

1.2 三种默认值实现方式，适用阶段不同

React生态里出现过三种主流的默认值写法，我按时间顺序排一下：

createClass时代的东西现在基本见不到了，但偶尔在古董项目里还能看到，理解它只是为了读老代码时不懵。真正要掌握的是后两种：class组件的defaultProps，以及函数组件的解构默认参数。

选择哪种，主要看你项目的代码风格和React版本。新项目基本都在写函数组件，那就直接上解构默认值；如果维护的是老式的class组件体系，defaultProps依然是最正规的做法。

2. 默认值触发的底层机制，很多人都搞错了

2.1 undefined才是默认值的唯一触发条件

我在带新人时常问一个问题：父组件传null，组件里的默认值会不会生效？十个人里有八个人会答“会，因为null就是没传”。这是整个React默认值机制里最重要的一个点：默认值只在属性值为undefined时才触发，null不会触发。

React在处理defaultProps时，逻辑可以简化成下面这段伪代码：

function prepareProps(type, rawProps) { const result = { ...rawProps }; const defaultProps = type.defaultProps; if (defaultProps) { for (const key in defaultProps) { if (result[key] === undefined) { result[key] = defaultProps[key]; } } } return result; }

注意这个循环里的判定条件：result[key] === undefined。它不是用!key这种真值判断，也不是用== null，而是严格等于undefined。这意味着：

• 子组件没写这个属性，读取时得到undefined，默认值生效；
• 子组件显式传了undefined，默认值依旧生效；
• 子组件显式传了null，默认值不生效，属性保持null。

为什么React要这么设计？因为undefined在JS语义里表示“未提供”，而null表示“主动给了个空值”。业务上这两个状态往往有完全不同的含义。比如一个头像组件的src，不传undefined说明用户没设置头像，组件展示占位图是合理的；传null可能意味着“用户明确要隐藏头像”，此时你强行换成占位图就错了。

如果你自己用{...defaultProps, ...props}这种方式去合并默认值，就会有一个隐藏bug：当父组件显式传size={undefined}时，展开运算符会把defaultProps里的默认值覆盖掉，得到undefined。React内部的逐属性判断逻辑不会犯这个错，这也说明为什么不要用对象展开来做默认值合并。

2.2 ||、??和解构默认值的边界差异

实际开发里，除了官方默认值机制，很多人习惯在组件内部手写兜底逻辑。我见过最多的是这三种：

// 方式一：逻辑或 const size = props.size || 'default'; // 方式二：空值合并 const size = props.size ?? 'default'; // 方式三：解构默认值 function Button({ size = 'default' }) {}

三种写法看着差不多，行为差别很大，尤其是||，堪称暗坑之王。||判断的是真值，只要左侧是0、''、false、NaN这些falsy值，右侧就会被选中。最典型的踩坑场景是布尔属性：组件默认按钮可点击，父组件传disabled={false}想禁用这个默认行为，结果false || true得到true，按钮反而变禁用了。这类bug定位起来特别费劲，因为代码语法完全没毛病，纯粹是语义被运算符扭曲了。

??（空值合并运算符）只针对null和undefined做兜底，看起来比||靠谱很多，但它仍然和React默认值机制有区别：React只兜undefined，??把null也一起兜了。所以，如果你明确知道父组件可能传null表示“清空这个属性”，用??就会破坏这个意图。

解构默认值则是在JS语言层面实现“仅当undefined时取默认值”的规则，这和React的defaultProps行为完全一致。这也是官方推荐函数组件优先用它的核心原因。三种方式的对照表放在第4.4节，排查问题可以直接当速查表用。

2.3 null与undefined，工程上的分水岭

很多业务开发不区分null和undefined，觉得“反正都是没有”，这种习惯在普通业务代码里也许问题不大，但放在组件默认值设计上就是明显的隐患。

举一个真实场景。我们内部有个输入框组件，value默认值是空串''。产品需求是“没有传value时，输入框展示占位提示，本身内容为空”。后来接口那边要支持“当服务端返回null时清空输入框”，前端拿到null直接塞给输入框，结果组件判断value不是undefined，默认值不生效，输入框里显示了个“null”。排查到最后，就是null和undefined语义混用的锅。

所以我建议，在组件设计阶段就把这两个状态的口径定清楚。我的习惯是：

undefined= 调用方未感知这个属性，组件用默认值兜底；null= 调用方主动传了空值，组件应尊重这个信号，不强行替换。

如果你接手的老组件里到处都用||兜底，先别急着重构，把“哪些属性必须允许数值0、空串和false”梳理出来，再逐个替换成解构默认值或??，否则很容易改出一堆新bug。

3. 实操：从老组件到新组件，默认值写法怎么演进

3.1 类组件里的defaultProps两种写法

class组件里写defaultProps有两种等价的姿势：类静态字段，以及外部赋值。下面这种static写法是现在的标准：

import React, { Component } from 'react'; import PropTypes from 'prop-types'; class Button extends Component { static defaultProps = { size: 'default', disabled: false, children: '确定' }; render() { const { size, disabled, children } = this.props; return ( <button className={`btn btn-${size}`} disabled={disabled}> {children} </button> ); } } Button.propTypes = { size: PropTypes.oneOf(['small', 'default', 'large']), disabled: PropTypes.bool }; export default Button;

如果你维护的项目构建配置还停留在更老的写法，也可以用外部赋值的等价形式：

class Button extends Component { render() { // ... } } Button.defaultProps = { size: 'default', disabled: false, children: '确定' };

这两种写法在React内部完全等价，static只是语法糖，最后都会变成构造函数上的静态属性。需要注意一个优先级：用户传入的props始终高于defaultProps。React合并的顺序是先填默认值，再覆盖用户传入值，所以不存在默认值把用户配置挤掉的可能。

配合prop-types做运行时校验时，defaultProps还能顺带减轻校验负担——因为默认值填充后，多数属性已经不是undefined，不会误触发“必填属性缺失”的警告。不过提醒一句：prop-types本身只是开发期工具，打包上线后不会做运行时校验，别把默认值逻辑建立在“propTypes能拦截错误传参”这个假设上。

3.2 函数组件推荐用ES6解构默认值

函数组件目前最推荐的写法，是在解构props的同时给默认值：

function Button({ size = 'default', disabled = false, children = '确定', ...rest }) { return ( <button className={`btn btn-${size}`} disabled={disabled} {...rest}> {children} </button> ); } export default Button;

这段代码里的...rest有一点容易忽略：解构掉已知属性后，剩余属性会被收集到rest里再展开到原生button上。如果忘了收rest，组件就吞掉了type、onClick、>function Pagination({ config = {} }) { const { pageNum = 1, pageSize = 10, total = 0 } = config; // 业务逻辑... }

这种嵌套默认值适用于“父组件传了一个对象，但对象只填了一部分字段”的场景。注意，如果父组件传的是config={null}，第一层解构默认值不会生效，后面读取config.pageNum会直接抛错。遇到这种不确定外部数据的情况，可以先处理一层null：

function Pagination({ config }) { const { pageNum = 1, pageSize = 10 } = config ?? {}; }

3.3 React 18.3警告和React 19移除：升级前要做什么

函数组件上的defaultProps最近几年一直处于“准备被淘汰”的状态：React 17里还能正常用，React 18.3开始会打出弃用警告，到React 19正式移除。

升级之后最直观的变化是：函数组件上定义的defaultProps完全不再生效。假设老代码是：

function Button(props) { return <button className={props.size}>{props.children}</button>; } Button.defaultProps = { size: 'default' };

在React 19里，父组件如果不传size，props.size就是undefined，页面样式直接崩掉。class组件不受影响，但现在新代码基本没人写class了，所以这个变化影响的覆盖面非常广。

我在迁移老项目时，给团队列的检查清单大致是这样的：

• 全代码库里搜索.defaultProps，逐个确认它挂的是class组件还是函数组件；
• 函数组件的defaultProps统一改成解构默认参数；
• 如果一个组件同时用了propTypes和defaultProps，改默认值写法后重新跑一遍类型检查和组件测试；
• 重点回归那些“曾经靠默认值才显示出正确文案”的组件，比如按钮文字、空状态占位符、分页每页条数。

对组件库作者来说，更稳妥的做法是直接对外声明“函数组件请传显式props”，内部再做一层兜底转换。但这是治标的过渡方案，长期还是要把组件源码切到新的默认值写法上。

3.4 高级场景：children备用内容、嵌套对象、半受控组件

默认值不只服务普通props，有几个高级用法很实用，建议在真实项目里演练一遍。

第一个是children的备用内容。某些展示型组件在没有children时，希望能渲染一个“默认插画”或“默认文案”。可以先判断一下children是否为空再取默认：

function EmptyState({ title = '暂无数据', children }) { return ( <div className="empty-state"> <h3>{title}</h3> {children ?? <p>你可以尝试刷新页面或调整筛选条件</p>} </div> ); }

这里如果用children || <p>...，当父组件传children={0}或children=""时也会被替换成默认内容，这就不合理了。用??严格处理“没传children”的情况更安全。

第二个是嵌套对象的默认值。很多组件接收一个config对象，里面一堆字段。如果config整体可能不传，可以先给config本身设默认对象，再解构内部字段：

function Chart({ config = {}, ...rest }) { const { showLegend = true, showTooltip = true, animationDuration = 300 } = config; // 组装图表... }

注意这样写时，如果父组件传config={{ showLegend: false }}，showLegend会正确保留false，不会因为falsy被吞掉。这正是解构默认值比||安全的地方。

第三个是半受控组件。有些组件允许业务方不传某个值，内部自己维护状态；一旦业务方传了，就切换到受控模式。比如一个可折叠面板，默认展开，但允许外部控制：

function Collapse({ defaultOpen = true, open, onToggle }) { const [innerOpen, setInnerOpen] = useState(defaultOpen); const isControlled = open !== undefined; const isOpen = isControlled ? open : innerOpen; const toggle = () => { if (isControlled) { onToggle?.(!isOpen); } else { setInnerOpen(!isOpen); } }; return ( <div className={isOpen ? 'collapse-open' : 'collapse-closed'}> <button onClick={toggle}>切换</button> </div> ); }

这里用open !== undefined判断是否受控，配合defaultOpen做非受控初始值，是两个默认值协同工作的典型写法。这种模式在很多组件库里都能看到，理解了默认值的触发条件，半受控组件的行为也就不会踩错了。

4. 常见问题排查与避坑实录

4.1 HOC直接调用组件函数，defaultProps不生效

有一种场景很隐蔽：自己写的高阶组件（HOC），在内部直接像普通函数一样调用子组件，而不是通过React.createElement或JSX渲染。比如：

function withLoading(Component) { return function WrappedComponent(props) { if (props.loading) { return <Loading />; } return Component(props); // 问题出在这 }; }

正常React渲染组件时，会先走元素创建流程，这个流程会读取Component.defaultProps并填充默认值。但Component(props)这种直接函数调用不会走这一步，于是所有默认值在这个HOC里全部失效，props就是原始传入的props，没传的属性全是undefined。

排查时最烦的是，脱离HOC单独用组件，一切正常；一旦套上HOC，文案就丢了。解决方式有两种：一是HOC内部改成JSX渲染，return <Component {...props} />；二是干脆放弃函数组件的defaultProps，改用解构默认值，这样即使被直接调用，默认值也是语言层面生效的。

如果你维护的组件库里有不少HOC，建议全局搜一下return [A-Z].*\(这种直接调用组件函数的地方，顺手改掉。

4.2 propTypes没安装，控制台刷一屏错误

React 15.5之后，PropTypes被移出了React核心包，现在需要单独安装：

npm install prop-types

很多老项目从React 16升级到React 17/18时，忘了同步装这个包，结果组件里用Button.propTypes = {...}的地方全变成运行时错误。更要命的是，这类错误通常只在开发环境打印，上线后静默消失，很容易被忽视。

我的建议是，新项目里尽量用TypeScript做类型约束，不用再依赖prop-types；但如果团队里还有大量老代码，至少把prop-types放进dependencies而不是devDependencies，防止CI构建时把开发依赖裁掉导致线上运行时挂掉。此外，配合defaultProps时，不要在propTypes里把有默认值的属性标成isRequired，这会造成“明明有默认值还报缺失”的乌龙。

4.3 TS环境下默认值的类型收敛问题

TypeScript项目和defaultProps的兼容性是老生常谈。最典型的痛点是：写在类静态字段上的defaultProps，无法自动影响props的类型推断。你明明定义了size = 'default'，但业务方使用组件时，IDE仍然提示size是可选属性。

函数组件用解构默认值就没有这个问题：

interface ButtonProps { size?: 'small' | 'default' | 'large'; disabled?: boolean; children?: React.ReactNode; } function Button({ size = 'default', disabled = false, children = '确定' }: ButtonProps) { return ( <button className={`btn btn-${size}`} disabled={disabled}> {children} </button> ); }

这里size的默认值字符串要写类型子集，TS就能在组件内部把size收窄成非可选类型。这样组件里后续的逻辑判断更干净，也能避免一堆不必要的可选链。

如果确实要在class组件里用defaultProps并享受类型收益，通常要额外定义Props类型的“默认值版本”：

type ButtonProps = { size?: 'small' | 'default' | 'large'; disabled?: boolean; }; type ButtonDefaultProps = { size: 'small' | 'default' | 'large'; disabled: boolean; }; class Button extends Component<ButtonProps> { static defaultProps: ButtonDefaultProps = { size: 'default', disabled: false }; }

这套写法能用，但成本偏高。新项目里我不会推荐。

4.4 传值行为速查表，排查问题直接抄

最后把各种“传值方式 + 兜底写法”的最终结果整理成一张表，方便你排查和评审时直接用。假设默认值是字符串'default'：

| 父组件传值 | defaultProps | 解构默认值 |props.size ?? 'default'|props.size || 'default'| | --- | --- | --- | --- | --- | | 不传 |'default'|'default'|'default'|'default'| |undefined|'default'|'default'|'default'|'default'| |null|null|null|'default'|'default'| |''|''|''|''|'default'| |0|0|0|0|'default'| |false|false|false|false|'default'| |'large'|'large'|'large'|'large'|'large'|

有几条快速记忆的结论：

• 上表中的||是重灾区，只要业务里允许属性值为0、空串、false，就坚决别用||做props兜底；
• 函数组件优先用解构默认值，行为和React官方defaultProps完全一致，还兼容React 19；
• 如果确实需要把null也当成“未设置”，用??，但要确认这样不会破坏“主动传null表示清空”的业务语义。

我个人在实际项目里的习惯是：组件API文档里明确区分“可选属性”和“可空属性”。可选属性用解构默认值，外部类型上标记为?:；可空属性允许null传入，组件内部自行决定是显示空态还是过滤掉。这样组件的契约边界非常清楚，大家调用时也少了很多互相猜的沟通成本。

最后再分享一个小技巧：给组件加默认值时，顺手在组件上方写一行注释，说明哪些属性是“业务敏感”的。比如disabled默认false这件事，如果业务方传false是被默认值机制忽略的，容易引发混淆，注释里点明一句“传false不会触发默认，传undefined才会”，后面维护的人能少走很多弯路。默认值这个东西，写对一次不难，难的是让团队所有人在同一条规则上理解它。