React JS中为何使用class而非ID进行组件样式设置？

核心原因是ID的原生特性和React组件化的开发逻辑天生不匹配，和原生JS开发的场景差异很大，具体可以拆成几个实际开发里的硬约束：

• 首先是和组件复用逻辑直接冲突。HTML规范里ID必须在整个页面全局唯一，但是React组件是可复用的封装单元，你写好一个通用卡片、按钮组件，同一个页面可能渲染几次甚至几十次。如果给组件根节点写死固定ID，只要组件渲染超过1次就直接违反规范，轻则样式匹配错乱，重则DOM查询拿到不符合预期的节点。原生JS开发时代页面结构大多是逐行硬编码的，开发者可以自己控制ID不重复，但组件是封装完给全项目用的，你根本预判不到同一个组件会被实例化多少次，写死ID从根源上就不可行。
• 其次是样式优先级的维护成本太高。CSS选择器权重里ID的优先级是class的10倍，一旦用ID写了基础样式，后续要做主题定制、局部样式覆盖、或者配合CSS方案做调整的时候，必须写权重更高的选择器才能覆盖原有样式，很容易堆出优先级混乱、难以维护的面条CSS。
• 第三是ID的核心作用在React里已经被替代了。原生开发里用ID很大一部分场景是为了快速查询DOM，但React本身不推荐直接操作原生DOM，哪怕需要获取DOM节点，官方也提供了useRef、createRef的方案，完全不需要依赖ID做选择器。ID剩下的只有样式相关的作用，但又有前面说的两个硬伤，自然不会被用作主力样式选择器。
• 最后是生态适配的问题。现在React生态主流的CSS方案，不管是CSS Modules、Tailwind CSS还是各类CSS-in-JS库，默认都是基于class做样式隔离、类名生成的，自动生成的唯一类名既可以避免全局样式污染，又没有全局唯一的强制要求，完美适配组件复用的逻辑，整个生态的最佳实践里本来就没有给ID留样式场景的位置。

注意这不是说React里完全不能用ID，做表单label和input的关联、页面锚点跳转这类场景下，ID还是完全可以正常用的，只是不会有人把ID作为组件样式的主力选择器而已。

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