屏幕分辨率测试_CSS像素与设备像素换算

逻辑分辨率	DPR	物理像素	宽 × DPR	高 × DPR	说明
1920×1080	1	1920×1080	1920	1080	1080p 显示器 / 笔记本原生
1920×1080	1.25	2400×1350	2400	1350	1080p + Windows 125% 缩放
1920×1080	1.5	2880×1620	2880	1620	1080p + Windows 150% 缩放
1920×1080	2	3840×2160	3840	2160	1080p 笔记本 Retina / 高清屏
1366×768	1	1366×768	1366	768	老款笔记本原生
1366×768	1.5	2049×1152	2049	1152	768 屏 + 150% 缩放，2.36 MP
2560×1440	1	2560×1440	2560	1440	2K 显示器 100%
2560×1440	2	5120×2880	5120	2880	2K + Retina
3840×2160	1	3840×2160	3840	2160	4K 显示器 100%
3840×2160	1.5	5760×3240	5760	3240	4K + 150%，工作区 2560 宽
3840×2160	2	7680×4320	7680	4320	4K 高分笔记本原生
768×1024	2	1536×2048	1536	2048	iPad 竖屏

使用方法

屏幕分辨率测试打开即自动检测，无需点任何按钮。默认示例按 1920×1080、DPR 2 的环境直出，脚本会用你真实的 window 读数覆盖。
「逻辑宽 / 逻辑高」默认取检测到的 screen.width/height，你可以改成任何 1～16000 的值来算别的屏幕。「缩放档位」默认取实测 devicePixelRatio，也可以手填 0.1～10。
点「重新检测」或改动任一输入框都会重算（单行输入裸按 Enter 立即触发）。四张卡给出逻辑分辨率、物理像素、百万像素与宽高比。
「色域 / 触摸点 / 视口方向」三行是附加信息：广色域屏在同 DPR 下观感更细，触摸点数能判断是不是触屏设备。
下方 12 行对照表覆盖 5 种逻辑分辨率 × 6 档 DPR，可导出 CSV；点「复制结果」把整份读数带走。

这个屏幕分辨率测试能解决什么问题

一是回答「我的屏幕到底多少」这个被问错的问题。同一台机器上「分辨率」至少有三种答案：Windows 显示缩放 125% 时，系统把 1920×1080 的物理屏暴露为 1536×864 CSS 像素；浏览器再按 Ctrl+ 加到 150%，视口又变成 1280×720。你去任何一个分辨率检测网站，看到的往往是第三种。本页把四组宽度一次列全，并明确标出每个数字的来源，你自己判断哪个才是你要的。

二是解释「为什么同一张截图在不同设备上尺寸不一样」。一张 3840×2160 的图片，在 DPR 1 的屏上占满窗口，在 DPR 2 的屏上只占四分之一——因为 CSS 像素是布局单位，设备像素才是屏幕上的小格子。物理像素 = CSS 像素 × DPR 这条等式一旦看懂，图片模糊、按钮太小、@media 断点不生效就都不神秘了。

三是给「浏览器缩放导致横向滚动条」一个确切解释。width: 100vw 包含垂直滚动条宽度，而 width: 100% 不包含——这就是为什么用 100vw 的页面会多出 15 像素横向溢出。Windows Chrome/Edge 的经典滚动条是 15 CSS 像素，本页面板里的 innerWidth − clientWidth 就是这个差值。你可以直接看到自己机器上是 15、17 还是 0（macOS 默认 overlay 滚动条常为 0）。

屏幕分辨率测试不做这些事：不告诉你显示器是几寸、什么面板——那是屏幕尺寸计算器的活，需要你自己填物理宽高；不测刷新率、色深、HDR 亮度这些需要用户授权或专用 API 的指标；也不判断「这个分辨率好不好」。如果你要的是CSS 尺寸单位之间的换算（如 1rem 等于多少像素），请用em 转像素。

原理：CSS 像素、参考像素，与四组宽度各自的含义

什么是 CSS 像素，它和英寸是什么关系。CSS Values and Units Level 3 规定「参考像素」为 1 CSS px = 1/96 inch，这是一个约定而非物理事实：CSS 像素的物理大小取决于观看距离与设备密度。devicePixelRatio（由 CSSOM View 规范定义）就是设备像素数 ÷ CSS 像素数这个比值。DPR = 2 表示一个 CSS 像素对应 2×2 个设备像素。所以物理像素 = CSS 像素 × DPR，且因为屏幕上的像素格必须是整数，乘出来的结果要用 Math.round 取整。

为什么 DPR 会有 1.25、1.5、1.75 这种非整数。Windows 的显示缩放档位是 100%、125%、150%、175%、200%、250%、300%，对应的 DPR 就是 1、1.25、1.5、1.75、2、2.5、3。Mac 的非整数缩放同理。这个非整数值带来一个实际后果：物理像素宽不一定是 CSS 宽的整数倍。1366 × 1.5 = 2049 恰好整数，但 1920 × 1.25 = 2400 也整除；真正会出问题的是 175% 这类 7/4 的档位，1920 × 4/7 = 1097.14，落到 1097。这也是本页强调「必须取整」的原因。

四组宽度分别是什么，这是本页最核心的区分。

screen.width / screen.height：整块屏幕的 CSS 像素尺寸，不含浏览器边框、标签栏、地址栏，也不管你窗口开多大。任务栏通常也含在 height 里（screen.availHeight 才是扣掉任务栏后的可用高度）。
innerWidth / innerHeight：视口（viewport）尺寸，也就是 <html> 元素能看到的部分，包含垂直滚动条占位。
clientWidth / clientHeight：视口尺寸不含滚动条。HTML 元素的 clientWidth 一直是布局用的可靠值，正因为它不把滚动条算进去。
outerWidth / outerHeight：整个浏览器窗口外框，含标签栏、地址栏、窗口边框。outerWidth > screen.width 恒成立，除非全屏。

四者的关系可以直接用来诊断问题。outerWidth > screen.width 告诉你窗口确实比屏幕小（没全屏）；innerWidth − clientWidth 告诉你滚动条有多宽；screen.width − clientWidth 则大致等于「窗口边框 + 侧边栏 + 滚动条」的总和。本页在默认环境（1920 宽屏）下的实测是：outerWidth 1936、screen.width 1920、innerWidth 1920、clientWidth 1905，滚动条占位 15 CSS 像素。

缩放如何改变测量结果，这是最容易误解的地方。浏览器缩放（Ctrl +/−）会改变 devicePixelRatio：100% 时 DPR=1，125% 时 1.25，150% 时 1.5，200% 时 2。而同一块 1920 物理像素的屏幕，在这些档位下暴露的 CSS 宽度分别是 1920、1536、1280、960。复算：1920 ÷ 1.25 = 1536（整除）、1920 ÷ 1.5 = 1280（整除）、1920 ÷ 1.75 = 1097.14（不整除，落到 1097）。这就是为什么 Windows 175% 档在 1080p 屏上会出现「可用高度只剩 617」这种反直觉数字——1080 ÷ 1.75 = 617.14，取整 617。

DPR 大不等于屏幕分辨率高，这是本页最想纠正的误解。1366×768 的笔记本，浏览器缩放 200% 后 DPR = 2，和 4K 屏的 DPR 一样是 2，但它的 CSS 可视区只剩 1366 ÷ 2 = 683×384，面积是 4K 屏 CSS 可视区（1920×1080）的 1/7.9。物理像素没变，「看起来更清晰」只是因为单位 CSS 像素变小了。判断屏幕大小要看 screen.width，判断清晰度要看 DPR，两个维度互相独立。

为什么物理像素要 Math.round 而不能直接显示小数。屏幕上的像素格是整数，1366 × 1.5 = 2049 是整数，但 1097.14 这样的值在物理上不存在。本页统一用 Math.round(css × dpr)，并在下表里把「宽 × DPR」「高 × DPR」两列单独列出，让你能看到取整前后的差异。1366 × 1.5 = 2049.0 是整的，但如果换成 1367 × 1.5 = 2050.5，取整就是 2051（Math.round 对 .5 向上）。

用 matchMedia 精确查询 DPR 档位。CSS 媒体查询支持 resolution 单位，window.matchMedia('(resolution: 2dppx)').matches 能逐档匹配实际 DPR，(min-resolution: 2dppx) 做阶梯判断。dppx 的定义是「每 CSS 英寸多少点」，1dppx 即 DPR 1、2dppx 即 DPR 2，因为 1 CSS 英寸 = 96 CSS px，DPR 2 时 1 CSS 英寸就含 192 个设备像素。本页的「缩放档位」输入框就是让你手填这个值来对照。

跨屏拖动时数值会变，页面必须能重算。把窗口从 Retina 屏拖到普通屏，Chrome 会重新计算 DPR 并触发 resize 与 matchMedia 的 change 事件；此时 devicePixelRatio 和 screen.width 都会变。本页监听 resize 自动重算，所以你拖窗口时看到的数字会跟着变——这不是 bug。另外 screen 只报告主屏，副屏的尺寸要用各屏自己的 matchMedia 判断，本页不做多屏枚举。

触点数与色域是附赠的两条线索。navigator.maxTouchPoints 的典型值是 0（无触屏）、5（手机）、10（双屏折叠设备）；window.matchMedia('(color-gamut: p3)').matches 为真表示广色域屏。它们与分辨率无关，但能解释「同样的分辨率为什么这台看着更舒服」。

完整示例（数值仅作演示）

示例条件：逻辑宽 1920、逻辑高 1080、缩放档位 2。逐项核对：

物理宽 = Math.round(1920 × 2) = 3840；物理高 = Math.round(1080 × 2) = 2160；
百万像素 = 3840 × 2160 ÷ 1e6 = 8.29 MP；
宽高比 = 1920 : 1080 = 16 : 9（两边同除以 120）；
滚动条占位 = innerWidth − clientWidth = 1920 − 1905 = 15 CSS 像素；
若改档位为 1.75：物理宽 = Math.round(1920 × 1.75) = 3360（整除，无损）；而反过来按 175% 系统缩放读屏时，screen.width 报的是 1920 ÷ 1.75 = 1097.14 → 1097，高同理 617；
对照表第 6 行是唯一需要看取整效果的一行：1366 × 1.5 = 2049、768 × 1.5 = 1152，两行都能整除，而 3840 × 1.5 = 5760、2160 × 1.5 = 3240 同样整除——
真正会看到小数的组合是 1097 与 617 这类，它们由系统缩放档位（175%、150%）而不是本页的档位输入产生。

这六个数字都能在下方对照表里印证：第 1 行（1920×1080 @ DPR 1 → 1920×1080）与第 4 行（1920×1080 @ DPR 2 → 3840×2160）是同一块屏在两档缩放下的对照；第 6 行（1366×768 @ DPR 1.5 → 2049×1152）说明取整后仍是整数；第 11 行（3840×2160 @ DPR 2 → 7680×4320）是全表最大的物理分辨率，33.18 MP。

输入范围与对照表

逻辑宽 / 逻辑高：1～16000 的整数。0、负数、小数、字母都会被拒绝并指出是哪个字段。上限 16000 覆盖到 8K 屏的逻辑宽度（3840 宽在 DPR 2 下也只有 7680），再大就不是实际屏幕了。
缩放档位：0.1～10，可留空表示「用实测到的 devicePixelRatio」。留空时页面显示真实 DPR 并标注来源；填 0.1 以下或 10 以上会被拒绝——DPR 0.1 意味着 1 CSS 像素只占 1/10 个物理像素，那不是任何真实设备的状态。
三个输入框都是单行，裸按 Enter 立即重算，改动也会实时刷新。

下面这张对照表是全站最常被引用的分辨率换算基准，12 行覆盖 5 种逻辑分辨率与 6 档 DPR：

逻辑分辨率	DPR	物理像素	百万像素	工作区 CSS 宽	常见设备
1920×1080	1	1920×1080	2.07 MP	1920	1080p 显示器，100% 缩放
1920×1080	2	3840×2160	8.29 MP	1920	MacBook Pro 14/16 英寸
1920×1080	1.5	2880×1620	4.67 MP	1280	1080p + Win 150%
1366×768	1	1366×768	1.05 MP	1366	老款笔记本，100%
1366×768	2	2732×1536	4.20 MP	683	同屏缩放到 200%，可视区仅 683 宽
2560×1440	1	2560×1440	3.69 MP	2560	2K 显示器，100%
2560×1440	1.25	3200×1800	5.76 MP	2048	2K + Win 125%
3840×2160	1	3840×2160	8.29 MP	3840	4K 显示器，100%
3840×2160	1.5	5760×3240	18.66 MP	2560	4K + Win 150%，等价 2K 工作区
3840×2160	2	7680×4320	33.18 MP	3840	4K 高分笔记本原生
768×1024	2	1536×2048	3.15 MP	768	iPad 竖屏
1080×1920	3	3240×5760	18.66 MP	360	手机竖屏 DPR 3

最后一行值得注意：1080×1920 是物理分辨率，乘 DPR 3 得 3240×5760，逻辑宽只有 360（1080 ÷ 3）。这就是为什么手机网页的 CSS 断点从不见 1080——1080 那是物理像素，360 才是布局用的数字。同理第 4、5 行的对比最直观：同一块 1366×768 的屏，DPR 1 时可视区 1366 宽，DPR 2 时只剩 683 宽，物理像素完全没变。表里第 2 行与第 10 行也是同一类：1920×1080 @ DPR 2 的物理像素是 3840×2160，工作区 CSS 宽 1920；3840×2160 @ DPR 2 的物理像素是 7680×4320，工作区仍是 3840。

边界与精度说明

DPR 不必是 2 的幂。Windows 125% = 1.25、150% = 1.5、175% = 1.75、250% = 2.5，Mac 的非整数缩放同理。极端组合也会出现：Windows 500% 缩放对应 DPR 5，而 Chrome 页面缩放 500% 叠在系统 200% 上可能测到 DPR 10。此时 1920 × 5 = 9600 已经超过任何真实屏宽——页面照实显示，不做上限截断，因为截断会掩盖真实的缩放状态。
取整用 Math.round 而非 floor。1097.14 用 floor 会得 1097，用 round 也得 1097；但 2050.5 用 floor 得 2050（偏小）、用 round 得 2051。物理像素取整偏小意味着显示的分辨率低于实际，取整偏大意味着「分辨率虚高」——round 至少不会系统性低估。
100vw 溢出的确切数量。Windows Chrome/Edge 的经典滚动条是 15 CSS 像素，部分高对比度主题下是 17（1920 − 17 = 1903）；Firefox 在 overlay 滚动条模式下与 macOS 默认为 0。这就是横向滚动条在 Windows 上出现、在 Mac 上不出现的原因，与 CSS 写法无关。修法是 width: 100% 或 max-width，不是 100vw。
全屏时 outerWidth 接近但不等于 screen.width。按 F11 后 outerWidth 会贴近 screen.width，但差值通常仍非 0，取决于窗口边框是否保留与任务栏位置。所以判断「是否全屏」不能只看两者是否相等。
最小化不改变这些值。窗口最小化后 screen 与 devicePixelRatio 保持不变，只有 innerWidth/innerHeight 可能变成 0 或保持最后尺寸（各浏览器不同）。所以最小化状态下测出的「视口宽」不可信，「屏宽」仍然可信。
精度上不涉及大整数。JavaScript 的安全整数上限是 2⁵³ − 1 = 9007199254740991，本页最大的量是 3840 × 5 = 19200 物理像素宽，相差约 4.7×10¹¹ 倍，取整运算不存在精度损失。
隐私模式与部分 Linux 桌面可能上报虚拟值。某些 Linux 桌面环境或虚拟化场景下浏览器会报 DPR = 1 的虚拟屏值。页面只如实显示读数，不做任何「修正」或推断——它没有可靠途径知道你真实的物理屏。

常见问题

为什么我看到的分辨率和买显示器时标的不一样？

因为「标称分辨率」是物理像素，而网页里的 CSS 像素要乘 DPR。27 寸 4K 屏的标称是 3840×2160，但 Windows 默认 150% 缩放时 screen.width 报的是 2560（3840 ÷ 1.5），网页作者看到的也是 2560。要拿物理值，把 screen.width 乘上 devicePixelRatio，也就是本页表格里「物理像素」那一列。

devicePixelRatio = 2 是不是就等于 Retina 屏？

不是。DPR 是一个比值，任何原因让它变成 2 都会报 2：Retina 屏在 100% 缩放下是 2；普通 1080p 屏在浏览器缩放 200% 下也是 2；Windows 系统缩放 200% 同样是 2。想判断物理分辨率，必须把 DPR 乘回去看 screen.width × DPR，而不是看 DPR 本身。

innerWidth 和 clientWidth 到底该用哪个？

做布局用 clientWidth。它不含垂直滚动条，而 innerWidth 含——这就是 width: 100vw 会比可用宽度多出 15 像素（Windows 经典滚动条）进而产生横向滚动条的原因。判断视口大小时两者都行，判断布局边界时必须用 clientWidth 或 100%。

我把浏览器缩放调大，DPR 就变了，这正常吗？

正常，这是设计如此。浏览器缩放改变的正是「一个 CSS 像素对应多少设备像素」，所以 DPR 会跟着变。100% 时 DPR=1，125% 时 1.25，150% 时 1.5，200% 时 2。物理像素总数始终不变——变的只是你用多大的格子在描述它。所以 DPR 变大不代表屏幕变清晰了，只代表每个 CSS 像素变小了。

为什么 1366×768 缩放到 200% 后可视区只剩 683 宽？

因为 CSS 宽 = 物理宽 ÷ DPR = 1366 ÷ 2 = 683。物理像素一个没少，但描述它用的 CSS 格子变大了一倍，能装下的格子数就减半。这时 screen.width 报 1366（屏幕没变），innerWidth 报 683（视口真的变窄了）。这两个数字同时出现，正好说明「屏幕尺寸」和「可用布局空间」是两件事。

页面为什么每次打开数字都不一样？

因为它读的是你当前这台设备、当前这个窗口的真实状态：窗口大小、是否全屏、有没有滚动条、屏幕缩放档位、是否触屏。别人截的图和你打开时看到不同是正常的。本页顶部的四组宽度与 DPR 就是用来消解这个疑问的——你能看到每个数字的来源，不必猜。

多屏 setups 下这些数值是哪块屏的？

screen 对象只报告主屏，副屏的尺寸需要枚举各屏或用各自的 matchMedia 判断，网页无法拿到完整的多屏列表。把窗口拖到副屏时 screen.width 与 DPR 可能不变，但 innerWidth 会变（视口确实换了），且 DPR 变化时浏览器会触发 resize，本页会自动重算。要精确知道每块屏的参数，用系统自带的显示设置而不是网页。

检测会读取我的隐私或上传信息吗？

不会。全部读数来自 window.screen、window.innerWidth、document.documentElement.clientWidth、navigator.maxTouchPoints 和 matchMedia 这些本地属性，没有任何网络请求，也不写 Cookie 或 localStorage。本页是纯静态页面，你可以断网打开。它也不会申请任何权限——不像摄像头、剪贴板那类 API 会弹授权框。

屏幕分辨率测试

常见逻辑分辨率 × DPR → 物理像素对照（12 行）