写 React 组件，大家天天都在跟 props 打交道，但有个细节我观察了很久：很多人写组件的时候根本不设属性默认值，等组件报错或者界面出现诡异的空白才开始排查。这问题说大不大，说小也不小，团队协作的时候尤其明显——你自己知道某个属性不传会怎样，别人可不一定知道。React 组件之属性默认值，就是帮你把“不传会怎样”这件事提前定义清楚，让组件在缺参数的时候也能体面地工作。这篇是系列第三篇，前两篇聊完组件基础之后，我打算把 props 体系里这个容易被轻视、但实际开发中坑特别多的点拆开讲透，包括类组件和函数组件各自的写法、默认值跟类型校验的配合、以及几个我踩过之后才知道的坑。
1. 属性默认值到底在解决什么问题
1.1 从一次线上事故说起
有段时间我做了一个列表组件，渲染用户头像和昵称。当时接口偶尔会缺nickname字段，组件里直接写了props.nickname.toUpperCase()，结果线上白屏。排查半天，原因很简单：后端某条数据的nickname是undefined。
事后我反思，如果组件声明了属性默认值，把nickname的默认值设为空字符串或者'匿名用户'，最坏情况也就是显示个兜底文案，绝不会白屏崩溃。这就是属性默认值最朴素的意义：在外部环境不完全可控的时候，组件自身先把底兜住。
从 React 的设计理念来看，props 是组件对外的契约，而默认值是这份契约的“补充条款”。调用方遵守契约传了值，组件就用传进来的值；调用方漏传、传了undefined，组件也不能撂挑子，得走默认值逻辑。这不是 React 独有的思想，函数默认参数、数据库字段默认值都是一回事，只是很多初学者写 React 的时候容易忽略这一层。
1.2 理解 props 传递链路再谈默认值
要理解默认值，先把 props 的完整链路在脑子里过一遍。父组件通过 JSX 属性向子组件传值，可以是静态的<Child name="张三" />，也可以是动态的<Child name={user.name} />。无论是哪种，到了子组件这里都被 React 收集成一个 props 对象。子组件内部读props.name，拿到的就是这个对象上的属性值。
这个链路里有一个关键点：父组件传undefined和不传属性，在子组件看来几乎是一回事。因为 JSX 编译之后，不传的属性不会出现在 props 对象里；传undefined虽然属性名在，但值依然是undefined。所以默认值机制要处理的，本质上就是props对象上某个属性缺失或值为undefined的情况。
这里要特意提醒一下，null不在默认值的覆盖范围内。也就是说，父组件如果传了name={null}，默认值不会生效，组件拿到的还是null。这个特性很重要，后面排查问题的时候会专门聊。
2. 类组件里 defaultProps 的用法与机制
2.1 最正统的声明方式
早期 React 开发以类组件为主时，defaultProps是官方提供的一等公民写法。它有两种声明位置，等价的：
class Button extends React.Component { static defaultProps = { color: 'blue', size: 'medium' }; render() { return <button className={`btn-${this.props.color} btn-${this.props.size}`}> {this.props.children} </button>; } }// 类声明之外挂载，老项目中更常见 class Button extends React.Component { render() { return <button className={`btn-${this.props.color} btn-${this.props.size}`}> {this.props.children} </button>; } } Button.defaultProps = { color: 'blue', size: 'medium' };两种方式效果完全一样，第二种属于“静态属性挂载”，在 Babel 转译和构建工具链不完善的时代更通用。现在项目基本都支持类静态属性语法了，直接在类里面写static defaultProps更内聚、可读性更好。
2.2 defaultProps 的生效时机
类组件的defaultProps有个非常微妙的机制：它作用于组件实例化阶段，在组件的构造函数执行之前，React 就已经把默认值合入 props 对象了。
这意味着两件事。
第一，constructor里访问this.props，拿到的已经是合并默认值之后的结果。写constructor(props)然后super(props)，接收到的props参数同样是合并后的完整对象。所以你可以放心在构造函数里直接使用this.props.color，不会读到undefined。
第二，render和其他生命周期方法里同样拿的是合并后的值。整个生命周期内，this.props始终是“传入值 + 默认值”合体后的状态。
但这里有个容易踩的坑：如果你在constructor里单独读某个属性，判断它“存不存在”来决定初始化逻辑，要注意默认值是否干扰了你的判断。比如：
constructor(props) { super(props); // props.color 永远是字符串，因为 defaultProps 兜底了 // 如果你想判断“用户有没有显式传 color”，是判断不出来的 }这个场景不多，但确实有人为了“判断是否传了属性”而在默认值上纠结。我的建议是，这种判断需求本身就说明设计有问题——你需要的是显式传值语义，可以在 props 里加一个isColorSet之类的布尔标志，而不是依赖某个属性的缺省状态。
2.3 与解构赋值的实际配合
类组件里大家很喜欢在 render 里用解构：
render() { const { color, size, children } = this.props; return <button className={`btn-${color} btn-${size}`}>{children}</button>; }配合defaultProps之后，解构出来的变量一定是有值的，不需要写color || 'blue'这种防御性代码。这也是defaultProps提升代码整洁度的一个直接体现——把防御逻辑收敛到声明处，而不是散落在使用处。
注意：类组件的
React.Component类型上并不强制要求定义defaultProps，它只是约定。但在团队协作中，强烈建议对外可复用组件都显式声明，否则调用方根本不知道该传什么、不传会怎样。
3. 函数组件的默认值设置，三种方案对比
3.1 函数组件的 defaultProps 与官方态度的转变
函数组件刚流行的时候，defaultProps同样适用，写法是这样：
function Avatar({ user }) { return <img src={user.avatar} alt={user.name} />; } Avatar.defaultProps = { user: { avatar: '/default-avatar.png', name: '匿名用户' } };这个写法一直可用，在 React 18 之前都没有问题。但后来官方逐渐释放信号：函数组件默认参数是更自然的做法。到了 React 18.3，函数组件使用defaultProps会出现警告提示，React 19 则明确不再支持函数组件的defaultProps。
原因其实不难理解。函数组件本质就是普通函数，JS 函数本身就有默认参数机制，在函数签名里做默认值处理是语言层面最直接的做法，没必要绕一层 React 的特殊 API。类组件的生命周期机制决定了它需要一个实例属性来存默认值，但函数组件每次调用都是独立的，直接在函数入口处处理就完了。
所以我的建议很简单：新代码里，函数组件统一用解构默认参数；老代码里如果还在用 defaultProps，尽早迁移。
3.2 解构默认参数的正确写法
这是目前函数组件最主流的写法：
function Avatar({ user = { avatar: '/default-avatar.png', name: '匿名用户' } }) { return <img src={user.avatar} alt={user.name} />; }注意，解构默认值只会在props对象上对应属性值为undefined时生效。父组件传了user={null}，这里拿到的依然是null，不会走到默认值。这个跟类组件defaultProps的行为一致。
还有一种更灵活的做法是，先解构出整个 props，再对需要的属性做二次默认值处理：
function Avatar(props) { const { user } = props; const finalUser = user ?? { avatar: '/default-avatar.png', name: '匿名用户' }; // 业务逻辑 }这里的??空值合并运算符把null也兜住了，跟解构默认值的行为不一样。如果需求确实是“null 也要兜底”，就该用这个方案。
3.3 单独暴露 props 的特殊场景
函数组件如果需要在内部读取完整的 props 对象（不是解构出来的单个属性），即props.foo这种访问方式，那解构默认参数帮不上忙，因为解构默认值只作用于局部变量。这种场景下，要么在函数体第一行手动合并：
function Avatar(props) { props = { user: { avatar: '/default-avatar.png', name: '匿名用户' }, ...props }; // 后面所有地方直接 props.user，安全 }要么直接用??运算符处理每个关键属性。说实话，我在实际项目中遇到过这种需求，通常发生在封装第三方组件的时候——第三方组件要求你必须传整个 props 对象进去。这种场景比较罕见，真遇到了，手动合并是通用解法，但要注意这会让 props 变成一个新对象，如果后续依赖引用相等性做优化，会带来额外影响。
4. 默认值与类型校验、TypeScript 的三方配合
4.1 PropTypes 校验下的默认值行为
如果项目里用prop-types做运行时校验，需要注意默认值和校验的执行顺序。React 官方文档里的规则是：propTypes 校验的是默认值合并之后的 props。也就是说，如果你定义了一个必填的propTypes，同时又给了defaultProps，校验时不会报错，因为默认值已经把属性补齐了。
来看一个实际例子：
Button.propTypes = { color: PropTypes.string.isRequired }; Button.defaultProps = { color: 'blue' };这段代码完全合法，不会因为isRequired而报警。因为 React 在内部先做了defaultProps合并，然后才跑propTypes校验。而有意思的是，如果调用方显式传了color={null}，那校验就会报错——null不是string类型，而且isRequired对null是敏感的（PropTypes.string本身对null会忽略，但.isRequired不会）。
这个顺序机制值得记住，因为它决定了你写校验规则时的思路：默认值只是“未传”的兜底，不是“传错”的屏障。缺参数交给默认值，类型错误交给 propTypes，两者各管一摊。
4.2 TypeScript 下的默认值陷阱
现在 TypeScript 基本是标配，但 TS 只知道静态类型，不知道运行时的默认值逻辑。所以有个坑特别常见：明明定义了默认值，TS 依然认为这个 props 是可选的，或者反过来说，接口里某个字段是必填的，但你明明给组件配了默认值。
defaultProps时代，类型声明通常这样写：
interface ButtonProps { color?: string; size?: 'small' | 'medium' | 'large'; } class Button extends React.Component<ButtonProps> { static defaultProps = { color: 'blue', size: 'medium' }; }因为接口里所有字段都是可选的，Button组件内部用this.props.color时 TS 的类型是string | undefined，虽然运行时不会真是undefined，但类型上它仍被认为是“可能不存在”。这意味着你不能直接调字符串方法，得先做空值判断或者断言，否则 TS 编译器会拦着你。这就是defaultProps在 TS 生态里的老毛病：运行时兜底和类型收窄是两码事。
有一个比较老的解决方案是给defaultProps声明完整类型：
static defaultProps: Pick<ButtonProps, 'color' | 'size'> = { color: 'blue', size: 'medium' };写了之后，React 的类型定义在某些版本里会把默认值信息推导出来，让this.props.color在组件内部推断为string而不是string | undefined。但这个行为依赖版本，React 18 之后越来越不稳定，官方也建议不要再让函数组件依赖这个机制。
新版函数组件的正确做法是用解构默认参数配合 TS 的类型推断：
interface AvatarProps { user?: { avatar: string; name: string }; } function Avatar({ user = { avatar: '/default-avatar.png', name: '匿名用户' } }: AvatarProps) { // user 在这里被推断为 { avatar: string; name: string } // （不是可选了，因为默认值已兜底） return <img src={user.avatar} alt={user.name} />; }这个方案写起来自然，类型也精准，推荐优先用。
5. 常见坑位与排查记录
5.1 空字符串和 0 不会被默认值兜底
这是最容易误判的一类问题。有人觉得props.count || 0是在做默认值，其实||会把空字符串、0、NaN 这些假值全部替换掉。而defaultProps或者解构默认值不是，它们只对undefined生效。
我举一个很典型的例子：
function Item({ count = 0 }) { return <span>{count}</span>; }如果调用方传<Item count={0} />，组件会显示 0，不会触发默认值。这个行为是符合预期的，但新手往往迷糊，会在组件里写count = count || 0，然后发现 count 传 0 时显示的是默认值 0（虽然数字一样）。如果你后续要区分“用户没传”和“用户传了0”，语义就乱了。
所以默认值的语义要想清楚：它只针对“缺失”，不对“假值”负责。如果需求是“任何假值都显示兜底文案”，那需要自己在函数体内做??或者||处理，不要寄托在默认值机制上。
5.2 null 进不来：默认值不背这个锅
前面提过两次了，这里展开说一下。默认值机制对null是透明的，不管是defaultProps还是解构默认参数。父组件写<Avatar user={null} />，子组件拿到的就是null。
这个行为导致的线上问题我见过不少：接口数据里某字段是null，后端没注意，前端组件以为有默认值兜底，结果页面渲染user.avatar直接报错。排查方向如果你是往“默认值为什么没生效”这个方向想，半天都定位不到——因为默认值确实生效了，问题是null根本不在它的管辖范围。
处理null的兜底，需要在函数体里主动处理，或者统一在数据层做清洗。我的经验是：后端子段可能为 null 的，尽量在 API 层就转成undefined或默认对象，别把脏数据传到组件层。组件层可以再用??兜一道，双保险。
5.3 React.memo 与函数组件 defaultProps 的冲突
函数组件配合React.memo做性能优化时，如果还用defaultProps，有一个比较隐蔽的问题。React.memo默认做浅比较，但它的比较不包含defaultProps合并的过程——memo比较的是父组件传入的 props 与上一次的 props，而defaultProps的合并是在子组件内部渲染时才发生的。
什么意思呢？假设这个组件：
function Avatar({ name = '匿名' }) {} const MemoAvatar = React.memo(Avatar);父组件渲染<MemoAvatar name="张三" />，第二次渲染还是<MemoAvatar name="张三" />，memo 浅比较发现 props 没变，不重新渲染，这没问题。但如果父组件第一次是<MemoAvatar name="张三" />，第二次完全不传属性即<MemoAvatar />，memo 比较的是{ name: '张三' }和{}，这俩不相等，会重新渲染——没问题。
真正的问题是，如果你用函数组件的defaultProps写默认值，React.memo 的性能收益在某些边界场景下会打折扣，因为defaultProps的合并发生在 memo 判断之后。React 18.3 已经明确告警，React 19 直接移除了函数组件defaultProps。如果你维护老代码，见到类似 warning，最佳方案就是迁移到解构默认参数。
5.4 对象和数组默认值的引用问题
类组件的defaultProps里如果定义了对象类型的默认值，比如：
static defaultProps = { config: { theme: 'dark' } };这个config对象在每个实例里是同一个引用。组件 A 如果内部修改了this.props.config.theme，组件 B 拿到的默认值也会被改掉。因为defaultProps是类级别的静态属性，不在实例上复制。
旧版 React 时代这个坑非常高发，有人因此把整个组件的状态改乱了。函数组件用解构默认参数也有类似风险：
function Panel({ config = defaultConfig }) {}如果defaultConfig是模块级别的对象，每次缺省时都引用同一个对象。组件内部如果把它当作本地状态直接改，第二次渲染时看到的可能已经不是原始默认值了。
我的建议是：默认值尽量用基本类型，或者默认值本身设计成不可变对象；确实需要对象类型默认值时，在组件内做一次浅拷贝再处理。这样虽然多了一点点开销，但能避免一大类“莫名其妙的数据串扰”问题。
5.5 迁移注意：解构默认值不能完全等同 defaultProps
虽然推荐函数组件用解构默认参数，但要清楚两者有一个细微差别：defaultProps对于整个 props 对象的每个字段都生效，而解构默认参数只针对你解构出来的那一个字段生效。这本来不算问题，但在跟React.memo、第三方封装库协作时，可能会有感知差异。
举个实际例子。假设你封装一个基础组件，内部透传...props给底层元素。类组件的defaultProps会在透传前把所有缺省字段补齐，所以底层元素拿到的是完整属性；函数组件用解构默认参数的话，缺省字段只是在局部变量层面被补上，如果你直接透传props，底层元素拿到的还是缺字段的原始对象。
function BaseButton({ color = 'blue', ...rest }) { // rest 里没有被补上 color，因为 color 只是局部变量 // 如果要透传，需要手动合并 return <button {...rest} color={color} />; }这种情况建议在函数体里重新组合 props，别偷懒直接透传旧对象。
6. 实战建议：默认值应该怎么定
聊完机制和坑，给出我实际干活时的几条经验。
第一，对外复用组件默认值一定要写在显眼位置。类组件放在defaultProps静态区，函数组件放在函数签名解构处。别用函数体内if (props.xxx === undefined) props.xxx = ...这种赋值式写法，既不直观，还可能引发重新渲染问题。
第二，默认值数量超过三个时，考虑把默认值对象单独提出来做常量管理，然后在组件内合并使用。这样调用方也能一眼看到“这个组件有哪些可选项”。
第三，区分“显示层面的兜底”和“业务状态的默认值”。组件展示层默认值只管“没有这个 UI 素材时显示什么”；业务默认值应该由状态库、数据层或者业务组件初值来管。混在一起，代码会越来越难维护。
第四，善用 TypeScript 的可选链?.和空值合并??做第二层防护，但要克制，不要每一处都写防御代码。第一层默认值，第二层必要处??，第三层才是可选链。三层下来，代码既安全又不至于满屏问号。
第五，如果在团队里推行组件规范，把默认值纳入代码审查范围。验收标准很简单：组件里所有 props 在文档说明或者注释里有明确的“缺省行为”描述，而不是让使用者猜。一个 props 没有默认值、没有注释的组件，交给下一个同事用的时候，大概率会出问题。
React 的属性默认值，归根结底是把组件的容错能力前置。写组件的人多花一分钟把边界想清楚，用组件的人就能少花一小时去排查“怎么没显示”。我个人的体会是，真正让一个组件库好用起来的，往往不是那些花哨的功能，而是这些基础细节处理得够不够稳。属性默认值只是一个点，但把这类点逐一磨平，组件的健壮性和协作效率都会上一个台阶。
这一篇就到这里。下一篇我会继续沿着 props 这条线，聊聊状态提升和受控组件相关的机制，那是组件通信里另一个容易出问题的地方。
