@media媒体查询可写在任意CSS上下文中，无需单独文件；推荐用min-width实现移动优先，避免不可靠的device-width；多查询几乎不影响性能，但需注意样式顺序与可维护性。
不需要写多个样式表，用 @media 媒体查询在单个 CSS 文件里按条件应用样式，是更主流、更可控的做法。
媒体查询必须写在单独的 .css 文件里吗
完全不必。@media 规则可以写在任意 CSS 上下文中：内联 <style></style>、<link> 引入的外部文件、甚至 CSS-in-JS 生成的样式块里。浏览器原生支持，无额外加载开销。
- 写在外部文件中是最常见做法，维护集中，缓存友好
- 用
<link media="...">确实能「按条件加载」整个文件，但会触发额外 HTTP 请求，且现代浏览器对未匹配media的 CSS 仍会下载（只是不应用） - 真正「不下载」需配合
rel="preload"+as="style"+onload注入，但复杂度陡增，通常没必要
@media 查询条件怎么写才可靠
优先用 min-width / max-width，避免用设备像素比或 device-width 这类不可靠特征。移动端适配以视口宽度（viewport width）为准，不是设备物理尺寸。
-
@media (min-width: 768px)表示「视口宽度 ≥ 768px 时生效」，推荐作为断点起点 - 不要混用
max-width和min-width在同一断点体系里，容易逻辑冲突；统一用min-width实现移动优先（mobile-first） - 避免写
@media screen and (max-device-width: 480px)——device-width在桌面缩放、iPad 分屏等场景下行为不可预测
@media (min-width: 768px) {
.header { font-size: 1.2rem; }
}
@media (min-width: 1024px) {
.header { display: flex; }
}
多个媒体查询会影响性能吗
几乎不影响。CSS 解析器对 @media 是惰性处理：只在视口变化或首次渲染时批量计算匹配状态，不重复解析。但要注意两点：
立即学习“前端免费学习笔记（深入）”；
- 把通用样式（不依赖媒体查询）放在前面，避免被覆盖逻辑干扰可读性
- 避免在
@media内重复声明大量相同属性，可用 CSS 自定义属性（--spacing-sm）抽离可变值 - 过度嵌套媒体查询（比如在每个组件里都写一遍断点）会导致维护困难，建议提取为设计系统级断点变量
真正容易被忽略的是：媒体查询匹配基于当前视口宽度，不是设备类型；所以桌面端缩放到手机宽度，一样会触发移动端样式——这恰恰是响应式本意，别试图用 JS 检测“是不是手机”来绕过它。
