写这篇文章的起因是我最近在整理一个老项目时又翻到了瓶颈期常见的场景同一套页面在手机、平板、桌面上的信息层级完全不同。有的模块在桌面端是核心到了移动端却是干扰项有的按钮只该在触屏上出现鼠标操作时反而碍事。这种“同一套DOM不同设备给不同体验”的需求我最早是用手写媒体查询自定义class一版一版堆出来的代码里到处是display:block和display:none的临时补丁维护起来极其痛苦。后来接触到 Foundation CSS 里那套成体系的可见性工具类才意识到这些看起来不起眼的 className背后其实是一套完整的响应式显隐设计哲学。这篇内容我就围绕“Foundation CSS 可见性”这个核心把它的类名体系、断点逻辑、实操姿势、以及我实际踩过的坑一次性讲透。不管你是刚接触 Foundation还是已经在用但没细研究过这套工具类相信都能找到值得“抄作业”的地方。1. 为什么需要一套专门的“可见性”工具类1.1 响应式开发中“显示/隐藏”的痛点做响应式页面最麻烦的不是布局而是“同一个内容在不同屏幕下怎么呈现”。举个例子一个商品列表页桌面端可以展示四列每列有详细的规格参数平板端降成两列可能要隐去部分说明文字到了手机端整个表格形态的结构基本就废了得换成卡片式布局。这时候你面临的选择很现实要么写多套HTML结构用JS去切换要么共用一套DOM用CSS在不同断点下控制哪些区域可见。第一种方案听起来干净实际上维护成本极高。两套结构意味着后端要输出两份数据前端要维护两份事件绑定出一次需求变更改动范围直接翻倍。我在真实项目里见过因为这种做法导致的线上事故——桌面端和移动端展示的数据不一致用户投诉了几天才定位到是切换逻辑漏了某个状态。第二种方案比较靠谱但如果你用手写媒体查询的方式去实现会陷入另一个泥潭每个模块都要自定义一套类名类名之间还没有统一的命名规范。今天写了.desktop-only明天写了.mobile-hide后天新同事又来了一个.show-on-pc。团队里每个人都在用自己的规则做同样的事最后样式表里全是冲突和黑魔法改一处崩三处。1.2 Foundation 的可见性工具类解决什么问题Foundation CSS 的可见性工具类就是把“在不同断点下显示/隐藏元素”这件事做成了标准化的、可预测的、开箱即用的类名体系。你不用再自己设计类名不用再纠结断点阈值怎么定只需要在 HTML 上添加show-for-medium、hide-for-small-only这种语义清晰的 class剩下的交给框架的 CSS 处理。我把它跟手写方案的差异总结成一张表方便你直观理解对比维度手写媒体查询方案Foundation 可见性工具类命名规范团队内自定容易冲突官方统一语义明确断点管理每个模块都要重写阈值框架统一管理改一处全局生效维护成本样式分散改动风险高类名即文档所见即所得屏幕阅读器支持需要自己处理内置 sr-only 辅助类移动端优先策略需要自己约束show-for-*/hide-for-*天然支持当然工具类不是银弹它解决的是“显隐”这一个维度的诉求。但它把最常出问题的这一环标准化了让团队里不同水平的人写出来的代码至少在类名层面是一致的。这一点对项目长期维护的价值远超过省下来的那几行 CSS。2. Foundation CSS 可见性核心类名与使用解析2.1 核心类名体系show-for / hide-for 与断点后缀Foundation 的可见性类名看起来絮叨但其实有非常清晰的语法结构。主体是show-for或hide-for后面跟断点名称断点名称又分“精确匹配”和“范围匹配”两种。先看常见断点名称Foundation 6 默认配置大约是small小屏手机、medium平板、large桌面、xlarge大桌面、xxlarge超大屏幕。每个断点后面还可以追加-only表示“仅仅在该断点区间生效”。我刚开始用的时候觉得这套命名太长了直到真正理解了它的设计意图才明白长是为了消歧义。举个例子show-for-medium元素只在medium及以上的屏幕显示small屏不显示。show-for-medium-only元素只在medium这个区间显示比它小的不显示比它大的也不显示。这两个类名只差一个-only但效果完全不同。如果你自己设计类名大概率会用show-medium和show-medium-only看起来更短但读代码的人很容易忽略-only的存在。Foundation 用这种啰嗦的写法反而是把“范围限制”这件事钉进了类名里减少了误读的可能。hide-for的规则与show-for正好互补hide-for-medium表示在medium及以上隐藏hide-for-medium-only表示仅仅在medium区间隐藏其他区间正常显示。2.2 辅助类show-for-sr、show-for-focus、show-for-landscape 等除了按断点显隐Foundation 这套体系还覆盖了几个容易被人忽略的场景。第一个是屏幕阅读器。在实际开发中我们经常遇到需要隐藏视觉、但保留给读屏软件的内容例如表单的隐藏标签、按钮的功能描述。这个需求如果自己实现需要写一段 clip 相关的 hack很多人都记不全。Foundation 直接提供了show-for-sr类一行 class 搞定内部代码已经处理好了视觉隐藏和读屏可见的细节。show-for-focus是show-for-sr的增强版适合做“跳过导航”这类链接平时隐藏键盘聚焦时显示。它解决了无障碍设计中特别常见的需求而大多数 CSS 框架都忽略了这一点要么只提供 sr-only要么需要开发者自己额外写 focus 状态的样式。还有show-for-landscape、show-for-portrait这种针对设备方向的工具类。虽然现在手机自适应方向做得不错但在某些特定场景比如横屏展示视频列表、竖屏显示聊天界面依然有使用价值。show-for-dark和show-for-light则是配合主题切换用的元素会根据系统或父容器的亮暗主题自动显隐在暗色模式适配中很实用。2.3 类名对照表与断点边界为了让你一眼看懂这套体系我把常用类名按断点整理成一张表。注意不同小节会围绕“断点边界”展开解释。你想要的显隐行为类名写法仅在小屏手机显示show-for-small-only小屏隐藏即中等及以上显示hide-for-small等价于show-for-medium仅在中等屏平板显示show-for-medium-only中等以上显示show-for-medium中等及以下显示show-for-medium-down旧版写法新版已弃用请用hide-for-large替代仅在桌面显示show-for-large-only大屏以上显示show-for-large大屏隐藏hide-for-large超大屏以上显示show-for-xlarge横屏时显示show-for-landscape竖屏时显示show-for-portrait屏幕阅读器可见show-for-sr聚焦时可见show-for-focus打印时可见show-for-print打印时隐藏hide-for-print关于断点边界Foundation 默认采用“向上兼容”的移动优先思路未加显隐类时元素在 JS 和 CSS 层面都默认可见一旦加了show-for-*就等同于告诉浏览器“这个元素有自己的显示策略”。断点的具体像素阈值在不同版本间会有差异以 6.x 为例大致是small为 0 到 639pxmedium为 640px 到 1023pxlarge为 1024px 到 1439pxxlarge为 1440px 及以上。但这里的边界值本质上是参考Foundation 内部用 em 单位计算在根字号为 16px 时39.9375em约等于639px64em约等于1024px。这种处理是为了适配浏览器缩放和不同根字号设置避免因为用户放大字体导致布局错乱。3. 实操过程从引入框架到实现响应式显隐3.1 最小环境搭建只有 CSS 也能跑起来很多人以为用了 Foundation 就要引入整套框架其实“可见性”这个需求只依赖 Foundation 的 CSS 部分连 JavaScript 都可以不加载。如果你用 npm 构建项目直接安装foundation-sites然后在入口文件中引入scss/util/visibility相关模块即可。但如果你只是想在普通 HTML 页面里快速用起来更省事的方式是引入 Foundation 的 CDN 样式文件。下面是完整的最小示例可以直接复制到本地看效果!DOCTYPE html html langzh-CN head meta charsetUTF-8 meta nameviewport contentwidthdevice-width, initial-scale1.0 titleFoundation Visibility 最小示例/title !-- 这里以 Foundation 6 的 CDN 为例实际引入时建议锁定具体版本号 -- link relstylesheet hrefhttps://cdn.jsdelivr.net/npm/foundation-sites/dist/css/foundation.min.css style /* 为了演示效果给示例区块加一点背景色 */ .demo-box { padding: 16px; margin: 8px 0; border: 1px solid #cacaca; border-radius: 4px; } /style /head body div classdemo-box show-for-small-only只有小屏手机才显示我/div div classdemo-box show-for-medium中等屏及以上显示小屏隐藏我/div div classdemo-box hide-for-large大屏及以上隐藏我其他屏都能看到/div div classdemo-box show-for-sr我看不见但屏幕阅读器能读到我/div /body /html这段代码里没有一行自定义媒体查询却已经实现了三种显隐策略。而且你拖动浏览器窗口大小就能看到每个区块根据断点出现的实时变化。这种“开箱即用”的体验正是框架类工具最大的价值。3.2 完整示例导航栏、表格、图片与表单的实战显隐单纯的 div 展示没有说服力我模拟一个真实业务页面把这套工具类用进常见模块。假设你在做一个商品管理系统页面里包含侧边导航、数据表格、商品缩略图、快捷操作表单。侧边导航在移动端占空间通常的做法是隐藏掉用一个按钮触发抽屉。我可以在导航容器上直接使用hide-for-small-only然后在抽屉内使用另一套导航结构同时在移动端固定一个悬浮按钮。nav classsidebar hide-for-small-only !-- 桌面端的完整侧边导航 -- ul li商品管理/li li订单管理/li li用户管理/li /ul /nav a classmobile-menu-button show-for-small-only href#mobile-drawer打开菜单/a数据表格是移动端适配的重灾区。Foundation 的表格本身有响应式方案但如果你只想在窄屏时隐藏掉某些不重要列工具类就很方便。例如“最后编辑时间”这一列在手机上不是核心信息直接table thead tr th商品名称/th th价格/th th classhide-for-small-only安全库存/th th classhide-for-small-only最后编辑时间/th /tr /thead tbody tr td测试商品/td td¥99.00/td td classhide-for-small-only20/td td classhide-for-small-only2025-06-15 10:30/td /tr /tbody /table这样在小屏下表格自动只保留商品名称和价格信息密度刚好适合手指滑动。图片缩略图区域移动端可以显示稍大一些的预览桌面端反而展示更多小图。我经常用show-for-medium-only来控制在平板上的特殊排布。至于快捷操作表单比如“批量上架”“导出报表”这些操作桌面端可以全部展示移动端只留一个“更多”按钮按钮在small下显示其他操作列在medium以上才展开。这些都是同一套类名在不同场景下的复用。3.3 自定义断点与覆盖样式的几种姿势Framework 默认断点不一定匹配你的业务。比如某些后台系统桌面宽度可能是 1280px而你希望在 1366px 以上才展示某个侧栏。这时候不需要推翻整套体系用 SCSS 重新覆盖断点配置即可。Foundation 的变量文件里定义了$breakpoints映射表像下面这样调整// foundation 的变量覆盖写在引入 Foundation 之前 $breakpoints: ( small: 0, medium: 720px, large: 1200px, xlarge: 1440px, xxlarge: 1920px, ); import foundation-sites/scss/foundation;如果你用的是纯 CSS 的 CDN 文件没法直接改 SCSS 变量需要自己写覆盖样式。这时候要注意优先级问题。Foundation 的可见性类大多基于媒体查询并且不少类带有!important。如果你用自己的 class 去覆盖注意要选择合适的优先级例如/* 自定义覆盖示例 */ media screen and (min-width: 1366px) { .custom-sidebar { display: inline-block !important; } }“为什么这里还要写!important”因为 Foundation 工具类的规则已经加了!important如果你不这样做自己的类名优先级就算更高也容易被框架样式压制。这种情况搁在手写方案里根本不会出现但用了框架就要接受它的设计风格这也算是一个实战经验了。还有一种覆盖姿势是直接改元素上的多个类。比如框架默认规则是show-for-medium但某个页面你希望这个元素只在large下显示那就把类名改成show-for-large没必要额外写覆盖样式。类的语义化在这里就体现出来了改 HTML 就能完成逻辑调整不需要进 CSS。4. 常见问题排查与避坑实录4.1 样式不生效优先级、顺序、important这类工具类用多了最常遇到的坑就是“我加了show-for-medium怎么没反应”。排查思路按顺序来先确认是不是类名拼错了。Foundation 的类名很长show-for-medium-only和show-for-medium差一个-only表现完全不同多一个少一个都可能导致行为不符合预期。再看是不是断点卡在临界值。比如浏览器窗口刚好在 1023px 和 1024px 之间如果你的设计稿和 Foundation 的断点表不一致视觉上会觉得“怎么这个元素闪来闪去”。这种情况建议在开发工具里精确调整窗口宽度找到断点临界位置确认是断点阈值问题还是样式覆盖问题。最常见也最隐蔽的是自定义样式覆盖问题。如果你的项目里没过其他 CSS 文件里面写了类似.card { display: block; }这种规则而且加载顺序在 Foundation 之后那它可能就把 Foundation 的显隐规则盖住了。针对这种情况最简单的处理方式是给覆盖规则加上!important或者在设计时就约定与显隐相关的业务类名不放在 Foundation 之后引入。我习惯在开发规范里写明一条铁律凡是涉及到响应式显示/隐藏的元素一律使用 Foundation 的可见性工具类不允许自定义display:none的类去覆盖框架规则。遵守这条能省下大量调试时间。4.2 移动端优先 vs 桌面端优先的类名选择“显隐”写起来容易难的是在“移动优先”和“桌面优先”之间做决策。Foundation 的这套类名设计更倾向于移动优先默认元素可见用hide-for-small-only去缩小屏上的内容用show-for-medium去增强大屏体验。这种思路的优势在于你不需要在移动端额外写很多“显示”逻辑因为默认就是全部显示只需要考虑哪些内容在小屏上不必要。不过真实项目经常有例外。比如营销活动页桌面端的视觉重点是主视觉大图移动端可能只需要一个小尺寸的 banner。如果按照移动优先你要在桌面端额外写一套大图在移动端再写一套小图还要用hide-for-small-only和show-for-small-only分别控制。这也不算难但要求你一开始就想清楚内容优先级别到最后临上线了才补那时候类名就会堆得非常散乱。我给的选型建议是默认内容结构始终保持“信息完整”即所有屏幕都能看到最核心的内容。只在非核心元素上使用显隐工具类。如果一个模块在移动端不展示那它在移动端的价值一定是很低的比如复杂的批量操作、大屏报表等。反过来如果一个模块在桌面端不展示那它通常是因为触屏交互对桌面端用户没有意义比如摇一摇、手势滑动等。遵循这个原则就不会出现“桌面端很好的内容在手机端消失用户抱怨找不到”的问题。4.3 可见性工具类与 CSS Grid / Flex 的协作陷阱现代页面大量使用 Flex 和 Grid 布局这时候工具类的工作方式会有点微妙。display:none和visibility:hidden的区别在 Flex 布局里表现得比传统布局更明显display:none会让元素完全脱离布局流后面的兄弟元素会顶上来visibility:hidden只是隐藏视觉元素本身还占着位置看起来就像留了一个“空洞”。Foundation 的工具类底层用的是display: none和display: block这一类的方式所以当一个 Grid 容器里某个子元素被隐藏时网格布局会自动重排剩下的元素重新填充网格轨道。这表面上看是好事但有坑如果你给 Grid 子元素设置了grid-row或grid-column的显式定位隐藏其中一个元素后其他元素的占位并不一定按顺序填充可能留下一个空白单元格。我踩过的一个真实坑一个商品卡片网格用了grid-template-columns: repeat(3, 1fr)第三个商品在移动端被hide-for-small-only隐藏了结果第二个和第四个商品并没有顺序排列成两列而是中间出现了一个空位。原因就是第四个商品设置了grid-column-start,它被指定到了第4格。解决办法是在响应式显隐的同时也要让 Grid 子元素的显式定位跟着断点变化或者干脆用 Flex 换行布局避免固定位置带来的重排问题。所以在使用这套工具类前建议先想清楚容器布局如果是简单的流式布局随便用如果是 Grid/复杂 Flex 布局务必检查隐藏后的重排行为。4.4 关于新版 Foundation 与旧版的区别不少老项目里的代码还是 Foundation 5 时代的写法比如show-for-medium-down、hide-for-medium-up这种后缀。到了 Foundation 6官方对可见性类名做了升级不再推荐使用-up/-down后缀统一用-only和没有后缀的断点名来表示范围。如果你在升级框架项目里的旧类名可能不会直接生效。我整理了一个新旧对照方便你在升级的时候快速替换旧版写法Foundation 5 及更早新版推荐写法Foundation 6 及以后show-for-medium-upshow-for-mediumshow-for-medium-downhide-for-largehide-for-medium-uphide-for-mediumhide-for-medium-downshow-for-large这里有个容易混淆的点旧版的show-for-medium-down表示“medium 及以下显示”在新版里为什么不直接用show-for-medium-down而要用hide-for-large因为新版的类名体系更想让开发者以“向上兼容”的思维考虑问题medium 及以下显示等价于 large 以上隐藏。虽然逻辑等价但语义上新版更鼓励你从“什么情况下要隐藏”的角度思考而不是把所有显隐条件都写成一个正向表达式。这种转换刚开始有点反直觉但用久了会觉得命名更干净不容易出现两层意思叠加过深的情况。如果你还在维护老项目又没有升级框架的计划那旧类名也还能用只是要清楚它未来的可持续性。我的建议是至少在新写的模块里直接使用新版类名避免老项目越来越难迁移。4.5 一个容易被忽略的点与 Sass 变量协同定义断点阈值用了 Foundation 的 SCSS 版本断点阈值可以全局一次性配置这很舒服。但随之而来的坑是如果你在项目里只是用 CDN 的 CSS而团队的设计规范里某些组件有自己的断点那么你会在媒体查询中频繁手写media (min-width: 960px)这类代码。这就形成了两套断点体系混用的情况——Foundation 的体系管工具类你自己的体系管业务样式。短期看没问题时间长了断点阈值会越来越分散。我建议在项目初期就把断点梳理成一份“响应式断点对照表”并且明确哪些区域用 Foundation 工具类哪些区域允许自定义媒体查询。比如页面级的布局外壳用自定义媒体查询内容级别模块的显隐全走工具类。这样一来两类样式互相不干扰排查问题时也能快速定位。写在最后一点个人使用体会这套可见性工具类单独抽出来看每一个类名都很简单但它最大的价值在于强迫你用一种统一的思维去规划响应式行为。在我自己的项目里一旦团队接受了它的类名规范大家写出来的页面在“什么内容在什么屏幕下可见”这件事上几乎不需要开评审会了因为类名已经把规则说清楚了。最后分享一个我在实际使用中的小习惯只要涉及显隐我都会在元素的 HTML 注释里写一行说明——为什么这个模块在某个断点下要隐藏。框架的类名虽然表达了“怎么做”但不会表达“为什么这么做”。这行注释对后来的维护者也包括三个月后的我自己来说真的能节省很多猜谜时间。如果你正在处理复杂的响应式页面不妨先别急着写那一堆自定义媒体查询花一个下午把 Foundation 的可见性类名过一遍大概率能替你省下后面无数个加班的夜晚。