适合内联的是小于1–2KB的critical CSS（如按钮、导航栏样式）和SVG图标；坚决不能内联的是公共库（如lodash、Vue）、大图/PNG/JPEG、favicon.ico；内联script/style会阻塞解析且需CSP配合nonce/hash，base64图片导致体积膨胀33%、缓存失效、失去响应式能力。
哪些资源适合内联，哪些坚决不能
html 中内联 <script></script>、<style></style> 或 base64 图片，本质是用体积换请求数。但不是所有资源都适合：
- 小于 1–2KB 的
critical CSS（首屏渲染必需）适合内联，比如按钮样式、导航栏布局 - 公共库如
lodash、vue.runtime.esm-bundler.js绝对不要内联——重复加载、无法缓存、破坏 CDN 优势 - SVG 图标可内联（
<svg>...</svg>），但大图或带复杂滤镜的 PNG/JPEG 内联后 HTML 体积暴涨，得不偿失 -
favicon.ico即使只有 1KB，也不建议 data URL 内联——浏览器会忽略<link rel="icon">中的 data URL（部分 Safari 和旧 Edge 不支持）
内联 script/style 后，执行时机和 CSP 怎么办
内联代码默认同步执行，且绕过外部文件的缓存策略，但会撞上两个现实约束：
-
<script></script>内联后没有async或defer属性可用，会阻塞 HTML 解析，若逻辑重，首屏时间反而更差 - 若启用了 CSP（Content Security Policy），默认禁止内联脚本和样式，必须显式加
unsafe-inline或使用nonce/hash- 错误写法：
<meta http-equiv="Content-Security-Policy" content="script-src 'self'">→ 所有内联<script></script>被拦截，控制台报错Refused to execute inline script - 正确做法：服务端生成唯一
nonce，注入到 HTML 和 CSP 头中，例如：<script nonce="abc123">...</script>+Content-Security-Policy: script-src 'nonce-abc123'
- 错误写法：
base64 图片内联的真实成本是什么
把图片转成 base64 后塞进 src 或 background-image，看似省了一次请求，实则引入三重隐性开销：
- 编码后体积膨胀约 33%，一张 5KB 的 PNG 变成 6.6KB 的字符串，且无法被 gzip 高效压缩（base64 字符集熵高）
- 浏览器无法单独缓存该图片，下次页面哪怕只改一个字，整个 HTML 缓存失效，图片数据重复传输
- 不支持
srcset和sizes，响应式图片能力归零；也不能被 preload 提前拉取 - 实测场景：在 HTTP/2 下，对同一域名下多个小图标做 base64 内联，比走多路复用请求更慢——因为阻塞了主 HTML 的解析流，而 HTTP/2 的请求并行优势被浪费
替代方案比内联更稳的几个动作
减少请求数不该只盯着“往 HTML 里塞”，优先考虑基础设施层的收敛：
Wechat Article Html
下载
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
- 把多个小 CSS 合并为一个，用构建工具（如 Vite、Webpack）自动提取
critical CSS并内联，其余仍外链 - 使用
<link rel="preload">提前声明关键资源，例如：<link rel="preload" href="/main.css" as="style">，比内联更可控 - 启用 HTTP/2 或 HTTP/3，让多个小资源并行加载的成本大幅降低，此时盲目内联反而增加 TTFB 和首字节时间
- 对静态资源加长缓存（
Cache-Control: public, max-age=31536000），配合文件内容哈希命名（如main.a1b2c3.css），既保缓存又保更新
内联不是开关，是权衡。真正卡顿的地方往往不在请求数，而在资源是否关键、是否可缓存、是否被提前感知——这些点漏掉，光压请求没用。
立即学习“前端免费学习笔记（深入）”；
