获取用户屏幕分辨率的HTML方法

本文深入解析了HTML中获取用户屏幕分辨率的关键方法——`screen.width`和`screen.height`，指出它们返回的是设备主显示器的原始物理像素尺寸，恒定不变且不受缩放、窗口大小或浏览器UI元素影响，但正因如此极易被误用于响应式布局等实际场景；文章强调，真正决定用户可见内容区域的是`window.innerWidth/innerHeight`及CSS媒体查询，而`screen`属性仅适用于极少数需判断设备底层能力的场合（如WebGL初始化或横屏检测），并提醒开发者务必结合`devicePixelRatio`才能获得真实物理像素，避免在高DPR或系统缩放环境下产生严重适配偏差。

screen.width 和 screen.height 返回的是设备屏幕的物理像素尺寸（单位：px），不是浏览器窗口大小，也不是 CSS 像素 —— 这一点在高 DPI 设备（如 MacBook、Windows 缩放 125%/150%）上极易误判。

screen.width / screen.height 返回什么值？

它们是 screen 对象的只读属性，反映设备整个显示区域的原始分辨率：

• screen.width：水平方向总像素数（例如 1920、2560、3840）
• screen.height：垂直方向总像素数（例如 1080、1440、2160）
• 不随浏览器窗口缩放、拖拽或全屏切换而变化
• 在多显示器环境下，返回**主显示器**的尺寸（无法区分副屏）

为什么 window.innerWidth / window.innerHeight 更常用？

实际 Web 开发中，你通常关心的是「用户当前能看到多少内容」，而不是屏幕总宽高。比如响应式布局、弹窗居中、图表渲染区域等场景：

• window.innerWidth 和 window.innerHeight 返回的是**视口（viewport）内部可用像素**，受缩放、滚动条、地址栏高度影响
• 在 macOS Safari 中，screen.height 包含菜单栏和 Dock 高度，但用户实际可操作区域更小
• 移动端 Chrome Android 下，地址栏收起/展开会改变 window.innerHeight，但 screen.height 恒定不变
• 如果用 screen.width 判断是否为“大屏”来加载高清图，可能在 125% 缩放的 1920×1080 Windows 笔记本上错误触发 —— 它仍报告 1920×1080，但 CSS 像素只有约 1536×864

真要用 screen.width 做适配？注意这些坑

仅在极少数明确需要设备能力判断的场景才考虑它，比如：

• 上报设备类型（配合 navigator.platform 或 matchMedia）
• 初始化 WebGL 渲染上下文时申请最大缓冲区（需搭配 devicePixelRatio）
• 判断是否为横屏设备（screen.width > screen.height），但注意折叠屏、旋转平板可能动态变化

务必配合 window.devicePixelRatio 使用 —— 例如获取真实物理像素宽高：
const physicalWidth = screen.width * window.devicePixelRatio;
否则在 Retina 屏上，你拿到的 screen.width 是逻辑像素（如 1440），而非设备原生（2880）。

替代方案：用 CSS 媒体查询 + JavaScript 检测更可靠

想根据“可视区域大小”做响应式决策，优先用：

• CSS @media (min-width: 768px) —— 浏览器自动处理缩放与 DPR
• JavaScript 的 window.matchMedia()：
  const mql = window.matchMedia('(min-width: 768px)');
mql.addEventListener('change', handler);
• 监听 resize 事件并读取 window.innerWidth，比轮询 screen.width 更精准也更轻量

硬依赖 screen.width 的代码，在 Windows 缩放设置为 125% 的 1920×1080 屏幕上，会和用户实际感知严重脱节 —— 这个值本身没错，只是它回答的不是你真正想问的问题。

今天关于《获取用户屏幕分辨率的HTML方法》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！