当你在 Elements 面板里犹豫不决：Styles 与 Computed 究竟谁在说真话？

在 Chrome DevTools 的 Elements 面板中，右侧并排的 Styles 与 Computed 看起来像两位性格不同但密切合作的工程师：Styles 更像一位档案管理员，逐条呈现来自各处样式表的原始声明与来源；Computed 则像一位总工程师，给出浏览器最终采纳、已计算完成、可直接用于渲染的那一份答案。理解二者的分工与协作，是定位 CSS 问题效率从分钟级降到秒级的关键。官方文档也明确建议：查看某元素的规则与诊断 CSS 问题，使用 Elements 面板下的 Styles 与 Computed 两个子面板配合进行。(Chrome for Developers)

两个面板的角色画像

Styles 面板是规则视图。它按层叠次序列出命中的选择器与声明：每条规则来自哪里（内联、外链样式表、<style>、@media 块、@supports 等）、处在何处、是否被覆盖、是否 !important、是否响应伪类。你能直接在这里编辑、启用或禁用某条声明，立刻看到页面变化；还可以看到被覆盖而划线的声明，帮助你理解层叠与优先级为何如此落子。Chrome 文档将它描述为展示实际写在各样式表中的规则集合，是查找无效、被覆盖或不生效 CSS 的首选窗口。(Chrome for Developers)

Computed 面板是结果视图。它不关心你写了多少重叠的规则、在哪些媒体查询里声明了哪些缩写属性；它只给出浏览器用于渲染该元素的最终值：继承之后、层叠决出胜负之后、相对单位初步解析之后的那一份 resolved 或 computed 值，并将所有缩写拆解为精确的长属性项（例如把 margin: 10px 展开为四个边的具体像素值）。Chrome 文档直白地说：当你只想看到真正应用到元素上的 CSS 值时，使用 Computed。(Chrome for Developers)

在规范层面，CSS 的值处理经历 specified → computed → used → actual 的阶段。Computed 面板展示的就是其中的 computed values：在继承与变量解析、相对单位部分解算之后、布局相关细化之前的那一类值；这正是从父到子的继承中传递的数值类型。MDN 对此有系统定义，理解这层语义能帮助你判断某些值为何以 px 呈现、为何某些百分比还未折算为最终像素。(MDN Web Docs)

为什么需要两扇窗一同看

把 Styles 与 Computed 放在一起理解，就像把过程追溯与结果验收放在一个回路里：

你在 Styles 里看到命中的每条规则、声明的原貌与来源，搞清是谁在发声。
你在 Computed 里确认最终采用的数值，搞清浏览器到底听了谁的。

Chrome 官方在 CSS features reference 中给了一个操作建议：当你对被覆盖的声明不感兴趣时，去 Computed 只看真正生效的；当你要回溯来源和层叠路径时，回到 Styles。(Chrome for Developers)

更贴近引擎的细节差异

有一些容易忽略、但在定位疑难杂症时非常关键的差异：

Computed 展示的是长属性，不以缩写存留。例如写了 border: 1px solid red，在 Computed 会展开为 border-top-width、border-right-style 等四向与多维长属性；这能让你一眼看清某一边缘是否被其他声明单独改写。(Chrome for Developers)
Computed 的数值是解析后的 resolved/computed 值，典型表现是 font-size: 70% 在这里会显示为 14px 这类明确单位值，便于与像素级布局或位图渲染对齐。(Chrome for Developers)
Styles 强调规则来源与层叠路径：每一条声明后面附有来源链接，点击会跳转到对应样式表的位置；被覆盖的声明以删除线标示，让你立刻知道输赢关系。(Chrome for Developers)
Computed 一般还会配套展现盒模型图（margin/border/padding/content），它以直观的示意图呈现尺寸与间距，配合最终值可快速判断溢出与对齐问题。(GeeksforGeeks)

把规范搬进手边：`computed` 与 `getComputedStyle`

当你在控制台里调用 window.getComputedStyle(element)，得到的正是浏览器眼中的已计算样式，与 Computed 面板显示的语义对应。这是将可视化诊断转化为可编程探针的桥梁：你可以在脚本里读取这些值，做自测或生成诊断日志。例如自动化测试里断言 getComputedStyle(button).color 是否为期望的 rgb。MDN 明确指出该 API 返回的就是应用激活样式表并完成基本计算后的值。(MDN Web Docs)

真实世界的三个小案例

案例一：按钮文字为什么变灰了？

场景：某管理后台的 dark 主题切换后，页面里一个 .btn-primary 的文字意外变成灰色，且 hover 无效。你在 Styles 中选中按钮，看到如下线索：

.btn-primary { color: #fff; } 被加了删除线。
.theme-dark .btn-primary { color: #aaa; } 位于更靠后的一份 theme.css，是当前生效的规则。
在 Computed 中，color 的最终值是 rgb(170, 170, 170)，并且条目右侧提示了具体来源的选择器。

这说明主题样式的层叠顺序更靠后或优先级更高，覆盖了通用按钮样式。处理方式要么调整 theme.css 的加载顺序，要么提高 .btn-primary 颜色声明的特异性，或者（更推荐）在主题样式里单独定义语义色变量，通过自定义属性统一管理。官方文档强调：当你只想看最终值，直接看 Computed；当你要回到是谁改了它，回去看 Styles 的来源与删除线。(Chrome for Developers)

案例二：`font-size` 百分比到底是多少像素？

你为容器设置了 font-size: 125%，子元素又写了 font-size: 80%。在 Styles 面板里你能看到两条声明，但脑内换算容易出错。打开 Computed，font-size 一栏直接给出 px 值，比如 20px 与 16px。这背后对应的正是规范中的值处理阶段：相对单位在计算至 computed value 时已解析成解析度独立、可继承的值，便于继续传递。(MDN Web Docs, Chrome for Developers)

案例三：`margin` 似乎没生效？

你写了 margin: 24px auto 期望居中，但元素依旧贴边。Styles 显示声明存在且未被划线，转到 Computed 却发现 margin-left 与 margin-right 为 0px。展开条目，右侧提示是某个 display: grid 的父容器影响了布局（通过网格对齐重写了你预期的居中方式），此时就不应盲目加 !important，而应调整布局方式，例如在网格容器上设置合适的对齐属性。Computed 的长属性展开与最终数值展示，正是为这种定位而生。(Chrome for Developers)

一套可复现的小示例：配合 `Styles` 与 `Computed` 定位层叠与单位解析

将下面的最小示例保存为 index.html，在浏览器打开并用 Ctrl+Shift+I 打开 DevTools。示例刻意制造了一些层叠与单位差异，便于演练两个面板的互补视角。

<!doctype html>
<meta charset='utf-8'>
<title>styles vs computed demo</title>
<style>
  :root { --brand: #e6007a; }
  body { font-size: 100%; }
  .container { width: 60%; margin: 40px auto; font-size: 125%; }
  .btn { 
    padding: 0.5rem 1rem; 
    border: 1px solid var(--brand); 
    color: #fff; 
    background: var(--brand);
  }
  /* 有意制造覆盖 */
  .theme-dark .btn { color: #aaa; background: #222; }
  /* 缩写与长属性可在 computed 观察到展开 */
  .card { margin: 10px 20px; border: 4px solid #ddd; padding: 8px; }
</style>

<div class='container theme-dark'>
  <h1>DevTools styles & computed</h1>
  <button class='btn'>Action</button>
  <div class='card'>Inspect me</div>
</div>

演练要点：

选中 .btn，在 Styles 看到两条规则：.btn 与 .theme-dark .btn，前者的 color 被划线。点击每条规则右上的文件名或 style 源链接，能跳转到来源。Chrome 文档指出，Elements 面板支持查看所有命中规则并快速定位源码。(Chrome for Developers)
切换 Computed，搜索 color，能看到最终值为 rgb(170, 170, 170)，并且右边能展开查看是哪条规则取胜；搜索 border 或 margin，可以观察缩写被拆解为四个方向的长属性。Chrome 文档强调 Computed 展示的是解决后的值与长属性列表。(Chrome for Developers)
修改 :root 的 --brand 或把外层容器移出 theme-dark 类，观察两个面板的差异如何同时反馈。

如果你还想把面板布局固定为侧边而不是底部，Chromium 系列浏览器提供了面板布局切换。官方说明了在设置里将 Panel layout 改为 Vertical 或 Horizontal 的方式以稳定布局，便于同时查看。(Chrome for Developers, Stack Overflow)

工作流建议：把过程与结果连成闭环

诊断 颜色/字号/间距 类的视觉偏差时，先看 Computed 是否与预期一致，再跳回 Styles 查找来源与冲突。Chrome 文档用一句话概括：Styles 看规则，Computed 看结果。(Chrome for Developers)
碰到 缩写覆盖 的陷阱（例如你只改了 margin-left，却又写了一个新的 margin: ...），在 Computed 里查看四向长属性能立刻暴露问题根源。(Chrome for Developers)
面向自动化或运行时自检，把 Computed 面板看到的内容用 window.getComputedStyle 在脚本里复刻，做断言或日志打印，减少只在肉眼下成立的假设。(MDN Web Docs)

概念补充：值从哪儿来，走向哪儿去

为了更精确地理解两者的输出，值得把规范中的值阶段放进思维模型。MDN 描述：作者或继承给出的 specified value，经过变量解析、相对单位换算等步骤，得到可继承的 computed value；浏览器在布局阶段再将其转为与渲染环境相关的 used/actual 值。Computed 面板对应的就是中间的 computed，而 Styles 呈现的则是你的 specified 及其层叠规则。(MDN Web Docs)

常见误区与纠偏

把 Computed 当作最终像素布局的绝对真相。注意：computed 仍可能保留某些相对性或待布局计算的信息，某些属性的最后一步会在布局阶段完成；不要把它与 actual/used 完全等同。用它来定位规则取胜与继承结果是恰当姿势。(MDN Web Docs)
只在 Styles 里看有无删除线，却忽略 @media 或容器查询条件。Styles 会把规则分块罗列，但是否命中与视口、容器大小相关；必要时改变条件或勾选伪类，观察生效路径。官方 Elements 概览强调它能让你查看与调试命中规则，并识别不生效 CSS。(Chrome for Developers)

一句话记忆法

把 Styles 想成 谁说了什么，把 Computed 想成 最后听谁的。需要追责时去 Styles，需要验收时看 Computed。Chrome 文档也给出同样的工作建议：要看真正应用到元素上的值，就用 Computed；要看原始声明与层叠上下文，就用 Styles。(Chrome for Developers)

延伸阅读
想更系统地练习查看与修改 CSS，Chrome 官方提供了交互式入门教程；配合上文的示例，你可以在真实页面上快速验证每个观察点。(Chrome for Developers)

小贴士
有时你会在 Computed 中看到 font-size 等值已经是像素化的明确值，而你在 Styles 里写的是百分比或 rem。这正是规范里 computed value 的定义使然，它在继承与变量解析后给你一个稳定、可传播的值，便于后续布局。(MDN Web Docs)

以上，就是把两扇窗合起来用的完整思维框架与可复现的演练方法。下次遇到 CSS 异常，用 Computed 快速确认结果，再借助 Styles 追溯来源，定位会轻松许多。

当你在 Elements 面板里犹豫不决：Styles 与 Computed 究竟谁在说真话？