做中后台业务，为什么我不建议你用 Tailwind CSS？

大家好我又来了最近我接手了一个隔壁组转过来的中后台重构项目。交接的时候对方的技术负责人特意跟我强调说这个项目采用了最新的技术栈全面拥抱了Tailwind CSS开发体验极其丝滑。我当时心里还挺期待毕竟这两年Tailwind的风刮得太大了各种国内外大佬都在疯狂带货。结果周末我抽空把代码拉下来打开VSCode准备梳理一下业务主流程。盯了屏幕不到十分钟我感觉自己的眼睛快瞎了。光说理论没意思我直接给你们截取一段真实的、承载了各种表单校验和状态联动的业务侧边栏组件。你们自己品鉴一下所谓的极致开发体验const OrderCard ({ order, isAdmin, isExpanded }) { return ( div className{flex flex-col w-full p-5 mb-4 border rounded-lg shadow-sm transition-all duration-300 ${ isAdmin ? bg-red-50 border-red-200 : bg-white border-gray-200 } ${ isExpanded ? max-h-[800px] : max-h-24 overflow-hidden } hover:shadow-md cursor-pointer} div classNameflex items-center justify-between pb-3 mb-3 border-b border-gray-100 span classNametext-sm font-semibold text-gray-800 truncate w-[60%] {order.id} /span span className{px-2 py-1 text-xs rounded-full ${ order.status PAID ? bg-green-100 text-green-700 : bg-orange-100 text-orange-700 }} {order.statusText} /span /div {/* 内部极其复杂的业务字段渲染... */} /div ); }代码跑得通吗当然跑得通。UI 还原度高吗也挺高。 但是作为接下来要维护这个项目的组长我只觉得一阵头皮发麻。很多前端新人甚至是做惯了C 端独立开发的兄弟对Tailwind简直是顶礼膜拜。因为它不用取名字不用在JS和CSS文件之间来回切换写起来确实有快感。但作为趟过无数中后台项目的深水区我今天必须给这股跟风热潮泼一盆冷水在绝大多数重型中后台业务场景里Tailwind CSS并不是什么神兵利器而是给后期维护带来不方便。来咱们拿真实代码说话看看它到底是怎么摧毁中后台工程的。彻底掩盖你的业务主线做中后台系统最难的从来不是画 UI而是处理极度复杂的数据状态流转。上面那段代码最大的问题在于信噪比极低。作为一个接手代码的前端我点开这个文件首先想看的是这个组件在不同权限、不同展开状态下业务逻辑是怎么走的但在Tailwind的体系下我的视线全被flex、p-5、mb-4、max-h-[800px]这种毫无业务价值的视觉原子类给强暴了。如果退回到老古董的CSS Modules方案这段代码在JS侧应该长什么样咱们对比一下import classNames from classnames; import styles from ./OrderCard.module.less; const OrderCard ({ order, isAdmin, isExpanded }) { return ( div className{classNames(styles.orderCard, {[styles.adminMode]: isAdmin, [styles.expanded]: isExpanded })} div className{styles.cardHeader} span className{styles.orderId}{order.id}/span span className{classNames(styles.statusBadge, { [styles.statusPaid]: order.status PAID, [styles.statusPending]: order.status PENDING })} {order.statusText} /span /div {/* 业务字段一目了然 */} /div ); }发现区别了吗重构后的JSX变得极其纯粹。我只通过adminMode、expanded这种类名就极其清晰地传达了业务语义。至于那个订单编号到底占百分之几十的宽度那是UI 层该关心的事情它安静地待在.less文件里绝不会来污染我的业务主逻辑。跟现成的组件库水土不服中后台业务是不可能脱离Ant Design、Element Plus这类重型组件库的。而组件库的本质是封装好了一整套内部的DOM结构和ClassName规范。这就带来了一个极其致命的冲突当你用Tailwind去覆盖Ant Design的内部样式时你会写出极其恶心的Hack代码。比如产品经理要求在这个特定页面里把Ant Design表格的表头背景色改成浅蓝色单元格的padding改小一点。正常的Less做法是用样式穿透精确打击/* 样式文件覆盖 */ .myCustomTable { :deep(.ant-table-thead tr th) { background-color: #f0f8ff; padding: 8px 16px; } }你知道那个拥抱Tailwind的小伙子是怎么写的吗为了不写CSS文件他强行使用了Tailwind v3的任意变体语法// Tailwind 强行覆盖组件库内部样式 Table className[_.ant-table-theadtrth]:bg-blue-50[_.ant-table-theadtrth]:py-2 [_.ant-table-theadtrth]:px-4 [_.ant-table-tbodytrtd]:text-gray-600[_.ant-table-tbodytrtd]:py-2 dataSource{data} columns{columns} /这段代码合进主分支的时候我都替后续维护的兄弟感到悲哀。这玩意儿连换行都没有密密麻麻挤在一起。未来如果要做主题切换或者升级Ant Design导致内部类名变了谁敢去动这坨连正则都极难匹配的字符串不仅没有提高开发效率反而为了强行凑Tailwind的语法写出了一堆极难维护的代码。负边距引发的问题一行代码被写出来的成本远远低于它在未来三年里被维护的成本。Tailwind本质上就是披着ClassName外衣的行内样式。它把所有的样式固化在了HTML结构上。设想真实的维护场景前任开发为了让一个按钮和旁边的输入框对齐极其随意地写了一个向左偏移负间距的类名Button className-ml-2 mt-1提交/Button半年后你接手这个需求产品要求在这俩元素中间加一个Icon。你看着这个-ml-2和mt-1会陷入极其痛苦的挣扎他当时为什么要写负边距是因为外层父元素加了错的padding导致的还是为了抵消Button内部自带的margin‍♂️在传统CSS中我们往往会留有注释说明抵消输入框自带的右侧留白。但在Tailwind里没有注释的容身之所。为了保证不出线上Bug你绝对不敢删掉那个-ml-2。你会选择在它后面再打个补丁加个pl-4试图把它顶回来。 第二年另一个接手的同事遇到了错位又在后面补了一个mt-[-5px]。日积月累HTML标签上的类名越来越长死代码和冲突代码全堆在DOM上最终变成一座没人敢碰的屎山。别瞎搞先认清你的场景说了这么多难道Tailwind真的就是垃圾吗当然绝对不是。如果你在做偏C端的炫酷落地页、做SaaS官网或者你是独立开发者没有沉重的历史包袱不需要配合复杂的重型组件库那Tailwind绝对是神作。它自带极其优秀的设计规范能让你极速堆出好看的界面。但咱们讨论的是中后台。中后台是干嘛的团队十几个人来回交接动辄几百个页面充斥着极其复杂的表单联动和权限校验生命周期长达五年甚至十年。在这种重型项目中保持业务逻辑的纯粹性分离关注点远比你少写几行CSS要重要一万倍。好了今天分享到这谢谢大家