开发者拒绝css框架因其在体积、样式冲突、学习成本和过度抽象等方面带来实际负担；如加载性能下降、定制维护困难、掩盖底层知识、与现代工作流冲突等，需依项目实际权衡。
一些开发者拒绝使用css框架，不是因为它们不好，而是因为这些工具在特定场景下会带来实际负担——比如体积膨胀、样式冲突、学习成本和过度抽象。
框架体积大，影响加载性能
像bootstrap或Tailwind CSS这类流行框架，即使按需引入，基础CSS文件也常超过50KB（未压缩）。对追求首屏渲染速度的项目来说，这相当于硬塞进一个“样式巨无霸”。尤其当只用到其中10%的功能时，其余代码全是冗余。
- cdn加载框架CSS会增加http请求数和阻塞渲染时间
- Tailwind的默认配置生成数万行CSS，若未正确配置PurgeCSS或content pruning，生产包极易臃肿
- 小型营销页或内部工具页面，手写200行语义化CSS往往比引入框架更快更轻量
样式强耦合，难以定制与维护
CSS框架通常预设大量组件类名（如.btn-primary、.card-body）和全局重置规则。一旦业务需求偏离标准ui范式，修改成本陡增。
- 覆盖框架默认样式常需提高选择器权重（如加!important或嵌套多层），破坏CSS可预测性
- 主题切换困难：多数框架不原生支持深色/高对比度等无障碍主题的无缝切换
- 设计系统升级时，框架版本迭代可能要求批量替换类名（如Bootstrap 4→5的.text-center变为.text-lg-center）
掩盖底层CSS问题，延缓技能成长
依赖类名堆砌实现布局（如flex flex-col md:flex-row gap-4 p-6），容易弱化对盒模型、层叠上下文、BFC、逻辑属性等核心机制的理解。
立即学习“前端免费学习笔记（深入）”；
- 遇到Flex/Grid无法对齐、z-index失效、margin合并异常时，缺乏调试底层CSS的能力
- 团队新人直接上手框架，可能写出“能跑但不可读”的样式组合，长期降低代码可维护性
- 响应式断点被封装成sm:、lg:前缀后，反而模糊了媒体查询的真实作用边界
与现代前端工作流存在摩擦
框架的“全局样式注入”模式，和CSS Modules、CSS-in-js、Scoped Styles等隔离方案天然冲突。
- vue SFC中启用
后，框架类名无法穿透作用域，导致样式丢失 - react + CSS Modules下，无法直接复用.container-fluid等类名，必须额外暴露或重写
- 微前端架构中，多个子应用共用同一份框架CSS，易引发样式污染和版本不一致
基本上就这些。不是否定CSS框架的价值，而是提醒：它是个工具，不是标准答案。项目规模、团队能力、交付节奏、长期维护成本——这些才是决定要不要用的关键。