CDN本身不合并CSS，合并由构建工具（如Webpack、Vite）在部署前完成；CDN仅缓存并分发已合并的产物，如style.css，浏览器通过单个URL请求该文件。
CDN 本身不合并 CSS 请求，合并发生在构建或部署阶段
CDN 不会自动把你的 a.css、b.css、c.css 合成一个文件返回。它只缓存和分发你上传/回源的原始资源。所谓“通过 CDN 合并请求”，本质是：你先在本地或构建流程中把多个 CSS 合并好，再把那个合并后的文件推送到 CDN；浏览器请求的仍是单个 URL，只是这个 URL 指向的是 CDN 上托管的“已合并”产物。
常见错误现象：<link href="https://cdn.example.com/a.css,b.css"> 或 <link href="https://cdn.example.com/a.css?merge=b.css">——这些写法浏览器根本不识别，直接 404 或加载失败。
- CDN 是“搬运工”，不是“裁缝”。它不解析 HTML 或 CSS 内容，也不重写请求路径
- 真正起合并作用的是构建工具（如 Vite、Webpack）或发布脚本，不是 CDN 控制台里的某个开关
- 如果你看到“CDN 合并 CSS”的说法，大概率是混淆了“CDN 加速合并后的文件”和“CDN 执行合并”
如何让 CDN 服务合并后的 CSS 文件
关键不是让 CDN 合并，而是确保你上传到 CDN 的，已经是合并好的产物。操作链路很明确：
- 开发时保留
header.css、button.css、theme-dark.css等独立文件，便于维护和按需加载 - 构建时用工具合并：Vite 默认将
import './a.css'和import './b.css'打包进style.css；Webpack 配合mini-css-extract-plugin也能输出单个 CSS 文件 - 把构建产物中的
style.css上传到 CDN，例如推送到https://cdn.example.com/v1.2.0/style.css - HTML 中只引入这一个链接：
<link rel="stylesheet" href="https://cdn.example.com/v1.2.0/style.css">
注意：如果构建后仍看到多个 CSS 文件出现在 dist/ 目录里，说明打包配置没生效，或用了 @import / 动态 loadCSS() 等绕过构建流程的方式。
立即学习“前端免费学习笔记（深入）”；
为什么不能依赖 CDN 边缘计算做 CSS 合并
目前主流 CDN（Cloudflare、Akamai、阿里云 CDN、腾讯云 CDN）均不提供运行时 CSS 合并能力。原因很实际：
- HTTP 层无法安全地解析和拼接 CSS：
@charset声明位置、@import顺序、!important权重、媒体查询嵌套等都可能因拼接错位导致样式失效 - 边缘节点资源有限，做文本合并+重写+缓存键重算，开销远高于直接透传
- 缓存失效逻辑复杂：一个子文件更新，整个合并结果是否失效？CDN 无从得知源文件依赖关系
- 已有方案更可靠：构建时合并 + 版本化路径（如
/v1.2.0/style.css），天然支持缓存分离与原子更新
合并后如何兼顾按需加载和主题切换
全量合并会破坏灵活性，但不用退回“每个页面加 10 个 <link>”的老路。正确做法是分层合并：
- 基础样式（reset、typography、layout）→ 合并为
base.css，<link>同步加载 - 功能组件（modal、tooltip、carousel）→ 合并为
components.css，可media="print"或 JS 动态加载 - 主题类（dark、high-contrast）→ 单独保留
theme-dark.css，用document.documentElement.classList.toggle()切换，并配合rel="preload"提前拉取 - 打印样式 → 用
<link rel="stylesheet" href="print.css" media="print">，完全不参与首屏阻塞
真正容易被忽略的点是：合并策略必须和缓存策略对齐。比如把 theme-dark.css 错误地打进 base.css，用户切主题就得重下全部样式，反而增加延迟。HTTP/2 下并行加载多个小文件没问题，但缓存复用率才是长期性能的关键。
