screen.width 和 screen.height 返回的不是设备物理分辨率，而是受缩放、dpr、浏览器ui等影响的设备像素值；真正用于ui布局应优先使用 screen.availwidth/availheight。
screen.width 和 screen.height 返回的是设备物理分辨率吗
不是。在多数现代浏览器中，screen.width 和 screen.height 返回的是**设备像素（device pixels）下的屏幕可用宽度/高度**，但受缩放、DPR（devicePixelRatio）、是否全屏、甚至浏览器 UI 占位影响，它往往不等于你直觉里的“显示器分辨率”。比如 Windows 上 125% 缩放时，screen.width 可能比真实物理宽度小 20%；iOS Safari 在横屏时可能返回竖屏数值（因 viewport 锁定行为）。
常见误判场景：
- 用户报告“明明是 2560×1440 屏幕，
screen.width却是 1536” → 很可能是 DPR=2 且缩放导致逻辑像素被压缩 - 在 PWA 全屏模式下读取值突然变小 → 浏览器工具栏隐藏后，部分 Android WebView 仍按非全屏逻辑计算
screen.availWidth / availHeight 更适合 UI 布局决策
如果你真正关心的是“页面最多能用多宽的像素来排版”，应该优先用 screen.availWidth 和 screen.availHeight。它们排除了任务栏、Dock、菜单栏等系统 UI 占用空间，更接近实际可绘制区域。
实操建议：
- 做响应式弹窗最大尺寸限制？用
screen.availWidth * 0.8比硬写1920更鲁棒 - 避免在页面加载完成前就访问 —— 虽然
screen是同步属性，但在某些 iOS WKWebView 初始化阶段可能短暂返回异常值（如 0），建议加一层兜底：const width = screen.availWidth || window.innerWidth || 1280;
- 注意：macOS 的 Dock 默认是自动隐藏的，
availWidth在 Dock 显示/隐藏时不会触发重算，所以它反映的是“当前已知可用”值，不是实时监听项
想获取真实物理分辨率？别依赖 screen 对象
screen 对象本身不提供物理像素（physical pixels）或 DPI 信息。浏览器出于隐私考虑，已逐步限制高精度设备信息暴露。例如 Chrome 88+ 起，screen.devicePixelRatio 在跨域 iframe 中会被降级为 1，而 screen.width 在隐私模式下也可能被四舍五入到最接近的百位数（如 1920 → 1900）。
替代思路（有限但更可靠）：
- 用
window.devicePixelRatio×window.innerWidth粗略估算 CSS 像素对应的设备像素数量（仅适用于视口内区域，非整屏） - 如果目标是适配高清屏，直接用 CSS 媒体查询更稳妥：
@media (-webkit-min-device-pixel-ratio: 2), (min-resolution: 192dpi) { ... } - 需要精确设备型号或 DPI？必须借助原生能力（如 Electron 的
screen.getPrimaryDisplay()或 React Native 的PixelRatio.get()），纯 Web 页面无法绕过浏览器沙箱
screen.orientation 不是分辨率，但常被一起误用
有人试图用 screen.orientation.angle 或 screen.orientation.type 来判断横竖屏进而推算分辨率，这是危险的。因为：
-
screen.orientation在桌面浏览器中支持度差（Firefox 已废弃，Chrome 仅限 Android/iOS） - 即使可用，
type返回的是"landscape-primary"这类字符串，和screen.width > screen.height的判断结果不一定一致（比如旋转屏幕但未触发 orientationchange） - 真正的横竖屏切换应监听
resize事件 + 检查window.innerWidth/window.innerHeight，而不是依赖screen.orientation
一个容易被忽略的事实：很多笔记本外接显示器后，screen.width 仍返回内置屏参数，而非主显示器分辨率 —— 因为 screen 描述的是“当前窗口所在屏幕”的抽象，而浏览器通常只报告主屏或首个检测到的屏，不支持多屏枚举。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
