link标签顺序影响样式生效，因CSS层叠中源顺序是权重与!important相同时的最终决胜条件；HTML中link按书写顺序阻塞解析、下载并应用，故需将基础样式置前、覆盖样式置后，禁用async/defer，并避免@import混用。
为什么 link 标签顺序会影响样式生效？
因为 CSS 层叠（cascade）规则中，**源顺序（source order）是决定样式的最后决胜条件之一**。当多个规则的选择器权重（specificity）和重要性（!important）都相同时，后出现的样式会覆盖先出现的——无论它们写在同一个文件里，还是分别通过不同 <link> 引入。
常见现象：base.css 定义了 .btn { color: blue; }，theme.css 也写了 .btn { color: red; }，但页面按钮仍是蓝色——大概率是 theme.css 的 <link> 写在了 base.css 前面。
如何安全控制 link 加载顺序？
关键不是“怎么让浏览器按你想要的顺序加载”，而是“明确声明依赖关系并保证执行时序”。HTML 中的 <link> 默认是**阻塞解析、按顺序下载并应用**的，所以只要写对位置，就天然有序。
- 把基础通用样式（如重置、工具类、组件基类）放在最前面
- 把业务组件样式、页面专属样式放在中间
- 把主题覆盖、暗色模式、动态皮肤等「高优先级覆盖层」放在最后
- 避免用
async或defer加到<link rel="stylesheet">上——它们不支持这些属性，加了也无效，还可能误导自己
@import 和 link 混用会破坏顺序吗？
会，而且非常隐蔽。@import 在 CSS 文件内部使用时，**会强制同步阻塞后续样式的解析，且其引入内容的层叠优先级取决于它所在规则的位置，而不是它实际下载完成的时间**。
立即学习“前端免费学习笔记（深入）”；
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
例如：
/* main.css */
@import 'reset.css';
.btn { color: blue; }
@import 'theme.css'; /* theme.css 里的 .btn { color: red; } 不一定生效！*/上面这段代码中，theme.css 实际上被插入到了 .btn { color: blue; } 之后，但它的规则仍可能因解析时机或嵌套层级被降权。更糟的是，@import 在 <link> 后面引入的 CSS 里再使用，会进一步打乱源顺序。
- 永远不要在通过
<link>加载的 CSS 里用@import引入另一个外部 CSS - 如果必须复用片段，改用构建工具（如 PostCSS、Sass）做
@use/@forward，输出为单文件后再<link> - 浏览器对
@import的兼容性没问题，但它的层叠行为在多文件场景下不可预测
权重相同但顺序混乱时，怎么快速定位是哪条规则胜出？
打开 Chrome DevTools → Elements 面板 → 选中元素 → 右侧 Styles 标签页。被划掉的样式不生效，但上方会显示「specificity」和「source order」两栏。重点看：
- 有没有两个规则 specificity 完全一样？比如都是
.header .nav a和.nav a.active（都是 0,2,1） - 生效的那条规则，对应的是哪个文件、第几行？点进去确认是不是你预期的文件
- 检查 Network 面板里 CSS 文件的加载顺序是否和 HTML 中
<link>顺序一致（注意 HTTP/2 多路复用可能让时间戳看起来乱，但应用顺序仍严格按 HTML 顺序）
真正容易被忽略的点：CSS 自定义属性（--color-primary）的继承和计算发生在层叠之后，所以修改变量值不会改变规则本身的优先级；想靠改变量“绕过顺序问题”，往往只是掩盖了结构缺陷。
