内联样式仅在特定场景下必须使用，而外部样式表是工程底线。必须用内联样式的情况包括：html邮件模板、js动态计算样式、第三方组件强制要求、ssr首屏关键样式；link引入css保障缓存、复用、可维护性与工具链支持。
内联样式和外部样式不是“选哪个更好”，而是“在什么场景下必须用哪个”。绝大多数时候，link 引入外部样式表是唯一合理选择；内联样式只在极少数明确受限的环节才该出现。
什么时候必须用 style 属性写内联样式
不是“能用”，而是“没得选”——只有这几种情况绕不开内联样式：
- HTML 邮件模板：多数邮件客户端（如 Outlook、Apple Mail）会忽略或剥离
link和style标签，只认style属性 - JavaScript 动态计算的样式：比如拖拽元素实时更新
transform或top/left，用 class 切换做不到像素级控制 - 第三方嵌入组件强制要求：某些广告 SDK、统计埋点 widget 会注入带
style的 DOM，你无法改它的引入方式 - 服务端渲染首屏关键样式（SSR critical CSS）：为避免 FOUC，把首屏必需的几条规则内联进
head，但这是临时过渡，不是常态写法
为什么 link rel="stylesheet" 是默认起点
外部样式表不是“推荐”，而是工程底线。它解决的是可维护性、协作和加载效率的根本问题：
- 浏览器对
.css文件有强缓存能力，HTML 改了也不影响样式文件复用；而内联样式随 HTML 每次传输，体积翻倍 - 修改一个
button.css就能同步所有页面的按钮样式；用内联就得打开 20 个文件挨个找style="..." - CSS 优先级可控：外部样式可通过 class 组合、BEM 命名等手段精确干预；内联样式权重固定为 1000，后期想覆盖只能加
!important，等于自废武功 - 构建工具（如 Vite、Webpack）默认处理
link引入的 CSS，支持代码分割、tree-shaking、postcss 等；内联样式完全游离在工具链之外
常见误用：把内联当“快捷方式”
看到某个元素样式不对，顺手加个 style="margin-top: 20px" 调试，然后忘了删——这是最典型的滑坡起点：
- 这个
margin很可能本该由某个通用 class（如mt-5）统一控制，加内联等于绕过设计系统 - 后续别人用相同 class 的元素时，发现样式不一致，开始怀疑 CSS 变量或 JS 覆盖，浪费大量调试时间
- 自动化测试或无障碍扫描工具会把大量内联样式识别为“硬编码值”，标记为技术债
- 一旦项目接入 CSS-in-JS（如 styled-components），混合使用内联样式会让样式来源彻底不可追溯
真正难的不是语法怎么写，而是每次敲下 style= 之前，能否立刻回答：这个值是否可能被复用？是否会被主题切换影响？是否需要响应式断点？如果任一答案是“是”，那就别用内联。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
