@import 会阻塞渲染并导致白屏延长，因其串行加载、无法预加载、不支持事件监听且易引发 FOUC；应优先使用 <link>，仅在极少数条件加载场景下谨慎使用。
使用 @import 引入 CSS 会阻塞渲染
浏览器解析到 @import 时，必须先下载并解析被导入的样式表，才能继续处理后续 CSS 规则。这意味着它会延迟关键 CSS 的应用，导致页面白屏时间变长。尤其是链式 @import（A.css 导入 B.css，B.css 又导入 C.css），会形成串行请求，无法并行加载。
- 所有
@import都在 CSS 解析阶段执行，不参与 HTML 加载流程的资源发现（resource discovery） - 即使写在
<style>标签末尾，也无法改变其“后加载”本质 - 在
<link rel="stylesheet">已加载完成的情况下，@import仍可能触发额外的重排/重绘
link 支持 preload、media、onload 等关键能力
<link> 是 HTML 原生标签，浏览器在 HTML 解析早期就能识别并预加载资源；而 @import 只能在 CSS 文件被读取后才生效，完全错过预加载窗口。
-
<link rel="preload" as="style" href="main.css">可提前拉取关键样式，@import无对应机制 -
media属性支持响应式加载（如media="(prefers-color-scheme: dark)"），@import虽支持但仅限于规则内，无法控制网络请求时机 -
<link>可监听load和error事件，便于做加载状态反馈或 fallback，@import不可监听
@import 在 CSS 文件内部使用更隐蔽但风险更高
当 @import 出现在外部 CSS 文件中（比如 base.css 里写了 @import "reset.css";），开发者容易忽略其带来的瀑布链和 FOUC（Flash of Unstyled Content）风险。
dmap-jsapi-skill
下载
DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
- 构建工具（如 Webpack、Vite）通常不会警告这类导入，但实际运行时仍按规范串行加载
- 某些旧版 Safari 对嵌套
@import的并发请求数限制更严格（如最多 2 个） - 如果被导入文件返回 404 或超时，整个导入链中断，且无降级手段
/* ❌ 不推荐：在 base.css 中这样写 */
@import url("reset.css");
@import url("typography.css");
@import url("components/button.css");现代项目应优先用 link，@import 仅限极少数场景
唯一还算合理的使用场景是：需要根据 CSS 环境变量（如 @media 或 @supports）条件性加载样式——但即便如此，也建议改用 <link media> 或 JS 动态插入。
立即学习“前端免费学习笔记（深入）”；
- CSS-in-JS 方案（如 styled-components）内部不用
@import，而是靠 JS 控制注入顺序 - PostCSS 插件（如
postcss-import）是在构建时将@import内联为普通规则，不产生运行时请求——这和浏览器原生@import完全不是一回事 - 如果你正在调试一个白屏时间长的页面，检查 network 面板里是否存在多个串行的 CSS 请求，很可能是
@import在作祟
真正难察觉的是：开发者以为自己用了构建时内联，结果部署后忘了关闭插件或误配了环境，导致生产环境跑出原生 @import。这种问题往往只在真实网络条件下暴露。
