React+TypeScript 组件类型注解的两种核心写法

Unknown — Thu, 13 Nov 2025 00:00:00 +0000

对于 React 初学者来说，TypeScript 类型注解常常是入门难点——尤其是组件 props 的类型定义，既想让 IDE 给出清晰提示（必选/可选、类型、参数名），又不想被复杂的类型语法绕晕。

本文将总结两种最实用的 React 组件类型注解写法，帮你快速上手并做出合适选择。

一、核心前提：为什么需要组件类型注解？</h2>

在写 React 组件时，类型注解的核心价值的是：

IDE 智能提示：父组件使用时，自动显示 props 名称、必选/可选标记、类型说明；</li>
提前报错：漏传必选 props、传错类型时，TypeScript 直接标红，避免运行时 bug；</li>

代码可读性：他人（或未来的你）看代码时，能快速知道组件需要什么参数。</li> </ol>
而我们要讲的两种写法，都能实现这些价值——只是风格和适用场景不同。
二、写法一：Function 关键词 + 单独 Props 接口</h2>
这是最贴合直觉的写法，尤其适合刚接触 React+TS 的同学，核心是“先定义 props 类型，再给组件函数标注类型”。
1. 基础写法（完整示例）</h3>
// 1. 导入 React（可选，若用 JSX.Element 需导入） import React from 'react'; // 2. 定义语义化 Props 接口（组件名 + Props 命名规范） interface GreetingCardProps { // 必选属性：无 ? 符号，类型明确 username: string; // 可选属性：带 ? 符号，可配合默认值 message?: string; // 复杂类型：回调函数（参数类型+返回值类型） onSend?: (content: string) => void; } // 3. 组件定义：function 关键词 + 参数解构 + 类型标注 function GreetingCard({ username, message = '欢迎使用 React+TS！', // 可选属性设置默认值 onSend, }: GreetingCardProps): JSX.Element { // 显式标注返回值类型 const handleClick = () => { // 可选链语法：避免 onSend 为 undefined 时报错 onSend?.(`${username}说：${message}`); }; return ( <div className="greeting-card"> <h3>你好，{username}！</h3> <p>{message}</p> <button onClick={handleClick}>发送消息</button> </div> ); } // 4. 导出组件（分开导出，提升可读性和扩展性） export default GreetingCard;</code></pre>2. 核心要点（初学者必看）</h3> Props 接口命名：必须遵循 [组件名]Props</code>（如 GreetingCardProps</code>），语义化且易关联；</li> 解构位置：在函数参数中直接解构 props，父组件使用时能看到具体参数提示（而非模糊的 props</code> 变量）；</li> 返回值类型：用 JSX.Element</code> 更直观（与 JSX 语法对应），和 React.ReactElement</code> 本质等价；</li> export 写法：分开导出（先定义后导出），避免一行代码拥挤，后续添加静态属性/扩展更方便。</li> </ul> 3. 父组件使用效果</h3> 1import GreetingCard from './GreetingCard'; 2 3function Parent(): JSX.Element { 4 return ( 5 <div> 6 {/* 输入 <GreetingCard 后，IDE 自动提示： 7 - username（必选）: string 8 - message（可选）: string | undefined 9 - onSend（可选）: (content: string) => void 10 */} 11 <GreetingCard 12 username="小明" 13 message="一起学习 TypeScript 吧！" 14 onSend={(content) => console.log(content)} 15 /> 16 </div> 17 ); 18}</code></pre>三、写法二：Const 箭头函数 + React.FC（函数式风格首选）</h2> 这种写法是“const 变量 + 箭头函数 + React.FC 泛型”，核心是用 React 内置的 React.FC</code>（FunctionComponent）类型模板，简化类型标注。 1. 基础写法（完整示例）</h3> import React from 'react'; // 1. 定义 Props 接口（无需手动加 children！） interface GreetingCardProps { username: string; message?: string; onSend?: (content: string) => void; } // 2. 组件定义：React.FC<Props> 标注变量类型 const GreetingCard: React.FC<GreetingCardProps> = ({ username, message = '欢迎使用 React+TS！', onSend, children, // 自动获得 children 属性，无需在 Props 接口定义 }) => { const handleClick = () => { onSend?.(`${username}说：${message}`); }; return ( <div className="greeting-card"> <h3>你好，{username}！</h3> <p>{message}</p> {children} {/* 直接使用 children，无需额外配置 */} <button onClick={handleClick}>发送消息</button> </div> ); }; export default GreetingCard;</code></pre>2. 核心要点（搞懂 React.FC 的本质）</h3> React.FC 是什么？：它是 React 内置的泛型类型模板，本质是给变量标注“这是一个 React 函数组件”，语法简化为 React.FC<Props接口></code>；</li> 自动包含的特性：内置 children?: React.ReactNode</code> 属性，无需在 Props 接口手动定义；</li> 自动约束返回值类型为 JSX.Element</code>，不用额外写返回值标注；</li> </ol> </li> 变量标注的意义：const GreetingCard: React.FC<GreetingCardProps></code> 是给变量 GreetingCard</code> 贴“组件标签”，告诉 TypeScript 这个变量对应的箭头函数是 React 组件，需遵循 Props 接口规范。</li> </ul> 3. 父组件使用效果</h3> 和写法一完全一致——父组件使用时，IDE 同样会显示完整的 props 提示（必选/可选、类型、名称），漏传必选 props 会标红报错。 四、两种写法核心对比（初学者怎么选？）</h2> 对比维度</th> 写法一（Function + 单独 Props）</th> 写法二（Const 箭头 + React.FC）</th></tr></thead> 可读性</td> 高，符合传统函数认知，新手易理解</td> 简洁，但需理解 React.FC 泛型，略抽象</td></tr> children 支持</td> 需手动在 Props 接口添加 children?: React.ReactNode</code></td> 自动内置，无需手动定义</td></tr> 返回值类型</td> 需显式标注 : JSX.Element</code></td> 自动推导，无需额外标注</td></tr> 静态属性扩展</td> 直接挂载（GreetingCard.static = ...</code>）</td> 需先赋值给变量，再挂载（多一行代码）</td></tr> useCallback 兼容</td> 完全兼容，直接包裹 function 函数</td> 兼容，包裹箭头函数（写法更统一）</td></tr> 学习成本</td> 低，只需掌握接口和函数类型标注</td> 中，需额外理解 React.FC 泛型概念</td></tr> </tbody></table> 选择建议：</h3> 优先选写法一：如果你是初学者，觉得 function</code> 更易理解，或组件很少用 children</code>，选这种——直观、少踩坑，核心功能完全满足；</li> 选写法二的场景：如果团队用函数式编程风格（箭头函数为主），或组件经常需要 children</code> 属性，选这种——能省掉 children</code> 定义，写法更简洁；</li> 核心原则：两种写法在功能上无优劣，优先选择你能看懂、写起来顺手的，项目内保持风格一致即可。</li> </ol> 五、初学者避坑指南</h2> 不要混用两种写法：比如 function GreetingCard: React.FC<Props> () {}</code> 是错误的，React.FC 只能标注变量（箭头函数/函数表达式），不能标注 function 声明；</li> Props 接口不要省略：即使组件只有一个 props，也建议定义单独接口（如 interface ButtonProps { text: string }</code>），比直接写 (props: { text: string })</code> 更易维护；</li> 可选属性必加默认值：可选属性（带 ?</code>）建议设置默认值（如 message = '默认文案'</code>），避免组件内频繁判断 undefined</code>；</li> export 写法推荐：无论哪种写法，都建议“先定义组件，后导出”（分开写），避免一行代码过长，后续扩展更方便。</li> </ol> 总结</h2> React+TypeScript 组件类型注解的核心是“明确 props 类型”，两种写法都能实现 IDE 提示、类型校验和可读性提升： 初学者优先选 Function 关键词 + 单独 Props 接口，直观易理解，学习成本低；</li> 熟悉泛型后可尝试 Const 箭头函数 + React.FC，适合函数式风格和频繁使用 children</code> 的场景。</li> </ul> 不用纠结“哪种更好”，掌握一种写法并熟练运用，再根据项目需求或团队规范切换即可——核心是让 TypeScript 帮你减少 bug，让代码更清晰。 如果需要进一步学习，建议先熟练掌握接口定义和函数类型标注，再深入理解 React.FC 等 React 内置类型工具，逐步提升 TypeScript 运用能力～ 解构赋值已经在当前作用域 “声明” 了变量（比如bookmarks</code>），后续再用const/let/var</code>声明同名变量，就违反了 “同一作用域不能重复声明” 的规则 解决办法</h3> 1. 解构时直接 “重命名”（推荐）</h4> 直接在解构时给 props 里的变量起个 “别名”，避免冲突 —— 这是 JS 解构语法支持的原生功能 function BookmarkList({ bookmarks: propsBookmarks }: Props)</code></pre>2. 不重复命名</h4> 换个语义化的变量名，props 里的bookmarks</code>是 “原始数据”，后续处理后的可以叫filteredBookmarks</code>（过滤后）、sortedBookmarks</code>（排序后），既避免冲突，代码可读性也更高。 读《Tiny Habits》的一个启发 Unknown — Tue, 11 Nov 2025 00:00:00 +0000 当一个行为没有发生，我们该从哪儿找原因？ 不够努力？</li> 态度有问题？</li> </ul> 《张忠谋自传 · 上》什么是学习曲线？ Unknown — Thu, 09 Oct 2025 00:00:00 +0000 什么是学习曲线？ 随着生产经验的积累，单位产品的成本会不断下降。 </blockquote> 张忠谋在德仪（Texas Instruments）时，韩德生（Henderson）提出这个理论，帮助他们理解制造效率与经验的关系。 张忠谋大力称赞这个理论，让我有些迷惑，做的越多，越熟练，这难道不是常识吗？ 把“常识”量化成可以预测、可以决策的工具。这就是它从“正确的废话”变成“战略武器”的地方。 有哪些初始成本极低、后果延迟且不可逆的行为？ Unknown — Fri, 05 Sep 2025 00:00:00 +0000 利用 “行为门槛低 + 风险感知弱” 的心理反差，引导用户做出看似轻松、实则影响深远的决策。 压缩 “初始决策成本”：让行为 “触手可及”，降低用户的思考和行动门槛；</li> 延迟 “负面后果感知”：让风险在遥远的未来显现，避免即时压力干扰决策；</li> 锁定 “后果不可逆性”：一旦行为发生，损失或影响无法轻易撤销，从而形成 “决策 - 后果” 的强绑定。</li> </ol> “剪标不退换” 的服装销售 商家把衣服上的纸质标签换成硬塑料的，还把标签位置从不影响试穿的拉链处，挪到了会直接蹭到皮肤的脖颈处 —— 故意让标签磨得人不舒服，好让用户忍不住剪掉标签。而衣服一旦剪了标，通常就不能退换了。 其心理学本质是： 用即时痛苦掩盖长期风险 塑料标签的摩擦感是即时且明确的负面刺激，而「剪标导致无法退换」的后果是延迟且模糊的潜在风险。根据即时满足偏差，用户会优先处理眼前的不适，而非考虑未来可能的退货需求。 </li> 用行为惯性切断退路 商家将标签位置从拉链处（不影响试穿）移至脖颈处，实际上创造了一个「忍受摩擦」或「剪标」的强制选择场景。根据强迫选择理论，当用户被迫在两个选项中抉择时，往往会选择「最直接、最可控」的选项（剪标），而非被动忍受持续的不适感。 </li> 用认知偏差重构决策框架 用户在试穿时会下意识地认为「剪标是正常操作」，而非主动思考是否需要保留标签以退换货。这种设计利用了用户的现状偏见，即倾向于维持已发生的行为（剪标），而非主动改变现状（保留标签）。 </li> </ol> 如果人生是一场游戏 Unknown — Sat, 03 Aug 2024 00:00:00 +0000 活着就是为了追求最大的游戏体验 </blockquote>

Clane's Notes

React+TypeScript 组件类型注解的两种核心写法

二、写法一：Function 关键词 + 单独 Props 接口</h2>
这是最贴合直觉的写法，尤其适合刚接触 React+TS 的同学，核心是“先定义 props 类型，再给组件函数标注类型”。</p>

三、写法二：Const 箭头函数 + React.FC（函数式风格首选）</h2>
这种写法是“const 变量 + 箭头函数 + React.FC 泛型”，核心是用 React 内置的 `React.FC</code>（FunctionComponent）类型模板，简化类型标注。</p>`

3. 父组件使用效果</h3>
和写法一完全一致——父组件使用时，IDE 同样会显示完整的 props 提示（必选/可选、类型、名称），漏传必选 props 会标红报错。</p>

读《Tiny Habits》的一个启发

《张忠谋自传 · 上》什么是学习曲线？

有哪些初始成本极低、后果延迟且不可逆的行为？

如果人生是一场游戏

对比维度</th>	写法一（Function + 单独 Props）</th>	写法二（Const 箭头 + React.FC）</th></tr></thead>
可读性</strong></td>	高，符合传统函数认知，新手易理解</td>	简洁，但需理解 React.FC 泛型，略抽象</td></tr>
children 支持</strong></td>	需手动在 Props 接口添加 `children?: React.ReactNode</code></td>`	自动内置，无需手动定义</td></tr>
返回值类型</strong></td>	需显式标注 `: JSX.Element</code></td>`	自动推导，无需额外标注</td></tr>
静态属性扩展</strong></td>	直接挂载（`GreetingCard.static = ...</code>）</td>`	需先赋值给变量，再挂载（多一行代码）</td></tr>
useCallback 兼容</strong></td>	完全兼容，直接包裹 function 函数</td>	兼容，包裹箭头函数（写法更统一）</td></tr>
学习成本</strong></td>	低，只需掌握接口和函数类型标注</td>	中，需额外理解 React.FC 泛型概念</td></tr> </tbody></table> 选择建议：</h3> 优先选写法一</strong>：如果你是初学者，觉得 `function</code> 更易理解，或组件很少用 children</code>，选这种——直观、少踩坑，核心功能完全满足；</li>` `选写法二的场景</strong>：如果团队用函数式编程风格（箭头函数为主），或组件经常需要 children</code> 属性，选这种——能省掉 children</code> 定义，写法更简洁；</li>` 核心原则</strong>：两种写法在功能上无优劣，优先选择你能看懂、写起来顺手的</strong>，项目内保持风格一致即可。</li> </ol> 五、初学者避坑指南</h2> 不要混用两种写法</strong>：比如 function GreetingCard: React.FC<Props> () {}</code> 是错误的，React.FC 只能标注变量（箭头函数/函数表达式），不能标注 function 声明；</li> Props 接口不要省略</strong>：即使组件只有一个 props，也建议定义单独接口（如 interface ButtonProps { text: string }</code>），比直接写 (props: { text: string })</code> 更易维护；</li> 可选属性必加默认值</strong>：可选属性（带 ?</code>）建议设置默认值（如 message = '默认文案'</code>），避免组件内频繁判断 undefined</code>；</li> export 写法推荐</strong>：无论哪种写法，都建议“先定义组件，后导出”（分开写），避免一行代码过长，后续扩展更方便。</li> </ol> 总结</h2> React+TypeScript 组件类型注解的核心是“明确 props 类型”，两种写法都能实现 IDE 提示、类型校验和可读性提升：</p> 初学者优先选 Function 关键词 + 单独 Props 接口</strong>，直观易理解，学习成本低；</li> 熟悉泛型后可尝试 Const 箭头函数 + React.FC</strong>，适合函数式风格和频繁使用 children</code> 的场景。</li> </ul> 不用纠结“哪种更好”，掌握一种写法并熟练运用，再根据项目需求或团队规范切换即可——核心是让 TypeScript 帮你减少 bug，让代码更清晰。</p> 如果需要进一步学习，建议先熟练掌握接口定义和函数类型标注，再深入理解 React.FC 等 React 内置类型工具，逐步提升 TypeScript 运用能力～</p> 解构赋值已经在当前作用域 “声明” 了变量（比如bookmarks</code>），后续再用const/let/var</code>声明同名变量，就违反了 “同一作用域不能重复声明” 的规则</strong></p> 解决办法</h3> 1. 解构时直接 “重命名”（推荐）</h4> 直接在解构时给 props 里的变量起个 “别名”，避免冲突 —— 这是 JS 解构语法支持的原生功能</p> function</span> BookmarkList</span>({</span> bookmarks</span>:</span> propsBookmarks</span> }</span>:</span> Props</span>)</span></span></code></pre>2. 不重复命名</h4> 换个语义化的变量名，props 里的bookmarks</code>是 “原始数据”，后续处理后的可以叫filteredBookmarks</code>（过滤后）、sortedBookmarks</code>（排序后），既避免冲突，代码可读性也更高。</p> 读《Tiny Habits》的一个启发 Unknown — Tue, 11 Nov 2025 00:00:00 +0000 当一个行为没有发生，我们该从哪儿找原因？</p> 不够努力？</li> 态度有问题？</li> </ul> 《张忠谋自传 · 上》什么是学习曲线？ Unknown — Thu, 09 Oct 2025 00:00:00 +0000 什么是学习曲线？</p> 随着生产经验的积累，单位产品的成本会不断下降。</p> </blockquote> 张忠谋在德仪（Texas Instruments）时，韩德生（Henderson）提出这个理论，帮助他们理解制造效率与经验的关系</strong>。</p> 张忠谋大力称赞这个理论，让我有些迷惑，做的越多，越熟练，这难道不是常识吗？</p> 把“常识”量化成可以预测、可以决策的工具</strong>。这就是它从“正确的废话”变成“战略武器”的地方。</p> 有哪些初始成本极低、后果延迟且不可逆的行为？ Unknown — Fri, 05 Sep 2025 00:00:00 +0000 利用 “行为门槛低 + 风险感知弱” 的心理反差，引导用户做出看似轻松、实则影响深远的决策。</p> 压缩 “初始决策成本”</strong>：让行为 “触手可及”，降低用户的思考和行动门槛；</li> 延迟 “负面后果感知”</strong>：让风险在遥远的未来显现，避免即时压力干扰决策；</li> 锁定 “后果不可逆性”</strong>：一旦行为发生，损失或影响无法轻易撤销，从而形成 “决策 - 后果” 的强绑定。</li> </ol> “剪标不退换” 的服装销售</strong></p> 商家把衣服上的纸质标签换成硬塑料的，还把标签位置从不影响试穿的拉链处，挪到了会直接蹭到皮肤的脖颈处 —— 故意让标签磨得人不舒服，好让用户忍不住剪掉标签。而衣服一旦剪了标，通常就不能退换了。</p> 其心理学本质是：</p> 用即时痛苦掩盖长期风险</strong></p> 塑料标签的摩擦感是即时且明确的负面刺激</strong>，而「剪标导致无法退换」的后果是延迟且模糊的潜在风险</strong>。根据即时满足偏差</strong>，用户会优先处理眼前的不适，而非考虑未来可能的退货需求。</p> </li> 用行为惯性切断退路</strong></p> 商家将标签位置从拉链处（不影响试穿）移至脖颈处，实际上创造了一个「忍受摩擦」或「剪标」的强制选择场景</strong>。根据强迫选择理论</strong>，当用户被迫在两个选项中抉择时，往往会选择「最直接、最可控」的选项</strong>（剪标），而非被动忍受持续的不适感。</p> </li> 用认知偏差重构决策框架</strong></p> 用户在试穿时会下意识地认为「剪标是正常操作」，而非主动思考是否需要保留标签以退换货。这种设计利用了用户的现状偏见</strong>，即倾向于维持已发生的行为（剪标），而非主动改变现状（保留标签）。</p> </li> </ol> 如果人生是一场游戏 Unknown — Sat, 03 Aug 2024 00:00:00 +0000 活着就是为了追求最大的游戏体验</p> </blockquote>

Clane's Notes

React+TypeScript 组件类型注解的两种核心写法

二、写法一：Function 关键词 + 单独 Props 接口</h2> 这是最贴合直觉的写法，尤其适合刚接触 React+TS 的同学，核心是“先定义 props 类型，再给组件函数标注类型”。</p>

3. 父组件使用效果</h3> 和写法一完全一致——父组件使用时，IDE 同样会显示完整的 props 提示（必选/可选、类型、名称），漏传必选 props 会标红报错。</p>

读《Tiny Habits》的一个启发

《张忠谋自传 · 上》 什么是学习曲线？

有哪些初始成本极低、后果延迟且不可逆的行为？

如果人生是一场游戏

二、写法一：Function 关键词 + 单独 Props 接口</h2>
这是最贴合直觉的写法，尤其适合刚接触 React+TS 的同学，核心是“先定义 props 类型，再给组件函数标注类型”。</p>

3. 父组件使用效果</h3>
和写法一完全一致——父组件使用时，IDE 同样会显示完整的 props 提示（必选/可选、类型、名称），漏传必选 props 会标红报错。</p>

《张忠谋自传 · 上》什么是学习曲线？