内联样式仅适用于JS动态控制和HTML邮件模板；内部样式表限于原型验证或SSR关键CSS；外部样式表是唯一可维护、可缓存、可工程化的标准方案。
内联样式只该出现在JS动态控制或邮件模板里
内联样式 style 属性的优先级是 1000，比任何选择器都高，但它不是“更高级”，而是“更危险”。它把结构和表现死绑在一起，HTML 文件体积随样式增长而膨胀，且无法被浏览器缓存。真实项目中，你几乎不该手动写 style="color: red;" 这类代码。
真正合理的使用场景只有两个：
– JavaScript 动态计算后设置的样式，比如拖拽时实时更新 transform 或弹窗位置；
– HTML 邮件模板，因为多数邮件客户端（如 Outlook、Apple Mail）会剥离 <style></style> 和外部 <link>，只认内联样式。
常见翻车点：
– 用内联样式覆盖第三方组件库的默认样式，结果上线后 JS 加载失败，页面直接裸奔；
– 在 Vue/React 组件里大量用 :style 绑定对象，却没做防抖或 memoization，导致重绘频繁；
– 把媒体查询写进 style（不支持），以为能响应式，实际完全无效。
内部样式表仅限单页应用原型或 SSR 服务端注入
<style></style> 标签写在 里，作用域是当前 HTML 文档，不跨页，也不参与构建流程。它比内联稍好，但依然违背“结构与样式分离”原则——CSS 逻辑混在 HTML 文件中，无法被 webpack/Vite 提取、压缩、拆包或做 CSS Scope。
立即学习“前端免费学习笔记（深入）”；
现代工程里，它只在两种情况下合理：
– 快速验证一个交互效果（比如改个动画 timing-function），不想开新文件；
– SSR 场景下，服务端渲染时把关键 CSS 内联进 （即 Critical CSS），避免 FOUC，但这部分通常由框架（如 Next.js 的 getServerSideProps + styled-jsx）或插件自动生成，不是人手写的。
注意：<style></style> 不支持 @import、不支持 CSS 变量跨文件复用、无法被 PostCSS 处理，也不参与 tree-shaking。一旦项目从 demo 进入协作阶段，就得立刻迁移出去。
外部样式表是唯一可维护、可缓存、可工程化的选择
用 <link rel="stylesheet" href="index.css"> 引入独立 CSS 文件，是现代前端项目的事实标准。它让样式可复用、可缓存、可并行加载、可 sourcemap 调试，也天然适配模块化（如 CSS Modules）、原子化（如 Tailwind）、主题切换（通过动态换 href）等需求。
实操建议：
– 路径必须用相对或绝对 URL，别用 ./style.css 这种容易被构建工具误判的写法；
– 关键样式（如首屏按钮、标题）建议用 media="print" 或 onload 回调做异步加载优化，避免阻塞渲染；
– 不要用 @import url("reset.css") 替代 <link>，它会串行加载、阻塞渲染，且无法被 webpack 的 CSS 提取插件识别；
– 如果用 CSS-in-JS（如 Emotion），本质仍是生成外部样式表，只是由 JS 控制注入时机，不是绕过外部引入原则。
构建工具不会替你做决策，但会暴露你的选择漏洞
Vite、webpack、Rspack 这些工具对三种引入方式的处理差异极大：内联样式完全不进构建流程，内部样式表可能被提取为字符串但无法 HMR 热更新，只有外部样式表能享受完整的编译链路——PostCSS、CSS Modules、scope 哈希、自动 vendor 分离、甚至 CSS 代码分割。
最容易被忽略的一点是：当你在组件里写 <style scoped></style>（Vue）或 import './Button.module.css'（React），你以为是“内部”，其实构建工具早已把它转成了带哈希的外部 CSS 文件，并通过 class 名注入 DOM。真正的“内部样式表”只存在于未构建的 HTML 原始文件里——而那从来就不是生产环境该出现的东西。
