React中使用{...{属性}}形式批量传递Props是否存在问题？

先把实底说清楚 #

你遇到的这种{...{ currentSong, isPlaying, setIsPlaying, setCurrentSong }}的写法根本没有语法层面的硬性错误，JSX语法和浏览器完全支持，运行时效果和逐行显式传递Props完全一致，连传值逻辑都没有区别。但这种写法在实际项目里几乎没人用，本质是这写法半毛钱好处没有，全是开发体验上的麻烦。 #

这种写法的真实本质 #

很多人刚看到的时候会以为是什么省代码的语法糖，其实你写的这行代码，等价于在渲染Player组件时，临时在内存里创建一个没有任何语义的匿名对象，把几个相关变量塞进去，再把这个对象的所有属性展开成Props传给组件：

// 实际执行的等价逻辑，没有任何特殊魔法
const tempAnonymousObject = {
  currentSong: currentSong,
  isPlaying: isPlaying,
  setIsPlaying: setIsPlaying,
  setCurrentSong: setCurrentSong
};
<Player {...tempAnonymousObject} />

从运行结果看，它和逐行写Props没有任何区别：不会出现Props传值错误、组件崩溃的问题，也不会额外触发组件不必要的重渲染——因为展开之后传给Player的，仍然是你本来定义的那几个变量本身的引用，和那个临时用来包裹的对象没有关系。 #

为什么这种写法在社区里几乎看不到 #

• 完全打乱了开发者的代码阅读预期
  有一年以上React开发经验的人，看JSX代码都有固定的肌肉记忆：组件标签里逐行列出来的属性，就是组件接收的明确Props；看到...开头的展开符，默认是作者把一整个提前定义好的、有明确用途的对象整体透传过来——比如把父组件接收到的剩余Props原样传给子组件，或者把一堆DOM原生属性透传给底层元素。
  这种在展开符后面直接裹匿名对象的写法，完全打破了这个预期：协作者看到的第一反应往往是“作者是不是打漏了变量名？本来是要传一个提前写好的props对象的吧？”，得盯着括号仔细拆解半天才能识别到底传了哪些Props，平白增加认知负担。就算是自己写的代码，过两三个月回来看这段逻辑，也得愣两秒反应过来。
• 没有任何实际收益，纯无效写法
  对比逐行显式写Props，这种写法唯一能省的就是敲等号的那几个字符，换回来的是：每次组件重渲染都要临时创建一个没有语义的匿名对象，既不能加快运行速度，也不能减少打包体积，属于纯冗余的写法。就连Prettier这类自动格式化工具，遇到这种写法都经常会把所有Props挤在同一行，进一步拉低代码可读性。
• 给静态检查徒增麻烦
  不管是TypeScript的类型校验，还是ESLint的React代码规则，都是针对“逐行声明的Props属性”“有独立命名的Props对象”做了适配优化的。这种裹在匿名临时对象里的展开写法，会拉长类型推导的链路：本来逐行写Props时，TS能精准提示“你传的currentSong不符合Song类型定义”，裹上一层匿名对象之后，报错信息会变得模糊绕弯；甚至还会触发ESLint默认开启的“禁止无意义Props展开”的规则告警。

真正被社区认可的Props展开写法是什么样的 #

其实和你提到的内联写法运行效果完全一致，但在正常项目里被广泛使用的，是把Props提前定义成有明确名字的独立变量，而不是在展开符后面临时裹个匿名对象：

// 提前把和Player相关的Props聚成有明确语义的变量，需要时直接透传
const playerProps = {
  currentSong,
  isPlaying,
  setIsPlaying,
  setCurrentSong
};
<Player {...playerProps} />

这种写法不会打乱代码阅读预期——看到playerProps这个变量名，任何人都能快速知道这里传的是Player组件需要的配置；如果别的组件也要用同一套参数，直接复用这个变量就行，不会出现重复代码，所以才是项目里常见的写法，和你提到的“在展开符后面硬裹匿名对象”的写法有本质区别。 #

内容的提问来源于stack exchange，提问作者Talmacel Marian Silviu