该用 标签而非外部 css 文件的场景是：样式仅服务单页、改动频繁（如 a/b 测试页）或需快速验证布局；它省 http 请求、避免路径错误，但无法缓存、易耦合 js、不支持构建工具处理。
什么时候该用 <style></style> 标签而不是外部 CSS 文件
当样式只服务于单个 html 页面、且改动频繁（比如 A/B 测试页面、临时活动页），或者需要快速验证布局逻辑时，<style></style> 放在 里最直接。它省去了 HTTP 请求，避免因路径错误或服务器未响应导致样式丢失。
但要注意：这类内联样式无法被浏览器缓存，每次加载都得重新下载；多人协作时也容易和 JS 逻辑耦合，后期难定位问题。
- 适合场景：
<style></style>用于小范围定制，比如覆盖第三方库默认样式、调试时临时加border: 1px solid red - 不适合场景：中大型项目、需多页复用的组件样式、有主题切换需求的站点
- 如果用了构建工具（如 Vite、webpack），
<style></style>里的 CSS 不会经过 postcss 处理，rem转换、自动加前缀等功能默认失效
<style></style> 必须放在
必须放在 里，这是 HTML 规范强制要求。如果写在 开始处（比如紧挨着 标签），浏览器仍会尝试解析，但可能触发“阻塞渲染”或样式闪烁——尤其是内容先渲染、样式后加载时。
更糟的是，某些老版本 safari 或 IE 会直接忽略 <style></style> 中的规则，不报错也不生效。
立即学习“前端免费学习笔记（深入）”；
- 常见错误现象：页面刚打开时文字无颜色/无间距，0.5 秒后才突然“跳”成正确样式
- 检查方法：用浏览器开发者工具 Elements 面板看
<style></style>是否出现在下，且没有被标记为disabled - 注意：不能把
<style></style>放在<title></title>之后但又在<meta>前面——虽然语法上合法，但部分移动端 webview 会误判编码或视口设置
<style></style> 里写 @import 会影响性能吗
会影响，而且影响明显。在 <style></style> 块里用 @import url("xxx.css")，等价于在 CSS 文件里写 @import —— 浏览器必须先下载并解析当前 <style></style> 内容，再发起新请求加载被引入的文件，形成串行阻塞。
这比直接用 <link rel="stylesheet"> 多一次网络往返，首屏时间拉长，还可能破坏关键 CSS 提取逻辑。
- 替代方案：用
<link rel="stylesheet">并行加载，或把要引入的内容直接复制进<style></style>（仅限体积小、无复用需求） - 特别注意：
@import在媒体查询中使用（如@import url("print.css") print）不会阻塞屏幕渲染，但依然不推荐用于<style></style>内部 - 构建环境下，
@import还可能导致 source map 错位，调试时找不到原始 CSS 行号
用 <style></style> 写 CSS 时哪些特性容易被忽略
很多人以为 <style></style> 就是“把 CSS 文件内容粘进来”，其实它对作用域和解析上下文更敏感。比如 CSS 变量（--color-primary）在 <style></style> 里定义后，只能被同文档内的元素读取，没法跨 iframe 或 Shadow dom 使用；而 :host、::slotted 这类伪类根本无效。
- 容易踩的坑：
@keyframes动画名若和其他<style></style>块重复，会被后者覆盖，且无警告 - 兼容性差异：IE 不支持
calc()在<style></style>里的嵌套写法（如width: calc(100% - var(--gap))），需降级为固定值 - 安全限制：在 CSP（Content Security Policy）策略启用
style-src 'self'时，<style></style>是允许的，但若策略写了style-src 'none'，整个块会被浏览器静默丢弃
真正麻烦的不是怎么写，而是改完之后忘了删——尤其当项目从原型转为正式开发时，残留的 <style></style> 很难被自动化工具扫描出来，只能靠人工翻查。