CSS引入方式的四种方法
写CSS第一步就是决定代码放哪儿。行内样式直接写在HTML标签里，比如
，适合临时调试但维护困难。内部样式表放在的标签中，页面加载快但复用性差。最推荐外部样式表，用引入，能缓存还能多页面共享。还有个冷门的@import，性能不如，现在主要用在CSS模块化场景。
| 引入方式 | 代码示例 | 加载顺序 | 适用场景 |
|---|---|---|---|
| 行内样式 | 最高优先级 | 紧急热修复 | |
| 内部样式 | p{color:red} | 随HTML解析 | 单页小项目 |
| 外部样式 | 并行加载 | 中大型项目 |
选择符的进阶用法
类选择器.btn和ID选择器#header大家都会用，但属性选择器才是黑科技。[data-toggle="modal"]能精准抓取自定义属性，a[href^="https"]匹配所有https链接。组合选择器里，div > p只选直接子元素，比后代选择器div p性能高30%。伪类选择器像:nth-child(2n+1)搞斑马纹表格，:not(.disabled)排除特定元素，都是实战利器。
选择符权重避坑指南
当多个样式冲突时，浏览器按这套规则判断优先级：
!important直接封神千万别滥用!important，推荐用增加选择器特异性的方式覆盖样式。比如要修改.nav li的样式，可以写成.main-nav .nav li来提升权重。遇到第三方库样式污染时，用[id]这类属性选择器能天然获得更高优先级。
性能优化实战技巧
CSS选择符是从右向左解析的，.sidebar h3 span会先找出所有再向上过滤，数据量大的页面要避免这种写法。推荐改用BEM命名规范，像.card__title直接定位元素，比层级选择器快40%。移动端尤其要注意，复合选择器每增加一级，渲染时间可能增加5-15ms。Chrome DevTools的Performance面板可以检测选择符重绘成本，把耗时超过2ms的选择器列进优化清单。
浏览器解析CSS选择器的方式其实挺有意思的，它采用的是从右到左的逆向匹配机制。当遇到div p这样的后代选择器时，引擎会先疯狂收集页面里所有的
标签，然后再逐个检查它们的祖先链里有没有
标签，这种选择器就会让浏览器做上千次无谓的DOM遍历。
改用div>p这样的直接子代选择器就聪明多了，引擎只需要检查
的直系父节点是不是
常见问题解答
行内样式和内部样式表哪个优先级更高？
行内样式优先级更高。当行内样式（style属性）与内部样式表（style标签）冲突时，浏览器会优先采用行内样式。但实际开发中应该避免依赖这种优先级，而是通过合理的选择符设计来控制样式覆盖。
外部CSS文件为什么推荐用link而不是@import？
link标签在页面加载时能并行下载CSS文件，而@import会等到HTML解析完毕才开始加载，导致渲染延迟。测试数据显示link方式能使页面加载速度提升15-30%，特别是在移动端网络环境下差异更明显。
为什么说后代选择器div p性能较差？
浏览器从右向左解析CSS选择器，遇到div p时会先找出所有p元素再向上过滤，当页面有1000个p标签时就要执行1000次判断。而直接子选择器div>p只需要检查父元素是否为div，性能通常能提升20-40%。
如何解决第三方CSS库的样式冲突？
最稳妥的方法是使用更具体的选择符包裹，比如在容器元素添加唯一ID，写成#my-app .btn来覆盖第三方.btn样式。CSS Modules和Scoped CSS这类技术也能自动生成唯一类名避免冲突。
!important在什么情况下可以使用？
只有在需要覆盖内联样式或无法修改的第三方样式时才考虑使用!important，比如处理UI组件库的默认样式。常规项目开发中应该通过提升选择器特异性（如添加父类名）来实现样式覆盖，滥用!important会导致后续维护困难。
