不加 screen 不会失效，但默认匹配所有媒介类型，易在打印或语音场景误触发；建议显式写 @media screen 以确保仅作用于屏幕，尤其在旧版 safari 或 electron 中避免兼容问题。
media 查询写法不加 screen 会失效？
不是必须加，但不加就容易在打印预览或语音阅读器里意外触发——media 查询默认是「所有媒介类型」，而浏览器对未声明类型的解析策略不一致。实际项目中建议显式写成 @media screen，尤其当你只针对可视窗口做响应式时。
常见错误现象：@media (max-width: 768px) { ... } 在某些旧版 Safari 或 Electron 渲染中没生效，其实是被当成 @media all 处理了，而部分环境对 all 下的断点支持不完整。
- 移动端调试时发现样式没加载？先检查是否漏写了
screen - 若需同时适配打印样式，得另起一个
@media print块，不能混用 -
@media screen and (min-width: 480px)是最稳妥的写法，兼容性覆盖到 IE9+
viewport meta 标签没配对，media 查询白写了
再精准的 @media 规则，遇上没设 <meta name="viewport" content="width=device-width, initial-scale=1"> 的页面，手机浏览器会以桌面视口宽度（通常是 980px）渲染，导致 max-width: 768px 永远不匹配。
使用场景：H5 页面、微信内嵌页、PWA 应用——只要涉及移动设备显示，这个 meta 就是前置条件，不是可选项。
立即学习“前端免费学习笔记（深入）”；
- 微信 ios 客户端对
viewport解析更严格，漏掉initial-scale=1可能导致双击放大失效 - 如果用了
user-scalable=no，测试时记得手动双指缩放确认是否真禁用了 - 不要在 CSS 里试图用
@media覆盖 viewport 行为——它俩不在同一层，CSS 无法干预渲染视口计算
rem + media 查询混用时，font-size 基准别在 :root 里硬编码
很多人把根字体大小写死成 :root { font-size: 16px; }，再靠 @media 切换，结果在 iphone SE 和 ipad 上文字大小一模一样——这违背了响应式本意。正确做法是让 font-size 随视口动态变化，@media 只负责分段逻辑。
性能影响：纯 CSS 实现的 rem 基准切换比 js 计算快，但超过 5 个断点后，维护成本陡增；建议用 clamp() 替代多层 @media（如 font-size: clamp(14px, 2.5vw, 18px);），前提是不用兼容 IE。
- IE11 不支持
clamp()，得回退到@media+:root多次覆盖 - 用 JS 动态设置
document.documentElement.style.fontSize时，注意触发重排的时机，避免滚动卡顿 - chrome DevTools 的 Device Toolbar 切换尺寸后，要刷新才能重新触发
@media，不是实时响应
媒体查询里的 min-resolution 和 device-pixel-ratio 别乱混用
min-resolution: 2dppx 和 min-device-pixel-ratio: 2 看似等价，但前者是标准属性，后者是 webkit 私有前缀写法，firefox 和新版 edge 已弃用 device-pixel-ratio。混用会导致高 DPI 设备上规则重复命中或完全跳过。
容易踩的坑：写成 @media (-webkit-min-device-pixel-ratio: 2), (min-resolution: 2dppx) 看似兼容，实则在 Safari 15+ 中两个条件都成立，可能触发两次背景图加载。
- 优先用
min-resolution，单位统一用dppx（1dppx = 1x，2dppx = 2x） - 需要兼容老 android webview？加
min-device-pixel-ratio但单独写一个块，别用逗号合并 - 用
background-image做 @2x 图片时，记得搭配image-set()，比媒体查询更简洁
事情说清了就结束。真正麻烦的从来不是语法，而是不同设备对「视口」「像素密度」「媒介类型」这三者的解释差异——多开几个真机调试，比背一百条规则管用。