不要用@import。它会阻塞渲染、无法并行下载，拉长移动端首屏白屏时间；应改用并行加载，并通过media属性实现条件下载，提升性能。
移动端CSS加载要不要用@import？
不要。在<link>里用@import会阻塞渲染，且无法并行下载——浏览器必须先下载并解析外层CSS，才能发起@import引用的请求。移动端网络波动大、延迟高，这会让首屏白屏时间明显拉长。
常见错误现象：Network面板里看到多个CSS文件串行加载，Lighthouse提示“Render-blocking resources”；@import嵌套三层后，小屏设备等了两秒才显示文字。
- 改用
<link rel="stylesheet">并行加载主样式和媒体查询样式 - 如果必须复用某份基础CSS，直接把它内联进
<style></style>标签（仅限几KB以内） - 避免在CSS文件里写
@import url("mobile.css")，尤其别写在print.css或theme.css里
怎么用media属性让浏览器只下载对应屏幕的CSS？
关键不是“写媒体查询”，而是把media属性加在<link>标签上——这样浏览器能根据当前设备特征决定是否下载该资源，而非等CSS加载完再判断是否生效。
使用场景：为平板单独加载一套栅格系统，或为折叠屏加载横竖屏适配样式，又不想让手机用户多下100KB。
立即学习“前端免费学习笔记（深入）”；
-
<link rel="stylesheet" href="desktop.css" media="screen and (min-width: 1024px)">—— 宽屏设备才下载 -
<link rel="stylesheet" href="mobile.css" media="screen and (max-width: 767px)">—— 小屏设备才下载 - 注意：
media值必须是有效媒体查询，不能写media="mobile"这种自定义关键字 - 兼容性没问题：Chrome 1+、Safari 3.1+、Firefox 2+ 都支持
<link media>的预加载判断
prefers-reduced-motion这类新特性怎么安全接入？
它本身不触发额外下载，但容易误用成“全量加载动画CSS再靠JS开关”，这就失去意义了。真正轻量的做法是把动效规则直接包进@media块里，并用<link media>隔离。
性能影响：如果把@media (prefers-reduced-motion: reduce)写在主CSS里，所有设备都会下载整份含动效的CSS；而拆成独立文件后，仅需动效降级的用户才加载。
- 新建
reduced-motion.css，只放@media (prefers-reduced-motion: reduce) { ... }规则 - 用
<link rel="stylesheet" href="reduced-motion.css" media="prefers-reduced-motion: reduce"> - 别在JS里动态
insertRule或切换disabled属性——那会强制重排，且无法利用浏览器预加载逻辑
为什么min-width比max-width更常用？
因为移动优先已成事实。你写的base.css默认适配小屏，再用min-width渐进增强——这样即使媒体查询没加载完或解析失败，页面至少能看；反过来用max-width做“降级”，一旦CSS加载失败，桌面用户看到的就是未样式化的HTML。
容易踩的坑：用max-width: 480px写手机样式，但忘了给body设font-size，结果在iPhone SE上文字小得看不见；或者min-width断点设成768px，却没考虑iPad竖屏也是768px宽，导致横竖屏切换时样式错乱。
- 推荐断点：
768px（平板竖屏）、1024px（桌面窄屏）、1280px（常规桌面） - 用
min-width时，确保基础样式不依赖max-width覆盖，否则维护成本飙升 - 真要响应折叠屏或横竖屏切换，优先用
orientation或dynamic-range等更具体的媒体特性，而不是硬塞max-width
最常被忽略的是media属性的匹配时机——它在<link>标签解析时就触发，不等DOM构建完成。所以别指望用JS修改media值来“动态切换”，那只会让浏览器重新评估加载策略，反而引发重复请求。
