1. 屏幕上量出来的"1厘米"，凭什么信它
去年帮一个做硬件结构的朋友改图纸，他截图发过来，说这个卡扣槽宽"大概两厘米"，让我在页面上直接量一下对不对。我当时随手拿屏幕当尺子比了比，觉得差不多，回了个"没毛病"。结果打样回来，槽宽差了将近 4 毫米，卡扣根本扣不进去。那次之后我才认真把桌面刻度尺这类精确屏幕测量工具的底层逻辑翻了个底朝天，也才有了后面自己动手做一个能用的版本这件事。
核心问题其实特别朴素：屏幕上的"厘米"到底是谁定义的？你打开任何一个图像编辑软件，标尺上那段标着"1 cm"的线，它的长度取决于三层东西——你的显示器物理像素密度、操作系统给的缩放比例、以及软件自己认不认这两件事。任何一层没对上，这把尺子就是坏的，而且坏得很隐蔽：它照样画得整整齐齐，照样有刻度有数字，看上去专业得很，但你拿去量东西，误差可能是 20%，也可能是 70%。
这篇东西想干的事，是把"桌面刻度尺"从一个看着像玩具的小工具，拆成一套能真正落地的东西：它要解决什么、为什么绝大多数在线尺子不准、校准那一步到底在做什么、渲染层有哪些坑、多屏和缩放切换怎么记账、误差能压到什么程度、以及压不下去的部分该怎么办。适合三类人看：做 UI/平面/结构相关工作的、需要经常对着屏幕比对实物尺寸的、以及想自己写一个屏幕测量小工具但不想踩坑的。
先给一个反直觉的结论：屏幕刻度尺的精度，90% 不取决于你画刻度画得多漂亮，而取决于你有没有做校准，以及校准数据在什么条件下会失效。后面所有的实现细节，本质上都是在伺候这一件事。
1.1 三个"像素"混着用，一开始就错了
讲屏幕测量绕不开"像素"这个词，但它在实际语境里至少有三个完全不同的含义，混用一次，后面全歪。
设备像素（device pixel）是最底层的，就是面板上真实存在的发光单元，一个萝卜一个坑，它的物理尺寸由面板工艺决定，改不了。系统逻辑像素是操作系统为了让你在高分屏上看得舒服而虚拟出来的单位，Windows 的 125%、150% 缩放就是在这一层动手脚。CSS 像素是浏览器那一层的名义单位，规范里把它定义成"1/96 英寸"，注意，这是名义定义，不是物理事实——没有任何一条规定说你的屏幕上 96 个 CSS 像素必须正好是一英寸。
| 概念 | 谁定义 | 会不会变 | 和物理毫米的关系 |
|---|---|---|---|
| 设备像素 | 面板硬件 | 不变 | 每个像素的物理边长固定，但厂商不告诉你 |
| 系统逻辑像素 | 操作系统缩放 | 随缩放设置变 | 通过缩放比例间接关联 |
| CSS 像素 | 浏览器规范 | 名义固定 1/96 英寸 | 纯名义，不是物理量 |
| 图片像素 | 图片文件自身 | 不变 | 与屏幕无直接关系 |
这张表最要命的一行是第三行。很多人写屏幕尺子，默认"1 CSS 像素 = 1/96 英寸"，于是直接毫米数 × 96 / 25.4算出像素数就往画布上画。在 96 PPI 的老显示器上，这算法碰巧是对的；在 27 英寸 2K 屏上，实际密度是 108.8 PPI，误差 13%；在 13 英寸 1080p 笔记本上，实际密度 165.6 PPI，误差直接干到 72%。你量 10 厘米的东西，它给你 5.8 厘米，还理直气壮。
所以第一步必须把话说死：屏幕尺子的长度基准不能来自任何"规范默认值"，只能来自一次真实世界的对齐。这就是校准存在的全部理由。
1.2 手算一遍：从毫米到像素到底差多少
拿几个真实存在的屏型算一遍，感受会更直接。公式很简单：
PPI = sqrt(横向像素² + 纵向像素²) / 对角线英寸数 每毫米像素数 = PPI / 25.4- 27 英寸、2560×1440：sqrt(6553600 + 2073600) = 2937.3，除以 27 得108.8 PPI，每毫米4.28 个物理像素，1 厘米约 42.8 像素。
- 13.3 英寸、1920×1080：sqrt(3686400 + 1166400) = 2202.9，除以 13.3 得165.6 PPI，1 厘米约 65.2 像素。
- 24 英寸、1920×1080：2202.9 / 24 =91.8 PPI，1 厘米约 36.1 像素。
- 31.5 英寸、3840×2160：sqrt(14745600 + 4665600) = 4405.8，除以 31.5 得139.9 PPI，1 厘米约 55.1 像素。
同样是"1 厘米"，在这四块屏上对应的像素数从 36 到 65，跨度接近一倍。而如果你的程序写死了 1 厘米 = 37.8 像素（就是那个 96/25.4 算出来的值），那么在 13 英寸笔记本上，你用这把尺子量一张 10 厘米的纸，屏幕上显示的长度只有 5.8 厘米——它会把实物的刻度线画在纸的中间位置，你一眼就能看出来不对。
提示：上面这套算法只适合用来做"预估初值"或者帮助用户理解量级，绝不能直接拿来做最终刻度。原因很简单——厂商标称的对角线尺寸有公差，实际可视区域比标称小一圈，笔记本的"13.3 英寸"往往只精确到 0.1 英寸级别，累积到每毫米上就是百分之几的系统性偏差。校准那一步就是用来吃掉这些偏差的。
1.3 系统缩放这道坎，比 PPI 更容易被忽略
PPI 算错了至少还能看出明显不对，缩放没处理对才是真正的阴间问题，因为它只差 20%~30%，看着"差不多"，实际不能用于任何有公差要求的场景。
举个具体例子。一块 27 英寸 2K 屏，物理密度 4.28 像素/毫米。用户在系统里设了 125% 缩放，于是窗口里 1 个 CSS 像素对应 1.25 个设备像素。你的程序如果要画 10 毫米，算出需要 42.8 个设备像素，然后你把这 42.8 直接当成 CSS 像素去设置width，浏览器又给你乘了 1.25，实际画出 53.5 个设备像素——比该有的长了 25%，10 毫米变成了 12.5 毫米。
这类错误在代码里的表现极其隐蔽，因为它只在"缩放不是 100%"的机器上出现。开发机是 100%，测试同事的是 125%，设计同事的是 150%，三个人看到三把不同长度的尺子，互相甩锅能甩一下午。
正确的记账方式是把"绘制坐标"统一在 CSS 像素空间里，然后换算：
cssPxPerMm = devicePxPerMm / devicePixelRatio其中devicePixelRatio就是缩放倍数。校准环节测出来的应该是设备像素密度，存储时也存设备像素密度，等到画的时候再除以当前的 dpr。这样无论用户怎么改缩放，只要面板没换，比例关系就还成立。这条规则我踩过一次坑之后写进了自己的备忘：存储用设备像素，绘制用 CSS 像素，两者之间的桥只有 dpr 这一座，任何绕过这座桥的换算都是定时炸弹。
2. 校准这一步，决定了它是工具还是玩具
绝大多数在线尺子为什么不给校准入口？因为加了校准，用户第一次打开就得动手对一遍，转化率立刻掉。但你要是真拿它去量东西，就只能接受"仅供参考"。自己做工具就没这个包袱——校准做扎实，用一次管很久。
校准的本质是一次单参数标定：已知实物长度 L（毫米），测出它在屏幕上占了多少像素 P，于是比例系数 k = P / L，单位是像素/毫米。整把尺子此后所有刻度都由 k 决定。听起来简单到不需要讲，但真做起来，卡人的全是细节。
2.1 为什么不能直接采信系统报告的 DPI
有人会想，系统不是提供了 DPI 信息吗，浏览器不是有window.devicePixelRatio吗，读出来不就行了？不行，这三个来源各有各的不可靠。
第一，显示器 EDID 里确实可以带物理尺寸信息，但那个字段是厂家填的，可以乱填，也可以不填。廉价屏、便携屏、某些批次的面板，填的是面板裸片的尺寸而不是可视区尺寸，或者干脆填 0。第二，操作系统层面的 DPI 值经常是一个"用户偏好值"而不是"物理真实值"，Windows 的缩放档位就那么几档，109% 这种精细值是给不出来的，只能取最近的整数档。第三，浏览器能拿到的devicePixelRatio只包含缩放信息，完全不包含物理密度，它连"这块屏每毫米几个像素"这个问题的边都摸不到。
还有一个更玄的情况：虚拟显示、远程桌面、投屏、扩展坞转接，这些链路上物理尺寸信息基本丢失殆尽。我见过一台通过扩展坞接的屏，系统报的 DPI 和实际差了 40%，用户自己都不知道，因为文字看着是清晰的，只是"尺子"不对。
注意：如果你的工具要面向"不知道自己在用什么屏"的普通用户，那么任何依赖系统上报尺寸的方案都必须有兜底校准入口，并且默认引导用户走一次校准。别指望自动检测能救场。
2.2 用一张标准卡片完成校准的完整流程
参照物怎么选？原则是：尺寸有公开标准、家里随手能找到、边是直的、刚性够。标准银行卡尺寸的卡片（85.60 mm × 53.98 mm）是最优解，几乎人人都有，尺寸是国际通用标准，生产公差通常在 ±0.1 毫米级别，对屏幕测量来说绰绰有余。没有卡片的话，一元硬币（直径 25 毫米）也能凑合，但圆形不好对齐，误差会大一截。
具体操作流程我整理成这样，实测走一遍三十秒以内：
- 把卡片的长边紧贴屏幕，注意是贴住，不要悬空，屏幕上会留指纹，擦一下就行。
- 界面上两个可拖动的边界线，初始位置随便，然后把左边的线对准卡片左端。
- 拖动右侧滑块，让右边的线与卡片右端精确重合。重合的判断标准是：从正上方俯视，看不到卡片边缘露出来，也看不到屏幕上的线跑到卡片里面去。
- 界面实时显示当前比例系数和"当前 10 厘米在屏幕上相当于多少像素"，同时给一个校验区——在你的尺子上标出 85.6 毫米的位置，用户可以直接拿卡片比一下。
- 点保存。
为什么优先用长边？因为对齐误差是绝对值，量程越长，相对误差越小。假设肉眼对齐的绝对误差是 ±0.3 毫米，量 54 毫米的短边，相对误差 0.56%；量 85.6 毫米的长边，相对误差降到 0.35%。别小看这 0.2 个百分点，量 30 厘米的东西，差距就是 0.6 毫米。
还有一个提升精度的土办法：把校准视图放大。如果界面支持缩放，让卡片的虚拟边界线在屏幕上放大到 2 倍、3 倍去对齐，肉眼对齐的绝对误差可以压到 ±0.1 毫米以内。代价是用户操作麻烦一点，所以我一般把"快速校准"和"精细校准"做成两个入口，前者给随手用的场景，后者给真有公差要求的场景。
2.3 校准数据的失效判定，比存储更重要
校准值存下来只是开始，什么时候该作废重来才是真正决定工具可靠性的地方。我一开始只存了 k 值，结果用户换了个显示器、改了缩放、把窗口拖到副屏上，尺子还在用老数据，量出来全是错的，而且没有任何提示。
后来改成存一个"指纹"结构，每次渲染前先比对，不匹配就弹提示要求重校：
// 校准记录的结构，字段看着多，实际都是判断失效必需的 const calibration = { pxPerMmDevice: 4.28, // 每毫米设备像素，校准的唯一产出 dpr: 1.25, // 校准时生效的缩放倍数 screenW: 2560, // 校准时所在屏幕的物理宽 screenH: 1440, // 校准时所在屏幕的物理高 availW: 2048, // 可用工作区 CSS 宽，用于粗判屏幕切换 timestamp: 1700000000000 }; function isCalibrationValid(now) { const dprChanged = Math.abs(now.dpr - calibration.dpr) > 0.01; const screenChanged = now.screenW !== calibration.screenW || now.screenH !== calibration.screenH; const workspaceJumped = Math.abs(now.availW - calibration.availW) > 64; return !(dprChanged || screenChanged || workspaceJumped); }这里有几个判断阈值是拍出来的，不是算出来的：dpr 用 0.01 的容差是因为有些浏览器会给 1.2500001 这种值；可用宽度用 64 像素的容差，是为了避开任务栏自动隐藏、侧边栏展开收起造成的抖动，同时又能在换到不同尺寸屏幕时触发。这些阈值没有理论最优解，就是实测调出来的，写死在代码里比留成配置项更省事。
还有一条经验：别自动"修正"校准值。有人想做出"检测到 dpr 变化就自动按比例重算"的功能，听着贴心，实际是灾难。因为 dpr 变化可能伴随着屏幕切换，也可能只是用户改了缩放，两种情况对物理密度的含义完全不同。宁可弹一句"检测到显示设置变化，请重新校准，约需 20 秒"，也不要自作聪明地猜。
3. 刻度画得准不准，全在渲染这四件事上
校准对了，剩下的就是把刻度画出来。这部分看着是纯体力活，实际上有几个地方特别容易出问题，而且出问题之后表现都很"温和"——不是明显错，是看着别扭、量着差一点点。
3.1 Canvas 的两套尺寸，必须分开设置
画刻度一般用 canvas，因为线条多、需要频繁重绘、还要精确控制像素。canvas 有个经典陷阱：它有一个"后备缓冲区尺寸"（width/height属性）和一个"CSS 显示尺寸"（样式表里的宽高），这两个是两回事。高分屏上正确的做法是：
function resizeCanvas(canvas, cssWidth, cssHeight, dpr) { // 后备缓冲区按设备像素申请，保证物理分辨率不丢 canvas.width = Math.round(cssWidth * dpr); canvas.height = Math.round(cssHeight * dpr); // CSS 尺寸保持逻辑像素，页面布局才不会乱 canvas.style.width = cssWidth + 'px'; canvas.style.height = cssHeight + 'px'; const ctx = canvas.getContext('2d'); // 把坐标系整体缩放到 CSS 像素空间，后续绘制只关心逻辑坐标 ctx.setTransform(dpr, 0, 0, dpr, 0, 0); return ctx; }做到这一步，后面所有的绘图代码都可以按 CSS 像素写，不用满脑子想着乘除 dpr。这是我认为最值得坚持的一条纪律：换算只发生在一个地方，并且是入口处。如果绘图代码里散布着* dpr，那这个项目基本可以提前宣告维护不动了。
顺带一个坑：canvas.width赋值会清空整个画布并重置上下文状态，包括变换矩阵、线宽、字体。所以setTransform必须在尺寸设置之后调用，改一次尺寸就得重设一次，别指望它自己记住。
3.2 一像素的线，为什么看起来是两像素
刻度尺最讲究的就是线条锐利。但 canvas 画 1 像素宽的线有个反直觉的行为：如果线的中心线刚好落在整数坐标上，它会横跨两个像素单元，各占一半，也就是抗锯齿后的两条 50% 灰度的线——看起来就是一根模糊的、粗了一倍的线。
解法是把坐标偏移半个像素单位：
// 竖线：x 落在 n + 0.5 上，配合 1 像素线宽，正好填满一个像素单元 function vLine(ctx, x, y1, y2) { const px = Math.round(x) + 0.5; ctx.beginPath(); ctx.moveTo(px, y1); ctx.lineTo(px, y2); ctx.stroke(); }注意这里用的是 CSS 像素空间，所以"半个像素"要换算成0.5 / dpr才是设备像素意义下的半格。不过在 dpr 是整数（1、2、3）的情况下，0.5这个 CSS 偏移活力最好，因为0.5 × 整数 dpr仍然是整数加半，每个设备像素精确对半。dpr 是 1.25、1.5 这种非整数时，就无法做到绝对锐利了，这时候要么接受轻微柔化，要么把关键刻度线加粗到 2 像素让它看起来是刻意加粗的。
实际取舍是：主刻度线画 1 像素并做半像素对齐，次刻度线接受柔化。因为人眼对小刻度的柔化几乎无感，但对主刻度线的模糊很敏感——主刻度是要拿来做对齐基准的线，模糊就等于对齐精度下降。
3.3 刻度密度要自适应，别硬套 1 毫米一格
常识里尺子是 1 毫米一个小格，但屏幕尺子不能无条件照搬。低 PPI 屏上每毫米只有 3.6 个像素（91.8 PPI 那台），1 毫米一格意味着间隔 3.6 像素，加上抗锯齿，整排刻度会糊成一片灰带，完全没法读。
我的做法是按"屏幕上的间隔像素数"来分级：
| 每毫米像素数 | 小格间隔 | 中格间隔 | 大格（带数字） | 说明 |
|---|---|---|---|---|
| ≥ 6 | 1 mm | 5 mm | 10 mm | 高分屏，最接近实体尺 |
| 4 ~ 6 | 1 mm | 5 mm | 10 mm | 常见 2K，仍可读 |
| 2.5 ~ 4 | 2 mm | 10 mm | 20 mm | 中低密度，降级一档 |
| < 2.5 | 5 mm | 25 mm | 50 mm | 低密度或视距很远的场景 |
分级阈值不是玄学，是从"小格间隔至少 4 个像素才不糊"这条经验出发定的，再往上留了点冗余。数字标注只放在大格上，字号固定 11 CSS 像素，因为刻度尺上的数字是为了快速读数，不是为了美观，字号小了读得慢，大了会挤占刻度空间。
还有一个细节：数字要避免和刻度线重叠，通用做法是把数字绘制在刻度线端点外侧一段固定距离，并且按textAlign做左右避让——最左端的大格数字右对齐，最右端的左对齐，中间的居中。这个处理不做的话，尺子两端会出现半个数字被裁掉的情况，看着很不专业。
3.4 一套够用的绘制骨架
把上面几件事攒起来，核心绘制逻辑差不多长这样：
function drawRuler(ctx, opts) { const { width, height, cssPxPerMm, horizontal } = opts; ctx.clearRect(0, 0, width, height); // 按密度选档 const step = cssPxPerMm >= 4 ? 1 : cssPxPerMm >= 2.5 ? 2 : 5; const longStep = step * 10; const midStep = step * 5; ctx.strokeStyle = '#1a1a1a'; ctx.fillStyle = '#1a1a1a'; ctx.font = '11px system-ui, sans-serif'; const maxLen = horizontal ? width : height; for (let mm = 0; mm * cssPxPerMm <= maxLen; mm += step) { const pos = mm * cssPxPerMm; const isLong = mm % longStep === 0; const isMid = mm % midStep === 0; // 线越长表示刻度级别越高 const len = isLong ? 18 : isMid ? 12 : 6; ctx.lineWidth = isLong ? 1 : 1; if (horizontal) { const x = Math.round(pos) + 0.5 * (isLong ? 1 : 1); ctx.beginPath(); ctx.moveTo(x, 0); ctx.lineTo(x, len); ctx.stroke(); if (isLong) { ctx.textAlign = mm === 0 ? 'left' : 'center'; ctx.fillText(String(mm / 10), x, len + 14); } } else { const y = Math.round(pos) + 0.5; ctx.beginPath(); ctx.moveTo(0, y); ctx.lineTo(len, y); ctx.stroke(); if (isLong) { ctx.textBaseline = 'middle'; ctx.fillText(String(mm / 10), len + 6, y); } } } }这段代码里mm / 10是因为大格对应厘米，尺子上标厘米比标毫米好读。刻度起点从窗口边缘开始，意味着用户必须把窗口贴到被测物体的边上——所以工具最好提供一个"把窗口钉在最前面、去掉边框"的模式，否则窗体外框那圈阴影会直接毁掉对齐精度。这个细节在很多同类工具里都没处理，实际用起来特别难受。
4. 拖到另一块屏幕上，这把尺子就废了
单屏用户可能感受不到，但只要涉及外接显示器，坐标记账立刻变成主要矛盾。我最初版本在双屏环境下几乎不可用，用户把窗口从主屏拖到副屏，尺子立刻不准，而且没有任何提示。
4.1 devicePixelRatio 会变，而且变得很突然
devicePixelRatio不是常量。窗口跨屏移动时会变，系统缩放改了会变，接了外接屏会变，浏览器页面缩放（Ctrl+加号）也会变——注意最后这个很多人漏掉，浏览器自身的页面缩放同样会改devicePixelRatio，所以用户"不小心放大了网页"这个操作也会让尺子失准。
监听变化不能靠轮询，虽然轮询（比如每秒读一次）也能用，但浪费且滞后。比较靠谱的写法是用matchMedia绑定当前的 dpr 值，一旦变化这个媒体查询就会触发：
function watchDpr(onChange) { let mql = null; const bind = () => { const dpr = window.devicePixelRatio; mql = window.matchMedia(`(resolution: ${dpr}dppx)`); const handler = () => { mql.removeEventListener('change', handler); onChange(window.devicePixelRatio); bind(); // dpr 变了之后要按新值重新绑定，否则只触发一次 }; mql.addEventListener('change', handler); }; bind(); }这段代码有个必须注意的点：回调里要重新绑定。因为媒体查询一旦匹配失败，这个监听就失效了，不会再触发第二次。只绑一次的话，用户改两次缩放，第二次就捕获不到。
4.2 换屏之后，唯一的正确做法是重新校准
有人会想：副屏和主屏分辨率一样，是不是就不用重校了？不一定。分辨率一样不等于 PPI 一样——24 英寸 1080p 和 15.6 英寸 1080p 分辨率完全相同，但 PPI 差了 54%，物理密度差了整整一半。所以分辨率绝对不能作为"同一块屏"的判据。
我的处理策略是分桶存储：以分辨率 + dpr + 可用工作区宽高作为一个粗指纹，每块屏校准一次就存一个桶。用户在两块屏之间来回切，各自读各自的桶，命中了就直接用，没命中就提示校准一次。实际用下来，双屏用户第一次要各校一次，之后就很顺畅了。
这个方案有个边界情况要处理：两块完全相同型号的外接屏，指纹是重合的，会共用一个桶。好在同型号屏的物理密度一样，共用反而是对的。真正需要小心的是笔记本内屏加同尺寸外接屏这种组合，两者可能有细微的型号和批次差异，但差异通常在 1% 以内，对绝大多数用途够用了。如果有极端精度要求，就得让用户手动给每块屏命名区分，这就属于"过度设计换来的复杂度"，我一般不做。
4.3 窗口位置和测量基准的关系
还有一个容易忽视的点：测量基准应该绑定在窗口的哪个边缘。如果尺子的零点在窗口内容区左上角，那么窗口边框、标题栏、系统阴影都会成为干扰。用户把窗口贴到物体左边时，实际贴住的是带阴影的窗口外沿，而零点在内侧，中间差了几个像素，量出来直接偏。
处理方式有两种，各有取舍。一种是提供"无边框全屏条"模式，只保留一条细窄的尺子，没有任何装饰，用户把这条贴到物体边上，零点就在贴边处，误差最小。另一种是在窗口内画一条"校准基准线"，明确告诉用户这条线才是零点，并且允许用户手动调整这条线相对于窗口的位置偏移。
我更倾向第一种，因为它把"对齐"这个动作变简单了：用户不需要理解偏移量的概念，只要把窗口边缘对准物体边缘就行。第二种适合需要精确控制零点的场景，比如量两个孔之间的距离。两种模式并存也不冲突，做成两个快捷键切换就好。
5. 误差账本：哪些能压下去，哪些只能认
工具做到这个程度，是时候诚实地面对一个问题了：它能准到什么程度？我的态度一直是，与其宣传"高精度"，不如把误差来源列清楚，让用户自己判断这个工具适不适合他的场景。下面这份账本是我实测加推算混出来的，量级可信，具体数值会因设备而异。
| 误差来源 | 典型量级 | 能否修正 | 处理方式 |
|---|---|---|---|
| 未做校准，直接按 96 DPI 算 | 13% ~ 72% | 能 | 必须校准，没有商量余地 |
| 系统缩放未计入 | 20% ~ 50% | 能 | 存储设备像素密度，绘制时除以 dpr |
| 参照物自身公差 | ±0.1 mm（约 0.12%） | 部分 | 用长边、用标准卡片 |
| 肉眼对齐误差 | ±0.1 ~ 0.3 mm | 部分 | 放大视图后对齐，取多次平均 |
| 面板有效区与标称尺寸偏差 | 0.3% ~ 1% | 不能 | 校准会吃掉大部分，残余无法消除 |
| 屏幕边缘的非线性 | 边缘 1~3 mm 内明显 | 不能 | 避免在屏幕最边缘读数 |
| 曲面屏的曲率影响 | 视曲率，可达数毫米 | 不能 | 曲面屏上只用中间区域 |
| 视角造成的视差 | 1 ~ 5 mm | 部分 | 正上方俯视，别斜着看 |
| 亚像素舍入 | < 0.5 个设备像素 | 能 | 半像素对齐 |
把这张表翻译成人话就是：校准之后，短距离（10 厘米以内）测量，误差可以控制在 ±0.5 毫米量级；30 厘米左右，±1.5 毫米是可期待的；超过 40 厘米，就不要再指望它了，因为屏幕本身没那么大，而且长距离下对齐误差和视角误差都会成倍放大。
5.1 一次实测：三种屏、两个量程、校准前后
为了有点体感，我用三台设备做了一轮对比，方法是在屏幕上画一条 100 毫米和一条 200 毫米的线，然后用实体钢尺去量它在屏幕上实际占的长度。钢尺最小刻度 1 毫米，读数误差按 ±0.5 毫米算。
| 设备 | 物理密度 | 校准前 100 mm 实测 | 校准后 100 mm 实测 | 校准后 200 mm 实测 |
|---|---|---|---|---|
| 27 英寸 2K | 4.28 px/mm | 88.5 mm | 100.2 mm | 200.4 mm |
| 13.3 英寸 1080p | 6.52 px/mm | 57.8 mm | 99.7 mm | 199.5 mm |
| 24 英寸 1080p | 3.61 px/mm | 105.8 mm | 100.4 mm | 200.7 mm |
三台设备的校准前偏差分别是 -11.5%、-42.2%、+5.8%，方向和幅度完全由物理密度与"假设的 96 DPI"之间的差值决定，跟设备贵不贵没关系。校准之后，100 毫米量程的误差落在 ±0.4 毫米内，200 毫米落在 ±0.7 毫米内，这个结果和上面账本的推算基本吻合。
有个细节值得说：200 毫米量程的误差比 100 毫米大，但并不是成比例放大。原因是校准误差是"比例型"的，会随量程线性放大；而对齐误差是"固定型"的，不随量程变。两者叠加之后，表现出来的就是量程越长、绝对误差越大，但相对误差反而趋于稳定。这也解释了为什么校准参照物越长越好——把比例型误差压下去，剩下的大头就是固定型误差了。
5.2 什么时候应该干脆放弃屏幕测量
有些场景我明确建议别用屏幕尺子，硬上只会给自己找麻烦。
需要公差配合的场合，比如榫卯、螺纹、卡扣，这些往往要求在 0.1 毫米级别，屏幕测量够不到，直接上卡尺。需要跨设备一致性的场合，比如让十个同事各自量同一张图，每台机器的校准状态、缩放设置、甚至面板老化程度都不同，结果没法对齐。需要测曲面或异形的场合，屏幕是平的，被测物是弯的，投影关系就错了。还有法律效力或验收凭证的场景，屏幕截图没有可追溯的计量链路，不能作为依据。
反过来说，屏幕尺子最舒服的场景是：量 UI 元素的物理观感、估一下实物大概尺寸、校验打印件的比例、比对一个东西塞不塞得进某个空间。这些场景的容差普遍在 1 毫米以上，屏幕尺子完全胜任，而且比翻箱倒柜找卷尺快得多。
6. 从一把尺子，到一套自己的屏幕测量习惯
工具本身做完了，但真正让我觉得"这东西有用"的，是后面延伸出来的几种用法。这部分算是副产品，但实际价值可能比尺子本身还高。
6.1 反推屏幕的真实 PPI 和尺寸
既然校准这一步已经测出了每毫米多少设备像素，那 PPI 就是现成的：
PPI = pxPerMmDevice × 25.4反推出来的 PPI 拿去和"分辨率 + 标称对角线"算出来的理论值一比，就能判断这块屏的标称尺寸靠不靠谱。我那台标称 27 英寸的屏，实测反推 PPI 是 109.6，理论值是 108.8，反推出来的对角线约 26.8 英寸，差距 0.2 英寸，在合理范围内。但另一台便携屏就不一样了，标称 15.6 英寸，反推出的对角线只有 14.9 英寸——差 0.7 英寸，基本可以确定标称值掺了水。
这个能力有个实用场景：买显示器的时候，商家标的"27 英寸"到底是可视区还是含边框，很多时候说不清。有校准数据在手，一分钟就能验出来。当然，前提是校准本身要够准，用短边校准出来的 PPI 会有 1% 左右的抖动，想验尺寸就得用长边、放大了对齐。
6.2 把网页元素和截图里的东西也量了
做前端或者做设计评审的时候，经常遇到"这个按钮在实物上会不会太小"这种问题。有了每毫米像素数，浏览器里量元素的物理尺寸就是一次除法：
// 假设已经从校准数据里拿到了 cssPxPerMm const rect = document.querySelector('#target').getBoundingClientRect(); const widthMm = rect.width / cssPxPerMm; const heightMm = rect.height / cssPxPerMm; console.log(`元素物理尺寸约 ${widthMm.toFixed(1)} × ${heightMm.toFixed(1)} 毫米`);这个用法在评估触控目标尺寸时特别有用——无障碍规范里常提"触控目标不小于 44×44 逻辑像素"，但那是逻辑像素，实际手指按上去舒不舒服，得看物理尺寸。一个 44 像素的按钮，在 6.5 像素/毫米的笔记本上只有 6.8 毫米宽，在 3.6 像素/毫米的大屏上有 12.2 毫米宽，手感天差地别。这种差异光看截图是看不出来的，必须换算到物理尺寸。
同理，截图里量物件也能做，但有个前提：截图必须是在当前这块屏上、当前这个缩放比例下截的。如果截图是别人发来的，或者是在另一块屏上截的，那比例关系就断了，量出来没有意义。这个限制我在工具里用一句提示兜住：“当前测量基于本机屏幕校准，外部截图请自行确认来源”。
6.3 打印校验：用屏幕尺子反查打印机
这是一个我自己都没想到会常用的场景。打印一份带 100 毫米标尺线的测试页，打印出来之后，拿屏幕尺子去量纸上的那条线——如果屏幕上显示 100 毫米、纸上实际是 103 毫米，说明打印机在那个方向上放大了 3%。
这个用法成立的前提是屏幕尺子本身校准过，误差在 0.5% 以内。虽然精度不如专业的打印校准工具，但胜在快，而且不需要额外硬件。我调过一台老喷墨，纵向缩放偏了 2.7%，打完的表格总是对不齐，用这个方法三分钟就定位到问题出在驱动里的"适应页面"选项上。
6.4 给团队落地时的几条实在建议
如果要把这套东西推给团队用，我踩过的几个坑值得提前说。
第一，别把校准值当全局配置下发。每台机器的屏幕不一样，必须各自校准，统一配置是灾难的开始。第二，在新人入职的机器上做一次演示校准，让他们亲眼看到"校准前差 40%、校准后差 0.5 毫米"的对比，比发十页文档有用。第三，把"这是屏幕测量结果，容差约 ±1 毫米"写进交付说明，避免有人拿它当精密测量依据去跟供应商吵架。第四，定期复核，尤其是换过显示器或者升级过系统之后，重新走一遍校准，两分钟的事，能省掉后面半天的返工。
我个人在实际操作中的体会是：屏幕刻度尺这类工具的价值，不在于它能替代钢尺，而在于它把"随手量一下"这件事的成本降到了接近于零。你要是每次都得翻抽屉找尺子，很多小疑问就懒得去验证了，最后靠猜，猜错的代价往往比量一下大得多。把校准做扎实、把误差范围说清楚，它就是一个非常趁手的东西；把校准省掉、把精度吹上天，它就是一把漂亮但会骗人的尺子。区别只在那二三十秒的校准动作上。
