CSS if()语句与自定义函数：媒体查询写法即将巨变

CSS 媒体查询是前端开发中最基础的响应式设计工具，但它的写法可能很快就会发生翻天覆地的变化。YouTube 知名前端博主 Kevin Powell 近期展示了 CSS 即将引入的 if() 语句和自定义函数（@function），这些新特性将彻底改变我们编写媒体查询的方式。

CSS 嵌套语法：媒体查询的第一步优化

在传统的 CSS 中，编写媒体查询时需要重复选择器，代码冗余且不够优雅。而现在，CSS 原生嵌套（Nesting）已经得到了广泛支持，我们可以将媒体查询直接嵌套在选择器内部，省去重复书写选择器的麻烦。

CSS 原生嵌套是 CSS Nesting Module 规范的一部分，于 2023 年开始在主流浏览器中获得支持。在此之前，嵌套写法一直是 Sass、Less 等 CSS 预处理器的专属能力，也是开发者选择预处理器的核心原因之一。原生嵌套使用 & 符号引用父选择器，允许在一个选择器块内部直接书写子选择器和媒体查询，从而消除了代码中大量的选择器重复。这一特性的落地标志着 CSS 正在逐步吸收预处理器的优秀设计理念，减少开发者对构建工具链的依赖。值得一提的是，CSS 嵌套的实现经历了语法上的反复讨论——早期草案要求所有嵌套规则必须以 & 开头，后来规范放宽了这一限制，允许直接以元素选择器开头嵌套，使语法更接近开发者在 Sass 中的使用习惯。截至 2024 年，Chrome 120+、Firefox 117+、Safari 17.2+ 均已支持原生嵌套，覆盖了全球超过 90% 的浏览器用户。

这虽然只是一个小改进，但它让代码结构更加清晰，减少了重复代码。不过，真正令人兴奋的变化还在后面。

CSS if() 语句：在属性值中直接写条件逻辑

未来的 CSS 将支持在属性值中直接使用 if() 语句。这意味着，如果你只有一个属性需要根据屏幕宽度变化，你可以完全抛弃传统的 @media 块，直接在属性值中写条件判断。

从规范层面来看，CSS if() 函数源自 CSS Values and Units Module Level 5 规范中的 Inline Conditionals 提案。与传统的 @media 规则不同，if() 是一个**值级别（value-level）**的条件函数，它可以出现在任何接受 CSS 值的地方。这意味着条件判断的粒度从「整个声明块」细化到了「单个属性值」。除了 media() 条件外，if() 还支持 supports()（特性检测条件）和 style()（样式查询条件），使其成为一个通用的内联条件机制，而不仅仅局限于响应式设计场景。这种设计思路实际上借鉴了编程语言中三元表达式的理念——就像 JavaScript 中的 condition ? valueA : valueB，CSS 的 if() 让开发者能够在值的层面进行条件选择，而不必为了改变一个属性值就编写一整个 @media 代码块。从工程角度看，这大幅降低了简单响应式场景下的代码量，尤其适合只需要对单个属性进行断点切换的情况。

具体写法类似于：

.container {
  flex-direction: if(media(width > 600px): row; else: column);
}

当视口宽度大于 600px 时，flex-direction 为 row（横向排列形成列布局）；否则为 column（纵向排列）。

目前这个特性已经可以在 Chrome 中使用，但其他浏览器的支持还不够完善。Kevin 也坦言，这种写法初看可能会让人觉得"有点奇怪、不太好读"——毕竟我们习惯了将媒体查询作为独立的代码块来编写，突然把条件逻辑塞进属性值里，确实需要一个适应过程。

CSS @function 自定义函数：真正的游戏规则改变者

如果说 if() 语句还略显生硬，那么 CSS 自定义函数（@function）则提供了一种更优雅的解决方案。你可以定义自己的函数来封装媒体查询逻辑，让代码既简洁又具有良好的可读性。

CSS @function 是 CSS Functions and Mixins Module 规范的核心组成部分。长期以来，CSS 中的函数（如 calc()、min()、max()、clamp()）都是浏览器内置的，开发者无法定义自己的函数。@function 打破了这一限制，允许开发者创建可复用的计算逻辑，接受参数并返回值。这与 CSS 自定义属性（Custom Properties，即 CSS 变量）形成互补——自定义属性解决了值的复用问题，而自定义函数则解决了逻辑的复用问题。值得注意的是，该规范还包含 @mixin 的提案，未来 CSS 可能原生支持类似 Sass mixin 的样式块复用能力。从技术演进的角度看，CSS 自定义函数的引入填补了 CSS 抽象能力的最后一块重要拼图。此前，开发者虽然可以通过自定义属性（--variable）实现值的复用，但无法封装包含条件判断的计算逻辑。在 Sass 等预处理器中，@function 和 @mixin 是构建设计系统（Design System）和组件库的基石——它们允许团队将断点值、间距比例、颜色计算等设计决策封装为可复用的抽象单元。CSS 原生 @function 的出现意味着这些能力将不再依赖编译步骤，可以在运行时动态响应环境变化，这是预处理器无法做到的。

以下是 Kevin 演示的具体实现思路：

@function --mq-small(--narrow, --wide) {
  result: if(media(width > 600px): var(--wide); else: var(--narrow));
}

这个函数接受两个参数：--narrow（窄屏时的值）和 --wide（宽屏时的值），内部通过 if() 语句判断当前视口宽度，返回对应的值。

使用时，代码变得极其简洁：

.container {
  flex-direction: --mq-small(--narrow: column, --wide: row);
}

你甚至可以为不同的断点定义不同的函数，比如 --mq-medium、--mq-large 等，形成一套完整的响应式工具函数库。这种方式的优势在于：

• 语义化：函数名直接表达意图，--mq-small 一目了然
• 复用性：定义一次，到处使用，断点值只需维护一处
• 可读性：参数命名清晰，narrow 和 wide 比裸写的像素值更易理解

这种模式实际上与软件工程中的 DRY（Don't Repeat Yourself）原则高度契合。在大型项目中，响应式断点往往散布在数十甚至数百个 CSS 文件中，一旦设计团队决定调整断点值（例如将移动端断点从 600px 改为 640px），开发者需要逐一修改所有相关的媒体查询。而通过 @function 封装断点逻辑后，只需修改函数定义中的一个数值即可完成全局更新，极大降低了维护成本。

这些 CSS 新特性对前端开发意味着什么

从声明式到函数式的范式转变

传统的媒体查询是"声明式"的——你在一个独立的代码块中描述不同条件下的样式。而新的 if() 和 @function 则将 CSS 推向了更"函数式"的方向，条件逻辑可以直接嵌入到属性值中。

在编程范式中，声明式（Declarative）编程关注「描述结果是什么」，而函数式（Functional）编程强调「通过函数组合来表达计算过程」。传统 CSS 是典型的声明式语言——你声明元素在某个条件下应该呈现什么样式，浏览器负责实现。引入 if() 和 @function 后，CSS 获得了函数式编程中的核心能力：条件分支和函数抽象。这种演进与 JavaScript 框架从命令式 DOM 操作转向声明式组件的趋势形成有趣的对照——前端技术栈的各层都在寻找声明式与函数式之间的最佳平衡点。从更宏观的视角来看，CSS 的这种演进并非孤立现象。回顾 CSS 近年来的发展轨迹，从 calc() 引入数学计算、到自定义属性实现变量机制、到 min()/max()/clamp() 提供比较函数、再到如今的 if() 和 @function，CSS 正在沿着一条清晰的路径逐步获得图灵完备语言的部分特征。当然，CSS 的设计哲学决定了它不会也不应该变成一门通用编程语言——它的核心使命仍然是样式描述，但在这个边界内，更强的表达力意味着更少的对外部工具的依赖和更高的开发效率。

这种转变有利有弊。好处是代码更紧凑，相关的样式逻辑集中在一起，不需要在文件中来回跳转查看不同断点下的样式。潜在的问题是，当一个选择器下有大量属性需要响应式变化时，每个属性都写一个 if() 可能反而不如传统的 @media 块清晰。

浏览器支持现状

需要注意的是，这些特性目前仍处于早期阶段。if() 语句在 Chrome 中已经可用，但 Firefox 和 Safari 的支持尚未跟上。@function 的支持范围可能更窄。因此，在生产环境中使用这些特性还为时尚早，但作为技术储备和学习方向，现在了解它们非常有价值。

浏览器对新 CSS 特性的支持通常遵循一个渐进过程：先由某个浏览器引擎（通常是 Chrome 的 Blink 引擎）率先实现实验性支持，随后 Firefox 的 Gecko 引擎和 Safari 的 WebKit 引擎跟进。在所有主流浏览器达成一致支持之前，开发者可以使用 @supports 规则进行特性检测，实现渐进增强（Progressive Enhancement）。对于 if() 和 @function 这类新特性，一个务实的策略是：在个人项目和原型中积极实验，在生产环境中保留传统媒体查询作为回退方案，同时关注 Can I Use 等平台上的兼容性数据更新。历史经验表明，从一个浏览器率先支持到所有主流浏览器全面支持，通常需要 1-3 年的时间。以 CSS Grid 为例，Chrome 于 2017 年 3 月率先支持，Firefox 紧随其后，Safari 在同年 9 月跟进，但直到 2018 年底 Edge 切换到 Chromium 内核后，开发者才真正开始在生产环境中大规模采用。CSS if() 和 @function 可能会经历类似的周期，但考虑到当前浏览器厂商之间的协作比以往更加紧密（尤其是通过 Interop 项目的推动），这个过程有望加速。

与 Tailwind CSS 等框架的关系

如果你熟悉 Tailwind CSS 或其他原子化 CSS 框架，会发现这种"内联条件"的思路与它们的响应式前缀（如 md:flex-row）有异曲同工之妙。CSS 原生能力的增强，某种程度上也在缩小原生 CSS 与工具框架之间的差距。

Tailwind CSS 等原子化（Utility-First）CSS 框架的核心理念是将样式原子化为单一用途的类名，通过组合类名来构建界面。其响应式设计采用前缀约定（如 sm:、md:、lg:），本质上是将媒体查询的断点逻辑编码到类名中。CSS 原生 if() 和 @function 的出现，使得原生 CSS 也能以类似的内联方式处理响应式逻辑，但两者的抽象层次不同：框架在 HTML 层面提供便利，而原生特性在 CSS 层面增强表达力。这并不意味着框架会被取代——框架还提供了设计系统约束、开发体验优化、构建时优化等原生 CSS 尚未覆盖的价值。事实上，CSS 原生能力的增强与框架的发展往往是相互促进的关系。Tailwind CSS 的流行证明了开发者对内联式、组合式样式编写方式的强烈需求，这种需求反过来推动了 CSS 标准的演进。同样，当 CSS 原生支持了更多高级特性后，框架也会相应调整自身的定位和实现方式。例如，Tailwind CSS v4 已经开始利用 CSS 原生嵌套和级联层（@layer）来优化其输出代码。未来，随着 if() 和 @function 的普及，我们可能会看到新一代 CSS 框架直接基于这些原生特性构建，而不是通过编译时生成大量的媒体查询代码块。

总结

CSS 正在经历一场深刻的进化。从原生嵌套到 if() 语句，再到自定义函数 @function，这些新特性正在让 CSS 变得更加强大和灵活。媒体查询的写法可能很快就会和我们今天习惯的方式大不相同。

虽然这些变化需要时间来被广泛采用，但它们代表了 CSS 发展的明确方向——更少的重复、更强的表达力、更接近编程语言的抽象能力。作为前端开发者，现在正是开始关注和实验这些新特性的好时机。

核心要点