根本原因是首页、商品详情页等样式需求差异大，全量引入会导致首屏加载慢、带宽浪费、ttfb和lcp增加；按需引入通过构建工具将css与js模块对齐，实现路由或组件级精准加载，避免冗余解析与缓存失效。
大型电商网站采用按需引入 CSS，根本原因不是“想炫技”，而是首页、商品详情页、购物车、订单页、后台管理页……它们的样式需求差异极大，强行全部加载只会拖慢首屏、浪费带宽、增加 TTFB 和 LCP 时间。
为什么 link rel="stylesheet" 全量引入在电商场景下会出问题
电商页面结构复杂：首页有轮播、推荐流、广告位；详情页要渲染 SKU 选择器、图片放大器、评论组件；结算页依赖表单验证样式和支付图标。如果所有 CSS 都塞进一个 app.css，用户打开首页时，浏览器必须下载并解析包含「订单导出 Excel 按钮」样式的代码——这个按钮只在卖家后台出现。
- 首屏关键资源体积暴涨，FCP 延迟明显（尤其弱网环境）
- 缓存失效成本高：改一个「我的订单」页的按钮颜色，整个
app.css的哈希值就变，全站 CSS 缓存失效 - 构建产物中大量未使用的选择器（如
.seller-dashboard__export-btn在 C 端页面永远不匹配），CSSOM 构建更慢
React/Vue 项目里怎么让 CSS 真正“按需”
不能只靠人肉判断“这个组件用不用某份 CSS”，得靠构建工具和模块机制把样式和 JS 的加载生命周期对齐。
- 用
import './ProductCard.module.css'而不是import '../styles/global.css'—— CSS Modules 保证类名局部作用域，且 Webpack/Vite 默认做 scope hoisting + tree-shaking - 路由级拆分：Vite 中配合
import('./views/Checkout.vue')动态 import，其style块或@import的 CSS 会自动打到异步 chunk 中 - 避免在
main.js里import 'normalize.css'或全局@import，这类重置/基础样式应内联进 HTML 或走 critical CSS 提取
动态插入 link 标签的风险与补救
有些团队会在点击“展开规格参数”后才 loadCSS('/css/specs-accordion.css')，这看似按需，但极易触发 FOUC（Flash of Unstyled Content）。
- 浏览器不会阻塞渲染等待动态插入的 CSS，除非你手动加
media="print"再 onload 切回media="all" - 更稳妥的做法是：把该模块的 CSS 提前打包进对应路由 chunk，由框架/构建工具控制加载时机，而非运行时 JS 注入
- 若真要 JS 控制，务必搭配
document.fontFaceSet.load()和document.styleSheets检查加载完成状态，再操作 DOM
真正难的不是“怎么拆”，而是“拆完之后如何确保样式不冲突、调试不迷路、CI 不误删关键 CSS”。比如商品卡片的 hover 动画在首页和搜索页表现不一致，大概率不是 CSS 写错了，而是两处用了不同版本的 Card.module.css，或者某处漏了 :global(.icon-star) 的穿透写法——这些细节比引入方式本身更消耗排查时间。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
