为React父组件给子组件添加专属Props是否为不良实践？

首先，React本身就支持父组件读取子元素的props（通过React.Children.map+React.cloneElement这类API），这种模式在很多流行的React组件库中都被广泛使用——比如React Router的<Route>组件（你会给它加path、element等props，这些props其实是被上层的<Routes>组件读取处理的），或者Ant Design的<Tabs.Tab>（title属性就是给父组件<Tabs>用来生成标签头的）。

接下来聊聊这种方式的优势：

• 语义化&可读性更强：你的JSX结构直接把导航项的配置（name）和对应的子组件绑定在一起，<Nav><Child name="child1"/></Nav>一眼就能看明白“这个Child组件对应导航里的child1项”，而如果是单独传数组<Nav navItems={[{name: 'child1'}]}/>，你还得手动把数组元素和子组件对应起来，逻辑脱节，后期维护容易出错。
• 子组件灵活性更高：如果你的Child组件需要自定义样式、事件或者其他专属props，比如<Child name="child1" className="custom-child" onClick={handleClick}/>，直接写在组件上就行，不用在数组里额外加字段，结构更紧凑。
• 类型友好（TS场景）：用TypeScript的话，你可以给Child的props定义明确的类型，比如：

  interface ChildProps {
    /** 仅用于父组件Nav获取导航名称，组件内部不使用 */
    name: string;
    // Child自身的props
    className?: string;
  }
  

  这样能确保name字段的正确性，而数组方式需要单独定义数组元素类型，容易和Child组件的类型脱节。

当然，使用这种模式也需要注意几个坑：

• 子组件别依赖这些“父专用”props：一定要保证Child组件内部完全不使用name属性，如果Child自己需要显示名称，应该再加一个比如displayName的props，把“给父组件用的配置”和“子组件自身的属性”分开。不然以后你把Child复用在其他地方，或者修改Nav的逻辑，很容易出现混淆和bug。
• 做好文档注释：在组件的props注释里明确标注哪些是给父组件用的，比如上面TS示例里的注释，团队协作的时候其他人一看就懂，不会误用。
• 注意性能：如果Nav里有大量子组件，遍历React.Children的时候尽量用useMemo缓存处理后的结果，避免每次渲染都重复遍历计算。

那什么时候适合用你提到的“传名称数组”的方式呢？

• 当导航项只是纯数据渲染，不需要对应具体的自定义子组件时，比如只是显示文字链接，那<Nav navItems={['child1', 'child2']}/>会更简洁。
• 当导航项是动态生成的（比如从后端接口获取数据），用数组循环渲染比手动写一堆<Child>组件更高效。

总结一下：给子组件添加仅父组件使用的props是React生态中非常常见且合理的模式，只要你处理好“子组件不依赖这些props”和“明确文档”这两点，完全不属于不良实践，甚至在很多场景下比单独传数组的体验更好。

内容的提问来源于stack exchange，提问作者curious