JSX的style为什么必须写成对象而不能写字符串？

从报错现象切入：写成字符串会发生什么？

初次使用 React 的开发者，最常遇到的挫折之一就是把在 HTML 中习以为常的行内样式原封不动写在 JSX 标签上：

// ❌ 常见的错误写法
<div style="color: red; font-size: 16px;">欢迎访问</div>

在开发环境下，React 不仅不会渲染出期望的红色字体，还会直接在浏览器控制台中抛出一条醒目的黄色或红色警告：

Warning: The `style` prop expects a mapping from style properties to values, not a string. 
For example, style={{marginRight: spacing + 'em'}} when using JSX.

警告非常明确：style 属性期望接收一个“从样式属性映射到具体值的字典对象”，而不是一段字符串。于是我们必须把它改写成带有“双大括号”的形式：

// ✔ 正确的标准写法
<div style={{ color: 'red', fontSize: 16 }}>欢迎访问</div>

这里的“双大括号”常让新手感到困惑。实际上，它根本不是一个特殊的独立运算符，而是两个独立语法的自然嵌套：外层的一对大括号 { ... } 是 JSX 的表达式求值分界符，告知解析器此处从静态标记切入 JavaScript 执行上下文；内层的一对大括号 { color: 'red', fontSize: 16 } 则是一个货真价实的普通 JavaScript 对象字面量。

如果你把这个对象提取出来赋给一个常量，结构就会显得格外清晰：

// 将样式对象单独定义，彻底看清双括号的本质
const boxStyle = {
  color: 'red',
  fontSize: 16
};

// JSX 中仅保留一层用于传值的表达式大括号
<div style={boxStyle}>欢迎访问</div>

理解了外在语法之后，更本质的问题随之而来：React 为什么宁愿打破 HTML 沿用了数十年的字符串习惯，也要强制要求传入对象？

编译时视角：JSX 只是 JavaScript 函数调用的语法糖

要理解 style 的设计，首先必须认清 JSX 的真实身份。在浏览器能够执行我们的代码之前，Babel 或 SWC 这类转译器会将所有 JSX 标签转换为普通的 JavaScript 函数调用。

在传统的 React 编译管道中，代码会被转译为 React.createElement；而在现代的 JSX 运行时（Automatic Runtime）中，则会被转译为 _jsx 函数：

// 编译前的 JSX 源码
const element = <div id="header" style={{ color: 'red', margin: 10 }}>标题</div>;

// 编译后的真实 JavaScript 代码
import { jsx as _jsx } from 'react/jsx-runtime';

const element = _jsx('div', {
  id: 'header',
  style: {
    color: 'red',
    margin: 10
  },
  children: '标题'
});

注意转译后的第二个参数——它是一个包含了标签所有属性的 JavaScript 对象（即组件接收到的 props）。如果允许 style 保持字符串，那么在 JavaScript 运行环境中，样式就仅仅是一串无结构的文本；而将其保持为对象，样式就直接以结构化的键值字典存在于整个应用的数据流中。

这种设计让样式成为 JavaScript 的“一等公民”（First-class Citizen）。开发者无需借助复杂的字符串正则拼接，即可利用解构赋值、逻辑短路与三元表达式，极其自然地实现样式的动态计算与合并：

// 利用原生 JavaScript 对象的能力轻松组合样式
const buttonStyle = {
  padding: '8px 16px',
  borderRadius: 4,
  backgroundColor: isPrimary ? '#52677D' : '#FFFFFF',
  ...(isDisabled && { opacity: 0.5, cursor: 'not-allowed' }),
  ...customStyle
};

return <button style={buttonStyle}>提交</button>;

运行时视角：虚拟 DOM Diff 算法与原子化更新

除了编译层面的自然契合，促使 React 做出这一决定的最关键动力，来自于虚拟 DOM 的更新性能与精确控制。

在 React 的工作流程中，当组件状态发生变化时，React 并不会粗暴地把整个 DOM 树推倒重来，而是会在内存中构建一棵新的虚拟 DOM 树（Fiber 树），并将它与上一次渲染留下的旧树进行逐层对比。这个对比过程就是广受赞誉的协调（Reconciliation）与 Diffing 算法。

现在设想一下：如果 React 允许使用字符串表示样式，当组件重渲染且样式发生改变时，React 引擎应该如何应对？

假设方案一：每次直接赋值 node.style.cssText = newStyleString

直接用新字符串覆盖真实 DOM 节点的 cssText，看似最为简单直接。然而，这种操作具有严重的破坏性：

• 抹除未受控样式：如果第三方插件或原生脚本此前动态修改过该节点的其他行内样式，全量覆盖会将其瞬间清除。
• 强制引发浏览器全量重排（Reflow）与重绘（Repaint）：浏览器无法复用该元素当前已经计算好的样式布局树，必须丢弃旧规则重新计算，造成肉眼可见的卡顿。

假设方案二：在运行时引入 CSS 解析器解析字符串

为了精准找出变动的属性，React 必须在浏览器运行时自带一个完整的 CSS Parser。每当一个包含样式的组件重新渲染时，React 必须对新旧两个 style 字符串进行词法分词、语法解析，生成两张样式属性映射表，然后再进行比对。

这在工程上是不可接受的：CSS 语法非常复杂（包含分号转义、引号嵌套、括号闭合等），纯 JS 实现的解析器既会给 React 打包体积增加数十 KB，又会在组件频繁更新（如拖拽、滚动动画）时消耗大量 CPU 时间进行无谓的字符串正则匹配。

现实方案：原生对象带来的 O(N) 极速浅比对

因为样式在传入时就已经是一个结构化的 JavaScript 键值对象，React 在协调阶段（源码位于 react-dom-bindings/src/client/CSSPropertyOperations.js 中的 setValueForStyles 以及 diffProperties）能够以极其微小的代价完成增量比对：

1. 清除失效属性：遍历旧样式对象 prevStyle 的所有键，若该键在 nextStyle 中不再存在，则执行 domNode.style[prop] = '' 将其重置。
2. 更新变更属性：遍历新样式对象 nextStyle 的所有键，只需判断 prevStyle[prop] !== nextStyle[prop]。只要值发生了变化，就记录进更新队列。
3. 原子化提交：在 Commit 阶段，React 只会对真正发生变化的特定 CSS 属性调用单项赋值，例如 domNode.style.color = 'blue'，而完全不去触碰其他没有改变的属性。

整个比对过程是纯净的原生属性访问，时间复杂度为严格的 O(N)，完全消除了字符串解析开销，并最大程度保护了浏览器的渲染流水线。

接口规范与安全性：原生对齐与防御能力

除了编译与性能考量，JSX 选择对象还在底层接口规范与 Web 安全性上带来了巨大的工程红利。

1. 驼峰命名（camelCase）对标 W3C DOM 原生标准

在 HTML 中，我们书写 background-color: red；但在浏览器 JavaScript 环境中，由于短横线 - 在 JS 中是减号操作符，DOM 规范委员会早在二十多年前就制定了标准的 CSSStyleDeclaration 接口规范：所有 CSS 属性在 DOM 对象上均映射为小驼峰属性名，即 element.style.backgroundColor。

React 的 JSX 并不是对 HTML 的重新发明，而是让 JavaScript 能够原生操作 DOM。因此，JSX 让 style 的键名遵循小驼峰规范，本质上是在严格遵守浏览器的原生 DOM API 设计，省去了任何运行时命名转换的包袱。

2. 智能数值处理与无单位白名单

在传统 CSS 中，给长度属性只写数字而不写单位是无效的（例如 margin: 10 会被浏览器直接忽略并丢弃）。但在日常开发中，大量样式都以像素（px）为基准。

得益于对象结构对键值对的独立感知，React 内部维护了一张经过充分测试的“无单位属性白名单”（如 zIndex、lineHeight、opacity、fontWeight、flex 等）。对于非白名单内的普通长度属性，当检测到开发者传入的是一个数字时，React 会贴心地自动追加 'px' 后缀：

// 开发者简写纯数字
<div style={{ width: 200, height: 100, zIndex: 10 }} />

// React 内部自动标准化为
domElement.style.width = '200px';
domElement.style.height = '100px';
domElement.style.zIndex = 10; // 保留无单位数值

如果使用字符串，React 就无法在不解析完整语法的前提下安全完成这项智能转换。

3. 构筑 XSS 安全防线

在传统使用字符串拼接 HTML 的时代，样式属性是跨站脚本攻击（XSS）的重灾区。例如通过未过滤的用户输入拼接样式字符串时，恶意代码可以轻易通过闭合引号逃逸并注入伪协议或 CSS 表达式：

// 传统字符串拼接极易引发漏洞
const maliciousInput = "red; background: url('javascript:stealToken()')";
element.innerHTML = `<div style="color: ${maliciousInput}"></div>`;

而使用对象形式传递属性时，开发者传入的值是作为纯数据绑定在指定的 CSS 属性上。在赋值给 element.style[prop] 时，浏览器的原生 Setter 会将输入严格限制在该属性允许的值域范围内，即使内容包含分号、引号或括号，也不会逃逸出当前属性成为新的 CSS 规则，从根本上杜绝了结构逃逸型的 XSS 隐患。

总结与实战选型建议

综合来看，JSX 的 style 必须写成对象，是 React 体系下语法一致性、运行时比对性能、DOM 原生标准对齐与安全性保障四重目标共同作用的必然结果。

因此，在现代前端工程开发中，推荐建立清晰的样式使用边界：

• 动态高频变动样式：如通过鼠标拖拽实时计算的 transform、组件内部动态伸缩的宽高尺寸，强烈推荐使用 style 对象传递，必要时配合 useMemo 缓存对象引用。
• 静态视觉排版样式：绝大多数布局、颜色、字体、伪类与动画，推荐交给 CSS Modules、Tailwind CSS 或外部样式表处理。这能让 Virtual DOM 树保持极低内存占用，并充分利用浏览器原生 CSS 引擎经过几十年极致优化的匹配性能。