2026年前端CSS选型实战指南：BEM、CSS-in-JS与Tailwind决策树

1. 这不是技术选型指南而是一份前端团队三年踩坑实录我带过三个不同规模的前端团队从百人电商中台到二十人初创 SaaS再到十人内部工具组。2021 年我们还在用 BEM 写 CSS2022 年强行上 CSS-in-JS 被 React Server Components 打得措手不及2023 年在 Tailwind 上重构了三套系统后终于敢说没有“最好”的 CSS 方案只有“最不痛”的当下解法。标题里那个“2026 年到底该怎么选”问得特别实在——不是问理论优劣是问你现在手头这个项目、这个团队、这个交付周期明天早上 standup 时该拍板用什么。BEM 不是过时了是它解决的问题命名冲突、样式隔离在组件化时代被拆解了CSS-in-JS 也没死只是它承诺的“样式即逻辑”在服务端渲染和微前端里变成了负债Tailwind 更不是银弹当你的设计系统有 47 种按钮变体、12 套主题配色、3 层响应式断点嵌套时classbg-blue-500 hover:bg-blue-600 active:bg-blue-700 disabled:opacity-50 sm:px-4 md:px-6 lg:px-8这种写法会直接拖垮代码审查效率。真正决定选型的从来不是框架文档里的性能 benchmark而是你团队里 junior 开发者改一个按钮圆角要花多少分钟、designer 提供的 Figma 变体能否一键映射到 class、CI 流水线里样式 diff 的误报率有多高。这篇文章不讲“BEM vs Tailwind”的哲学辩论只记录我们如何用真实项目数据不是 benchmark是 Jira 工单耗时、Code Review 拒绝率、Lighthouse 样式加载阻塞占比倒推选型逻辑。如果你正为新项目纠结技术栈或者被老项目里混杂的三种 CSS 方案折磨得睡不着这篇就是为你写的。2. 架构演进不是线性升级而是问题域的迁移与拆解2.1 BEM 的黄金年代解决的是“全局污染”这个具体痛点2015 年我们做第一个大型后台系统时CSS 最大的敌人是#header .nav li a:hover这种选择器。当时团队刚从 jQuery 单页应用转型HTML 结构由后端模板拼接前端只负责局部交互。一个common.css文件被全站引入设计师给的 UI 稿里“用户列表页的删除按钮”和“订单详情页的删除按钮”长得一模一样但开发随手写了.delete-btn { color: red; }结果首页的“删除购物车商品”按钮也变红了。BEM 的价值根本不是“语义化”而是用命名规则制造物理隔离.user-list__delete-btn和.order-detail__delete-btn在源码层面就不可能冲突。我们当时定的规则极其粗暴Block 名必须是业务模块名user-list,product-cardElement 名必须是 Block 内原子级元素__header,__body,__footerModifier 名必须是布尔状态或枚举值--disabled,--size-large这套规则能跑通是因为我们刻意回避了两个难题一是动态样式生成比如根据用户等级显示不同颜色的 badge二是跨 Block 复用比如所有卡片都需要统一的阴影效果。前者我们用 JS 动态切换 modifier 类名解决后者我们复制粘贴.card--shadow到每个 Block 里。这听起来很蠢但在当时避免样式泄漏的收益远大于维护成本。BEM 的本质是“用命名空间换确定性”它把 CSS 的不确定性选择器权重、继承链锁死在文件边界内。直到 2020 年我们接入微前端主应用和子应用共用同一份 CSSBEM 的命名空间才第一次失效——子应用的.user-list__delete-btn依然能覆盖主应用的同名类。2.2 CSS-in-JS 的爆发当组件成为第一公民样式必须跟着搬家2021 年我们启动新电商平台技术栈全面转向 React TypeScript。这时 BEM 的裂缝开始扩大一个ProductCard组件需要根据库存状态显示不同背景色设计师要求“缺货时背景渐变色从左到右由灰变透明”。BEM 要求我们写.product-card--out-of-stock但这个 modifier 的触发条件是props.inventory 0逻辑和样式耦合在 JS 里却要靠 class 名传递状态。更糟的是我们用了 Storybook 做组件库设计师在 Storybook 里看到的ProductCard样式和实际页面里因为父组件传入不同 props 渲染出的效果不一致——因为 BEM 的 class 是静态的而状态是动态的。CSS-in-JS 就是为解决这个矛盾诞生的。我们选了 Emotion不是因为它性能最好而是它的css函数能无缝嵌入 JSXconst ProductCard ({ inventory }) { const bgColor inventory 0 ? linear-gradient(90deg, #999, transparent) : #fff; return ( div css{css background: ${bgColor}; border-radius: 8px; padding: 16px; } {/* content */} /div ); };这里的关键不是“样式写在 JS 里”而是样式逻辑和组件逻辑共享同一套状态变量。当inventory改变时bgColor自动重算无需手动管理 class 切换。我们还用 Emotion 的media支持实现了真正的响应式css media (min-width: 768px) { display: grid; grid-template-columns: repeat(3, 1fr); } media (min-width: 1024px) { grid-template-columns: repeat(4, 1fr); } 这比媒体查询写在独立 CSS 文件里强得多——组件的响应式逻辑完全内聚。但代价很快显现2022 年我们上线 SSR发现 Emotion 生成的 class 名在服务端和客户端不一致导致 FOUCFlash of Unstyled Content2023 年接入微前端子应用的 Emotion 样式注入顺序无法控制经常覆盖主应用的全局重置样式。CSS-in-JS 的核心假设是“组件即应用”当这个假设被微前端、SSR、Web Components 打破时它的优势就变成了枷锁。2.3 Tailwind 的崛起不是放弃抽象而是把抽象层移到设计系统2023 年我们重构内部 BI 系统团队里来了两位资深 UI 工程师。他们看了我们用 Emotion 写的DashboardCard组件第一句话是“你们的css函数里写了 12 行样式其中 8 行是padding,margin,border-radius,shadow—— 这些本该是设计系统的原子规则为什么每个组件都要重复写” 这句话点醒了我们。Tailwind 的本质不是“写 class 而不是写 CSS”而是把 CSS 的抽象层级从开发者手中交还给设计系统。我们不再定义.card { padding: 1rem; border-radius: 0.5rem; box-shadow: 0 2px 4px rgba(0,0,0,0.1); }而是让设计系统规定p-4padding: 1rem对应设计规范里的“标准间距”rounded-lgborder-radius: 0.5rem对应“大圆角”shadow-mdbox-shadow: 0 2px 4px rgba(0,0,0,0.1)对应“中等阴影”然后在组件里直接组合div classNamep-4 rounded-lg shadow-md bg-white h3 classNametext-lg font-semibold text-gray-900销售概览/h3 div classNamemt-2 flex items-center justify-between span classNametext-2xl font-bold text-blue-600¥24,567/span button classNamepx-3 py-1 bg-blue-500 text-white rounded text-sm hover:bg-blue-600 transition-colors 查看详情 /button /div /div这种写法的革命性在于样式决策权从开发者回归到设计师。当设计师说“所有卡片统一用大圆角”我们不需要 grep 全局代码改border-radius只需要确保rounded-lg的定义不变当需要新增“超大圆角”时设计系统扩展rounded-xl所有用到它的组件自动生效。我们用 Tailwind 的layer机制把设计系统规则分层/* src/styles/tailwind.css */ tailwind base; tailwind components; tailwind utilities; layer components { .btn-primary { apply px-4 py-2 bg-blue-600 text-white rounded font-medium hover:bg-blue-700 transition-colors; } .btn-secondary { apply px-4 py-2 border border-gray-300 text-gray-700 rounded font-medium hover:bg-gray-50; } }这样既保留了 Tailwind 的原子性又通过apply封装了业务语义。Tailwind 不是消灭 CSS而是把 CSS 的复杂度转移到设计系统治理上——这正是 2026 年前端团队的核心能力。3. 2026 年的选型决策树用四个真实维度代替“哪个更好”3.1 维度一团队成熟度——别让 juniors 为架构买单我们做过一个残酷实验让 5 名入职不满 6 个月的 junior 开发者分别用 BEM、Emotion、Tailwind 实现同一个“带状态切换的 Tab 组件”。结果如下方案平均完成时间Code Review 拒绝率主要问题BEM42 分钟60%class 名拼错tab__item--active写成tab__item-active、modifier 未覆盖所有状态Emotion58 分钟80%css函数里忘记加;导致编译失败、媒体查询嵌套错误、样式优先级冲突!important滥用Tailwind28 分钟20%flex和grid混用导致布局错乱、响应式断点写错md:写成sm:关键发现Tailwind 对 junior 最友好但前提是团队有清晰的 Tailwind 配置和设计系统文档。我们给新人配的不是“Tailwind 教程”而是三样东西一份tailwind.config.js注释版标出哪些配置是设计系统强制项如spacing: { 4: 1rem, 8: 2rem }一张 A4 纸打印的常用 class 速查表p-4,m-2,text-lg,bg-red-500等 50 个高频 classStorybook 里每个原子组件的 Tailwind class 映射表如Button组件的variantprimary对应bg-blue-600 hover:bg-blue-700而 BEM 要求新人理解 Block/Element/Modifier 的哲学Emotion 要求新人掌握 CSS-in-JS 的生命周期服务端渲染时css函数执行时机。2026 年的现实是团队扩张速度远快于架构演进速度。如果你的团队平均司龄低于 18 个月Tailwind 是唯一能降低认知负荷的选择。反之如果团队有 3 名以上 CSS 专家BEM 的可预测性反而能减少线上样式 bug——我们某个金融后台系统坚持用 BEM因为它的样式变更必须经过 QA 逐像素验收任何意外样式泄露都是 P0 事故。3.2 维度二交付节奏——紧急需求下哪套方案能最快上线去年双十一前两周运营突然要求首页增加“限时秒杀”横幅要求 48 小时上线。我们对比了三种方案的落地路径BEM 方案新建promo-bannerBlock定义__content,__timer,__ctaElements为--countdown,--sold-outModifiers 写 CSS在首页 HTML 中插入div classpromo-banner promo-banner--countdown耗时6.5 小时主要卡在 BEM 命名评审和 CSS 重置兼容性测试Emotion 方案新建PromoBanner组件用css函数写样式动态计算倒计时用useEffect处理倒计时逻辑耗时3.2 小时但上线后发现 SSR 下倒计时初始值为空导致首屏无内容紧急 hotfixTailwind 方案直接在首页 JSX 里写div classNamebg-gradient-to-r from-orange-400 to-red-500 text-white p-4 flex items-center justify-between div classNameflex items-center space-x-2 span classNamefont-bold 限时秒杀/span span classNametext-sm bg-black bg-opacity-20 px-2 py-1 rounded最后 2 小时/span /div button classNamebg-white text-red-600 px-4 py-2 rounded font-bold hover:bg-gray-100 transition-colors 立即抢购 /button /div耗时47 分钟包括设计师确认配色是否符合品牌规范结论很现实Tailwind 在紧急需求下胜出但它的胜利建立在设计系统已就绪的前提下。如果这是你第一次用 Tailwind临时查文档、试配色、调间距时间可能翻倍。而 BEM 的“慢”恰恰是它的优势——强制你思考 Block 边界避免未来三个月的维护债。2026 年的项目管理现实是80% 的需求变更发生在上线前 72 小时。你的 CSS 架构必须回答一个问题当产品经理凌晨两点发来新需求截图你的团队是能立刻开干还是先开一场架构评审会3.3 维度三技术栈约束——别让 CSS 方案拖垮整个技术决策我们曾为一个政府项目选型技术栈要求必须支持 IE11虽然 2026 年这很荒谬但真实存在后端是 Java Spring Boot前端资源走 CDN不允许 JS 动态注入样式安全审计要求所有 CSS 必须静态分析禁止运行时生成 class这三条直接封杀了 CSS-in-JS 和 Tailwind 的 JIT 模式。我们最终用 BEM PostCSSBEM 解决命名冲突PostCSS 插件postcss-custom-properties处理 CSS 变量降级postcss-preset-env自动添加 IE11 兼容前缀所有样式文件预编译CDN 返回纯 CSS另一个极端案例我们接入一个基于 Web Components 的遗留系统。它的 Shadow DOM 隔离了样式BEM 的 class 名在 Shadow Root 里完全无效Emotion 的css函数生成的 class 无法穿透 Shadow DOM只有 Tailwind 的layer base可以通过:host伪类注入全局样式layer base { :host { --tw-bg-opacity: 1; background-color: rgb(255 255 255 / var(--tw-bg-opacity)); } }2026 年的技术现实是前端不再是单一技术栈而是混合生态。你的 CSS 方案必须能回答它能否在微前端子应用里独立运行能否在 SSR 场景下保证首屏样式稳定能否与 Web Components 共存能否被 Cypress 的样式快照测试覆盖这些不是“高级功能”而是 2026 年的 baseline 要求。3.4 维度四长期维护成本——用数据量化“技术债”我们统计了过去三年三个项目的样式相关工单项目技术栈平均每月样式相关 bug 数平均修复时间主要类型电商后台BEMBEM Sass2.318 分钟class 名冲突、modifier 漏写、媒体查询覆盖不全SaaS 平台EmotionEmotion React5.742 分钟SSR 样式不一致、动态样式计算错误、CSS-in-JS 依赖版本冲突BI 系统TailwindTailwind Next.js1.19 分钟响应式断点错用、设计系统更新后 class 未同步、JIT 模式缓存失效关键洞察Tailwind 的 bug 数最少但它的“bug”本质是设计系统治理问题。比如设计师更新了主色调要求所有bg-blue-500改为bg-indigo-600我们需要全局替换并验证所有组件。这看起来是运维工作实则是设计系统健康度的晴雨表。而 BEM 的 bug 多是人为失误Emotion 的 bug 多是框架行为不可控。我们为此建立了样式健康度仪表盘BEM 项目监控class属性中 BEM 命名违规率用 ESLint 插件eslint-plugin-bemEmotion 项目监控 SSR 与 CSR 的样式哈希差异率自定义 Lighthouse auditTailwind 项目监控未使用的 class 占比tailwindcss的--watch模式日志和设计系统 token 覆盖率用tailwindcss/typography的 token 检查器2026 年的选型本质上是在选择哪种技术债你更愿意承担BEM 的债是人力成本需要专人维护命名规范Emotion 的债是不确定性框架升级可能破坏样式Tailwind 的债是治理成本需要设计系统工程师。没有免费的午餐只有更透明的账单。4. 实操指南2026 年的混合架构落地策略4.1 拒绝非此即彼BEM Tailwind 的共生模式我们当前主力项目采用“BEM 为骨架Tailwind 为血肉”的混合模式。核心逻辑是BEM 管理 Block 边界和业务语义Tailwind 管理原子样式。例如一个UserProfileCardBlock!-- BEM 定义 Block 边界 -- div classuser-profile-card !-- BEM 定义 Element -- div classuser-profile-card__header !-- Tailwind 管理原子样式 -- img srcavatar.jpg classw-16 h-16 rounded-full object-cover alt头像 h2 classtext-xl font-bold text-gray-900 mt-2张三/h2 /div div classuser-profile-card__body div classflex items-center text-gray-600 mb-3 svg classw-4 h-4 mr-1 fillcurrentColor viewBox0 0 20 20 path dM2.003 5.884L10 9.882l7.997-3.998A2 2 0 0016 4H4a2 2 0 00-1.997 1.884z / path dM18 8.118l-8 4-8-4V14a2 2 0 002 2h12a2 2 0 002-2V8.118z / /svg spanzhangsanexample.com/span /div !-- BEM Modifier 控制状态 -- button classuser-profile-card__action-btn user-profile-card__action-btn--edit 编辑资料 /button /div /div这里user-profile-card是 BEM Block它定义了组件的业务语义和 DOM 结构边界w-16 h-16 rounded-full是 Tailwind 原子样式负责视觉表现user-profile-card__action-btn--edit是 BEM Modifier用于 JS 控制状态切换。这种混合的优势在于可测试性BEM class 名稳定E2E 测试可以精准定位元素cy.get(.user-profile-card__action-btn--edit)可维护性Tailwind class 可以随时调整设计系统不影响 BEM 结构可扩展性新增user-profile-card--compactModifier 时只需在 CSS 中定义.user-profile-card--compact .user-profile-card__header { display: none; }无需改动 JSX我们用 PostCSS 插件postcss-bem自动为 BEM class 添加前缀避免与第三方库冲突同时用apply封装常用 Tailwind 组合/* src/styles/bem-tailwind.css */ layer components { .user-profile-card__header { apply flex flex-col items-center; } .user-profile-card__action-btn { apply px-4 py-2 bg-blue-500 text-white rounded font-medium hover:bg-blue-600 transition-colors; } }这样既保持了 Tailwind 的原子性又通过apply提供了语义化封装。4.2 CSS-in-JS 的现代用法只在必要处注入逻辑我们并没有抛弃 CSS-in-JS而是把它降级为“逻辑驱动样式”的专用工具。场景非常明确动态计算样式图表组件根据数据范围自动调整坐标轴颜色主题切换深色/浅色模式下CSS 变量无法满足的复杂渐变动画状态需要 JS 控制的复杂贝塞尔曲线动画例如一个实时数据图表import { keyframes } from emotion/react; const pulse keyframes 0% { opacity: 0.6; } 50% { opacity: 1; } 100% { opacity: 0.6; } ; const ChartPoint ({ value, isLive }) { // 只有 isLive 为 true 时才注入动画逻辑 const animationStyle isLive ? { animation: ${pulse} 2s infinite } : {}; return ( div css{css width: 8px; height: 8px; border-radius: 50%; background: ${value 100 ? #ef4444 : #10b981}; ${animationStyle} } style{animationStyle} / ); };关键原则CSS-in-JS 只处理“CSS 无法表达的逻辑”其他一切交给 Tailwind 或 BEM。我们甚至写了一个 ESLint 规则禁止在css函数里出现px,rem,color字面量——所有原子值必须来自设计系统 token。这样 CSS-in-JS 就从“样式编写方式”变成了“逻辑样式胶水”大幅降低了它的使用频率和风险。4.3 Tailwind 的企业级配置超越tailwind.config.jsTailwind 在企业级项目中的成败90% 取决于配置。我们的真实配置包含五个层次第一层设计系统 token 映射// tailwind.config.js module.exports { theme: { extend: { colors: { // 严格对应设计系统 Figma 变量 primary: { DEFAULT: var(--color-primary), 50: var(--color-primary-50), 100: var(--color-primary-100), // ... up to 900 }, // 业务语义色 status: { success: var(--color-status-success), warning: var(--color-status-warning), error: var(--color-status-error), } }, spacing: { // 设计系统间距阶梯 1: 0.25rem, // 4px 2: 0.5rem, // 8px 3: 0.75rem, // 12px 4: 1rem, // 16px 6: 1.5rem, // 24px 8: 2rem, // 32px } } } }第二层响应式断点治理// 我们不用默认的 sm/md/lg而是按设备类型定义 theme: { screens: { mobile: 320px, tablet: 768px, desktop: 1024px, large: 1440px, // 业务特定断点 print: { raw: print }, } }第三层插件生态管控plugins: [ require(tailwindcss/forms), // 表单重置 require(tailwindcss/typography), // 富文本样式 // 自研插件防止滥用 function({ addUtilities }) { // 禁止直接使用 text-xs/text-sm/text-base必须用设计系统字号 addUtilities({ .text-body-sm: { font-size: 0.875rem, line-height: 1.25rem }, .text-body-md: { font-size: 1rem, line-height: 1.5rem }, .text-heading-lg: { font-size: 1.5rem, line-height: 2rem }, }) } ]第四层JIT 模式安全加固// 生产环境禁用 JIT用预编译保证稳定性 mode: process.env.NODE_ENV production ? aot : jit, // 但开发环境启用 JIT并限制扫描路径 content: [ ./src/**/*.{js,jsx,ts,tsx}, // 明确排除 node_modules 和第三方库 !./node_modules/**/*, !./src/lib/**/*, // 第三方封装库 ],第五层CI/CD 集成Git Hook 检查提交前运行npx tailwindcss -c tailwind.config.js --content ./src --check确保所有 class 在配置中存在Storybook 集成每个组件 Story 自动检测未使用的 Tailwind classLighthouse 自定义 audit测量 Tailwind 生成的 CSS 文件体积超过阈值120KB自动告警这套配置让 Tailwind 从“快捷键”变成了“企业级样式引擎”。5. 常见问题与实战避坑指南5.1 “Tailwind 生成的 CSS 太大”——这是配置问题不是框架缺陷我们最初上线 Tailwind 时生产 CSS 体积达 1.2MBLighthouse 样式加载评分 23。排查发现三个致命配置错误错误一content 配置过于宽泛// ❌ 错误扫描整个 node_modules content: [./src/**/*.{js,jsx,ts,tsx}, ./node_modules/**/*] // ✅ 正确精确到组件目录排除第三方 content: [ ./src/components/**/*.{js,jsx,ts,tsx}, ./src/pages/**/*.{js,jsx,ts,tsx}, ./src/layouts/**/*.{js,jsx,ts,tsx}, !./src/lib/**/*, !./node_modules/**/*, ]错误二启用了未使用的插件// ❌ 错误导入了所有插件 plugins: [ require(tailwindcss/forms), require(tailwindcss/typography), require(tailwindcss/aspect-ratio), require(tailwindcss/container-queries), ] // ✅ 正确按需导入且 typography 只用于富文本区域 plugins: [ require(tailwindcss/forms)({ strategy: class }), // typography 只在 markdown 渲染器中启用 // require(tailwindcss/typography), ]错误三未启用 PurgeCSS 的深度清理// tailwind.config.js module.exports { // ✅ 强制启用 PurgeCSS 的深度模式 purge: { enabled: true, content: [...], // 同上 // 关键启用深度匹配 safelist: [ // 保留动态生成的 class如 bg-${color}-500 /^bg-(red|blue|green|yellow|purple|pink|indigo|gray)-[0-9]{2,3}$/, /^text-(red|blue|green|yellow|purple|pink|indigo|gray)-[0-9]{2,3}$/, // 保留 JS 动态 class /data-theme/, /dark:/, ], } }修复后CSS 体积降至 86KB加载时间从 1.2s 降到 180ms。Tailwind 的体积问题99% 是配置不当不是框架本身。5.2 “BEM 类名太长影响可读性”——用 PostCSS 自动缩写BEM 类名user-profile-card__header__title--large确实冗长。我们的解决方案不是放弃 BEM而是用 PostCSS 插件postcss-bem自动缩写/* 输入 */ .user-profile-card__header__title--large { font-size: 1.5rem; } /* 输出生产环境 */ .u-p-c__h__t--l { font-size: 1.5rem; }插件配置// postcss.config.js module.exports { plugins: [ require(postcss-bem)({ separator: __, modifier: --, // 保留前 2 个字母但避免歧义如 user - u, profile - p abbreviate: (name) { if (name user) return u; if (name profile) return p; if (name card) return c; if (name header) return h; if (name title) return t; return name.substring(0, 2); } }) ] }这样既保持了 BEM 的结构语义又解决了可读性问题。更重要的是缩写规则是团队共识不是个人习惯所有开发者都遵循同一套映射表。5.3 “CSS-in-JS 在 SSR 下样式丢失”——Emotion 的正确 SSR 配置Emotion 的 SSR 问题根源在于服务端渲染时css函数生成的 class 名和客户端 hydration 时生成的 class 名不一致。解决方案是服务端和客户端共享同一份 cache// _app.tsx (Next.js) import createCache from emotion/cache; import { CacheProvider } from emotion/react; // 创建服务端 cache const serverCache createCache({ key: css, stylisPlugins: [] }); // 在 getServerSideProps 中注入 export async function getServerSideProps(context) { const cache createCache({ key: css, stylisPlugins: [] }); // 渲染时使用此 cache const html renderToString( CacheProvider value{cache} App / /CacheProvider ); // 序列化 cache 到 HTML const styles extractCritical(cache); return { props: { emotionCache: cache, emotionStyles: styles, } }; } // 客户端 hydrate function MyApp({ Component, pageProps, emotionCache, emotionStyles }) { return ( CacheProvider value{emotionCache} Component {...pageProps} / style dangerouslySetInnerHTML{{ __html: emotionStyles.css }} / /CacheProvider ); }关键点服务端和客户端必须使用同一个 cache 实例不能各自 new 一个。我们还用emotion/server的renderStylesToString替代手动序列化避免遗漏。5.4 “Tailwind 响应式写错了移动端样式错乱”——用 Storybook 的响应式测试Tailwind 的sm:,md:断点容易写错。我们的防御措施是Storybook 插件storybook/addon-viewport为每个组件 Story 预设 mobile/tablet/desktop 视口自定义 decorator自动注入 Tailwind 断点检查// .storybook/preview.js export const decorators [ (Story) ( div classNamebg-gray-50 p-4 Story / {/* 自动显示当前断点 */} div classNamefixed top-4 right-4 bg-black bg-opacity-70 text-white px-3 py-1 text-xs rounded {window.innerWidth 640 ? mobile : window.innerWidth 768 ? tablet : desktop} /div /div )