在线屏幕坏点检测工具：亮点暗点漏光测试与验机SOP

1. 先聊清楚：我为什么非要自己做一个坏点检测页

上个月帮人验一台刚到手的显示器，开箱、通电、拆膜，一切顺利。结果切到白色背景的一瞬间，右上角偏下的位置有个非常扎眼的红点。买家当场愣住，卖家客服的回复是"3 个以内属于正常范围"。这种事我遇到过不止一次，后来干脆写了一个自用的在线坏点检测工具，主打三件事：亮点、暗点、漏光测试，打开网页、点一下全屏，就能把整块屏幕逐色过一遍。它不装客户端、不读系统信息、不上传任何数据，就是几十 KB 的静态页面，手机、平板、笔记本、外接显示器、电视盒子接的屏，只要能开浏览器就能用。

这个东西的价值其实不在"技术多难"，而在于把一套原本靠经验和工具盘的流程标准化了。以前测一块屏，你得手动去改桌面壁纸，一张一张切纯色图，还得记住哪些颜色对应查哪种缺陷；现在按一下方向键就能在八个标准色之间循环，配合灰阶、渐变、栅格、拖影几个附加页，一块屏从开箱到出具结论，五分钟能走完。我写它的初衷是自用，后来发现身边做二手设备流转的、装机店的、还有单纯想验机的普通用户，需求出奇地一致，于是把它整理成了一个通用页面。

适合谁看这篇：准备买显示器/笔记本/手机、想开箱就验的人；做设备流转、需要快速出检测结论的人；以及想自己动手写一个同类小工具的前端同学。下面我会把这套工具的设计思路、核心实现、完整的检测 SOP、以及判读时那些容易被忽略的坑全部拆开讲，代码片段都是可以直接抄的。

2. 概念先理清：屏幕缺陷远不止"坏点"两个字

2.1 亮点、暗点、彩点：都是像素级故障，但成因不一样

很多人把屏幕上的异常点统称为"坏点"，实际上按显示表现至少分三类。亮点（也叫常亮像素）是不管画面显示什么内容，那个像素都保持点亮状态，在纯黑背景下最刺眼，通常是一个白色或接近白色的小方块。暗点（常暗像素）正好相反，那个像素永远不亮，在黑背景下完全隐身，只有在白色或浅色背景下才会露出一个黑点。彩点是子像素级别的故障——液晶面板每个像素由红、绿、蓝三个子像素组成，如果只有其中一个卡死，你看到的就不是黑白点，而是一个红色、绿色或蓝色的点。

这个区分特别重要，因为它直接决定了检测顺序。我见过太多人打开一个黑屏页面扫了两眼，说"没有坏点"，然后收货。兄弟，暗点在黑屏上你根本看不见。也见过有人盯着黑屏上的红点猛擦屏幕，擦了半天发现擦不掉——那玩意儿在面板里面，你擦一年也没用。判断技巧我总结成一句话：黑背景找亮点和彩点，白背景找暗点，红绿蓝三色背景找对应子像素的异常。一个点在黑屏上是红的，说明红色子像素常亮；在白屏上是黑的，说明整个像素不工作；在某个颜色背景下"消失"了，说明问题出在那个颜色的子像素上。

2.2 漏光与均匀性：背光层面的问题，和坏点完全是两码事

漏光是 LCD 面板的结构性问题——背光模组的光从面板边缘或装配缝隙里"漏"出来，表现是黑背景下屏幕四角或边缘出现不规则的浅色光斑。它和坏点的区别在于：漏光是成片的、边界模糊的、亮度不均匀的，而坏点是点状的、边界清晰的。IPS 面板几乎必然存在一定程度的漏光，这是技术原理决定的，不完全是品控问题，判断的关键是"程度"和"是否影响日常使用"。

比漏光更容易被忽略的是亮度均匀性和色温均匀性。有些屏幕没有明显漏光，但整块屏从左到右亮度递减，或者左边偏冷右边偏暖。这种问题在纯白背景下看不出来，必须用中低灰阶（比如 20%~40% 灰）才明显。我在工具里专门做了 0、16、32、64、128、192、255 七级灰阶页面，就是为了抓这类"整体性缺陷"——它比单个坏点更影响观感，但往往被买家忽略，等用了一周才发现，售后就难谈了。

2.3 残影、烧屏与拖影：三个最容易被误判成坏点的现象

残影（Image Retention）是 LCD 上长时间显示静态画面后，切换内容时旧画面短暂残留的现象，通常几分钟到几十分钟会自行消失，属于可逆的。烧屏（Burn-in）是 OLED 上的不可逆老化，像素发光效率衰减导致的永久印记，表现是某个区域整体偏暗或偏色，形状往往和 UI 元素（状态栏、导航栏、输入法候选框）高度吻合。拖影是像素响应时间不足导致的运动模糊，只在动态画面下出现，静止画面完全正常。

三者容易被误判的原因很简单：残影看起来像"一大片坏点"，烧屏看起来像"屏幕上有个水印"，拖影在快速切换页面时会被当成"屏幕抖动"。区分方法也很直接：残影会自己消失，你放一段纯白画面十分钟再回来看；烧屏不会消失，而且形状有规律；拖影只在动的时候出现，静止时一切正常。工具里我加了一个移动方块页面和一个色块平移页面，就是专门给拖影准备的，虽然精度比不上专业仪器，但判断"有没有明显拖影"足够了。

2.4 到底几个点算不合格：把标准说人话

这是所有检测里最现实的问题。业界普遍参考的是像素缺陷分级体系，把缺陷分成常亮像素、常暗像素、子像素缺陷、簇状缺陷几大类，再按允许数量划分质量等级。消费级显示器、笔记本屏幕大多数按较宽松的等级执行——通俗说就是亮点基本零容忍，暗点和彩点允许极少量存在，具体数字各家售后政策不同，也经常成为扯皮的焦点。

我的建议是别死磕数字，按这个顺序走：第一，先查厂商官网公开的售后政策里对"亮点/暗点"的明确表述，有白纸黑字最省事；第二，开箱 7 天内发现问题立刻报备，很多渠道的"七天无理由"比"质量问题认定"好用得多；第三，如果确实超出政策范围但数量明显偏多（比如一整条边上连着四五个点，或者屏幕中央出现簇状缺陷），走"影响正常使用"的角度沟通，成功率比单纯争"数量"高。中央区域一个点和边角三个点，实际体验差别巨大，这个道理客服也懂。

3. 工具的整体设计与技术选型：为什么我选了最"土"的纯前端方案

3.1 纯静态页面的三个理由

做这类工具，方案其实有很多：写个 Electron 桌面应用、搞个 Python + OpenCV 的自动化检测脚本、甚至用系统自带的显示器测试功能。我最后选了最朴素的纯静态 HTML + CSS + JS，理由有三个。第一是零门槛，用户不需要装任何东西，发个链接过去就能用，这对"开箱现场验机"这个场景太关键了——你不可能让一个刚拆快递的人在五分钟内配好 Python 环境。第二是渲染路径最短，页面直接由浏览器合成器输出到屏幕，中间不经过任何图像处理管线，不会引入额外的缩放、锐化、色彩映射干扰判断。第三是无依赖，没有构建步骤，没有第三方库，一个 HTML 文件丢到任何静态托管上就能跑，十年后打开还能用。

代价也很明显：浏览器管不到硬件层。你没法真正读取面板信息，没法关闭系统的色彩管理，没法强制 10bit 输出，也没法精确测量亮度和色温。所以这个工具的定位必须说清楚——它是人眼目视检查的辅助工具，不是校准仪。它能帮你快速发现问题，但不能告诉你 ΔE 是多少。想清楚这条边界，后面所有的设计取舍就顺了。

3.2 页面骨架与状态管理：一个数组搞定所有

整个工具的交互模型可以抽象成"一组全屏画面 + 一个索引指针"。我把所有测试画面定义成一个页面数组，每项包含类型、颜色值、说明文字，切换就是改索引，渲染就是根据类型走不同分支。这种结构的好处是加新测试页只需要往数组里推一项，不用改任何控制逻辑。

const PAGES = [ { type: 'solid', color: '#000000', name: '纯黑 · 查亮点与彩点' }, { type: 'solid', color: '#FFFFFF', name: '纯白 · 查暗点与色斑' }, { type: 'solid', color: '#FF0000', name: '纯红 · 查红子像素' }, { type: 'solid', color: '#00FF00', name: '纯绿 · 查绿子像素' }, { type: 'solid', color: '#0000FF', name: '纯蓝 · 查蓝子像素' }, { type: 'solid', color: '#00FFFF', name: '青色 · 查混色异常' }, { type: 'solid', color: '#FF00FF', name: '洋红 · 查混色异常' }, { type: 'solid', color: '#FFFF00', name: '黄色 · 查混色异常' }, { type: 'gray', level: 0, name: '灰阶 0%' }, { type: 'gray', level: 20, name: '灰阶 20% · 查均匀性' }, { type: 'gray', level: 50, name: '灰阶 50%' }, { type: 'gray', level: 80, name: '灰阶 80%' }, { type: 'gradient', name: '灰阶渐变 · 查断层与色带' }, { type: 'grid', name: '像素栅格 · 查锐度与缩放' }, { type: 'motion', name: '移动方块 · 粗略观察拖影' } ]; let cursor = 0;

状态就这么点。我特意没引入任何框架，因为这类工具的核心诉求是"打开就能用、切页要跟手"，多一层响应式绑定就多一层延迟风险。用原生 DOM 直接改style是最稳的，实测在低端安卓机上也毫无卡顿。

3.3 全屏、常亮、隐藏鼠标：三个必须解决的环境问题

全屏是第一优先级。没全屏，浏览器地址栏和标签栏会占掉屏幕上下两块，边缘区域的缺陷直接漏检。标准做法是调 Fullscreen API：

async function toggleFullscreen(el) { try { if (!document.fullscreenElement) { await el.requestFullscreen({ navigationUI: 'hide' }); } else { await document.exitFullscreen(); } } catch (err) { // 部分移动端浏览器不支持元素全屏，降级为撑满视口 el.classList.toggle('pseudo-fullscreen'); } }

这里有个必须知道的坑：移动端浏览器对元素级全屏的支持一直不完整，很多环境下requestFullscreen会直接抛异常。所以我的降级方案是用 CSS 把容器高度设成100dvh（动态视口高度，比100vh更准确，能避开移动端地址栏收起展开导致的高度跳变），配合position: fixed; inset: 0;覆盖整个视口。虽然地址栏还在，但主体区域已经最大化了，对判断中心区域的缺陷够用。

常亮是第二优先级。测一块屏要几分钟，中间如果屏幕自动息屏，不但打断节奏，还可能把刚发现的点"忘掉"。现代化方案是 Screen Wake Lock API：

let wakeLock = null; async function keepScreenAwake() { if (!('wakeLock' in navigator)) return; try { wakeLock = await navigator.wakeLock.request('screen'); } catch (e) { /* 用户拒绝或电量过低，忽略 */ } } document.addEventListener('visibilitychange', async () => { if (wakeLock !== null && document.visibilityState === 'visible') { try { wakeLock = await navigator.wakeLock.request('screen'); } catch (e) {} } });

注意这里要处理visibilitychange。系统在页面切到后台时会自动释放 wake lock，切回来必须重新申请，否则用户来回切两次标签页，第三次开机就息屏了，体验极差。这是我在实际使用中踩过的坑，一开始只申请一次，测试到一半屏幕黑了，还以为是自己按错了键。

隐藏鼠标是第三优先级，用一行 CSS 就够：cursor: none;。听起来是小事，但在纯黑背景下，一个大白鼠标箭头会严重干扰你找亮点——因为它也是个白点。同样地，界面上所有 UI 元素在进入全屏后都应该淡出，只在鼠标移动或按键时短暂浮现一下然后自动隐藏。

4. 核心功能实现：从纯色轮播到灰阶渐层

4.1 纯色全屏填充与键盘/触屏切换

纯色页是整个工具的主干，实现上就是把容器背景色改成目标色，同时保证它铺满整个屏幕区域且没有任何内边距、边框、圆角：

.stage { position: fixed; inset: 0; margin: 0; padding: 0; border: 0; overflow: hidden; cursor: none; transition: none; /* 关键：绝对不能加过渡动画 */ -webkit-user-select: none; user-select: none; }

transition: none这一行看似多余，其实非常关键。早期版本我给颜色切换加了 0.2s 的过渡动画，看着挺优雅，结果在渐变过程中会出现中间色，如果屏幕存在特定色域的异常点，动画期间根本抓不住。更要命的是，过渡会让眼睛来不及适应亮度突变，切到白色时瞳孔收缩需要时间，过渡反而打乱了适应节奏。测试类工具的一切视觉装饰都该砍掉，这是我做这个工具最深的体会之一。

切换逻辑用键盘事件监听，方向键右/空格下一页，左键上一页，Esc 退出：

document.addEventListener('keydown', (e) => { if (e.key === 'ArrowRight' || e.key === ' ') { e.preventDefault(); cursor = (cursor + 1) % PAGES.length; render(); } else if (e.key === 'ArrowLeft') { e.preventDefault(); cursor = (cursor - 1 + PAGES.length) % PAGES.length; render(); } });

移动端没有方向键，方案是点击屏幕右半区下一页、左半区上一页，用click事件的clientX判断。这里要注意e.preventDefault()防止空格触发页面滚动，以及双指缩放要禁用：

<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1, user-scalable=no, viewport-fit=cover">

viewport-fit=cover是给刘海屏/挖孔屏准备的，让页面延伸到异形区域下面，这样屏幕各个角都能被纯色覆盖到——要知道现在很多手机的挖孔周围恰恰是最容易出问题、也最容易被忽略的地方。

4.2 灰阶与低亮度均匀性测试：为什么纯白反而看不出问题

很多人验屏只用黑白两色，这是最大的误区之一。纯白画面下，人眼对亮度的感知被压缩了，一块左边亮 300nit、右边亮 280nit 的屏幕，在纯白下你几乎看不出差异；但换到 20% 灰（大概 50~60nit），这个差异会立刻明显起来。这就是为什么所有专业均匀性测试都推荐在中低灰阶下观察。

我在工具里做了四级灰阶：0%、20%、50%、80%。使用方法是这样的，纯白页快速扫一遍找暗点；然后切到 20% 灰，退后一米，眯起眼睛看整体，重点观察四个角、四条边中段、以及屏幕正中央。如果某一块明显比其他区域亮或暗，或者整个屏幕呈现出明显的"阴阳脸"（半边亮半边暗），那就是均匀性问题。眯眼的动作不是玄学，它能削弱细节、突出大面积亮度差异，配合上人眼的周边视觉，判断均匀性比瞪大眼睛逐点扫更准。

灰阶值直接用 RGB 三通道同值填充就行，20% 对应#333333。这里有个细节需要提醒：不要用图片做灰阶。PNG 或 JPG 图片会经过色彩管理、缩放插值，实际显示值可能和你想要的 51,51,51 差不少。用 CSS 背景色是最"干净"的方式，浏览器直接把色值交给合成器，中间不做任何色彩空间转换（SDR 场景下）。

4.3 渐变与色阶断层排查：区分"面板不行"和"片源不行"

灰阶渐变页是一条从黑到白的水平渐变，用途是检查色阶断层（Color Banding）。理想情况下，你看到的应该是平滑连续的过渡；如果出现明显的"台阶"或"色带"，就是断层。断层有两个来源：一是面板色深不够（6bit 面板没做抖色），二是信号链路被压缩（比如输出位深设成了 6bit 而不是 8bit，或者开了有损压缩的传输格式）。

关键判断技巧：浏览器渲染的 CSS 渐变在 8bit 色深下几乎必然出现轻微断层，这是正常的，因为相邻两个色阶之间的差值就是 1/255，人眼在渐变区域能分辨出来。所以别把正常的 8bit 台阶当成故障。真正需要警惕的是大块跳跃——比如某一段直接从 30% 灰跳到 40% 灰，中间没有过渡，那就是面板或链路的真问题。

排查顺序我习惯这样走：先在浏览器里看渐变页，记下断层的位置；然后用系统自带的图片查看器打开一张标准渐变图对比；如果两边表现一致，说明是显示链路的问题，去显卡驱动里确认输出位深；如果浏览器更差，可能是浏览器的色彩管理在搞事。这套流程能帮你快速把"面板问题"和"配置问题"分开，避免白折腾一趟售后。

4.4 像素栅格与文字锐度：1:1 映射到底有没有做对

栅格页是一组 1 像素宽的黑白相间竖线（用repeating-linear-gradient实现），用途是验证分辨率映射是否正确。如果你的显示器是 2560×1440，但系统缩放设成了 150%，浏览器又做了非整数倍缩放，这组栅格就会出现明显的摩尔纹、粗细不均或者部分线条消失。

判断方法很直接：缩放调到 100%，栅格应该呈现均匀、清晰、无摩尔纹的细线；如果线条明显粗细不一，或者有几条直接糊成一片灰，说明像素没有做到 1:1 映射。这个测试对经常处理图像、写代码的人特别重要，因为非整数倍缩放会让文字边缘发虚，长时间看眼睛非常累。

顺手还能测文字锐度。我在页面里放了一行 12px、14px、16px 三档的中文小字，正常映射下小字应该笔画清晰、边缘锐利；如果发现字"发胖"或者有彩色边缘（这叫次像素渲染，RGB 排列的面板正常会有轻微彩边，但如果用的是 BGR 排列面板且系统按 RGB 渲染，彩边会特别明显），那就是面板排列和系统渲染不匹配。这个细节绝大多数人都不知道，但它确实存在，而且没法通过软件完全修复。

4.5 移动方块与刷新率：拖影和卡顿的粗略观察

拖影页是一个匀速横向移动的方块。如果面板响应时间不够（尤其是 VA 面板在暗部过渡时），方块后面会拖着一条灰影；如果刷新率或帧同步有问题，方块运动会"一跳一跳"的。这个方法精度很低，但胜在直观，而且能顺便验证一件事：屏幕是否真的运行在它标称的刷新率上。

简单的帧率测量可以这样写：

function measureFPS(duration = 2000) { return new Promise((resolve) => { let frames = 0; const start = performance.now(); function tick(now) { frames++; if (now - start < duration) { requestAnimationFrame(tick); } else { resolve((frames / (now - start)) * 1000); } } requestAnimationFrame(tick); }); }

注意这个数字只能作为参考，浏览器本身的合成开销、后台标签页限流、省电模式都会影响结果。我实测一台标称 144Hz 的显示器，用这个方法测出来 143.x，基本可用；但如果测出来是 60，先别急着判定显示器有问题，去系统显示设置里确认刷新率选项是不是被设成了 60Hz——这是最常见的"假故障"，我见过太多人抱怨新买的 165Hz 显示器"不丝滑"，最后发现是线材不支持，或者系统默认没切过去。

5. 一次完整的检测实操流程：从开箱到出结论

5.1 检测前的环境准备：这几步不做，测了也白测

第一，清洁屏幕。用超细纤维布干擦，别用纸巾、别用酒精湿巾（会伤镀膜）。这一步不做，你会把灰尘、指纹、水渍全当成坏点，白激动一场。我知道有个哥们儿因为一个"暗点"跟卖家吵了两小时，最后发现是屏幕上的一粒辣椒面，场面相当尴尬。

第二，调好亮度。SDR 内容我一般把显示器亮度调到日常使用水平（大概 30%~50%），别拉满也别调到最低。测漏光尤其要注意，高亮度下漏光会被整体亮度掩盖，低亮度下又会显得特别夸张，都不准，就用你平时看网页的那个亮度。手机端记得关闭自动亮度，否则你在黑屏页面待两秒，它就自己把亮度调下去了。

第三，关掉一切干扰。关夜间模式、关护眼模式、关 HDR（如果有）、关系统级的色彩滤镜、关任何"智能画质增强"。这些东西都会改变输出颜色，你看到的"偏色"可能是软件搞出来的。笔记本记得接电源，很多机器在电池模式下会主动降低屏幕亮度甚至刷新率。

第四，环境光。找一间光线不直射屏幕的房间，漏光测试最好在接近全黑的环境下做——不是因为暗环境下漏光"更真实"，而是因为环境光会让你的瞳孔收缩，降低对暗部细节的分辨能力。但要注意，全黑环境下人眼会过度敏感，一点点正常漏光都会被放大，所以最终判断还是要回到"日常使用环境"下再确认一次。

5.2 逐项执行的顺序与判定记录

我把流程固定成下面这个顺序，走一遍大概三到五分钟。顺序不是随便排的，它遵循"从最容易发现问题到最难判断"的原则，先用高对比度画面抓硬缺陷，再用低对比度画面看软问题。

记录方式建议很简单：把屏幕想象成 3×3 网格，发现问题就记"左上区、距左边约 8cm、距上边约 5cm，白色背景下可见黑点，黑色背景下不可见"。别写"右上角有个点"，这种描述在售后沟通里毫无说服力，因为"右上角"可以指任何位置。测量方式：用屏幕本身的像素数换算，或者干脆用尺子量一下到边框的距离，越具体越好。

5.3 取证与售后沟通：把"我觉得有问题"变成"有据可查"

发现缺陷后先别急着重启、别急着拆、别急着装系统，第一件事是取证。拍摄要点：把屏幕切到能最清楚显示缺陷的纯色（亮点用黑底，暗点用白底），相机开微距模式，尽量贴近但保持对焦，关闪光灯，用手动曝光把亮度压下来（自动曝光会把黑底拍成灰的，亮点就不明显了）。拍一张全景（证明位置）加一张特写（证明形态），再录一段从全屏到逐渐放大的视频，这套组合基本无懈可击。

沟通话术的关键是用词专业、描述具体、态度平和。我常用的模板大概是这样："我这边用纯色全屏做了逐色检查，白色背景下位于屏幕左侧偏上、距左边缘约 7cm、距上边缘约 4cm 处有一个常暗像素，黑色背景下该位置正常，判断为暗点；另外黑色背景下左下角有约 3cm² 的漏光。想问下这种情况按贵方的售后政策怎么处理？"——这段话里，"逐色检查""常暗像素""按政策怎么处理"三个点分别传递了"我懂行""我有依据""我不想吵架"，成功率会比"你这屏幕有坏点我要退货"高得多。

还有个实操技巧：七天无理由优先于质量问题认定。质量问题认定往往要走检测、要等判定标准、要扯数量，而七天无理由只看"商品完好"。如果不是特别在意那点运费，发现问题直接走无理由退货，是最省时间的选择。

6. 常见问题与排查实录：那些让人抓狂的瞬间

6.1 这到底是不是坏点：三分钟排除法

拿到一个可疑点，先做这三步。第一，擦。超细纤维布轻轻擦一下，会动的就是灰尘或污渍，别怀疑。第二，放大看形态。真正的坏点边界非常规整，通常是标准的方形或十字形，尺寸和单个像素（或子像素）一致；而灰尘、气泡、面板内部的异物边界不规则，尺寸也忽大忽小。第三，换背景看行为。这是最能定性的一步——纯黑下亮、纯白下不亮的，是亮点；纯白下黑、纯黑下看不见的，是暗点；只在某一个颜色背景下异常或消失的，是子像素缺陷；所有背景下都存在但亮度不变的，很可能是面板内部的异物或划痕，不属于像素缺陷。

还有一种特别容易被误判的情况：渲染残留。某些软件（尤其是老版本的图形工具、游戏、部分远程桌面客户端）会在屏幕上留下静态残影，看起来就像一大片坏点。判断方法是把页面切走、打开一个纯黑窗口覆盖上去，如果异常消失了，那就是软件问题，和屏幕无关。我遇到过一次，用户截图发过来"屏幕右下角一片花屏"，结果是他游戏客户端的准星残留，虚惊一场。

6.2 移动端的全屏坑：地址栏、刘海、手势条

移动端做这类工具有三个绕不开的麻烦。地址栏占位——用100vh会导致页面高度大于可视区域，底部被裁掉一截，正确做法是用100dvh或者用window.innerHeight动态计算。刘海和挖孔——需要viewport-fit=cover配合env(safe-area-inset-*)，让内容延伸到异形区下面，否则挖孔周围那一圈永远检测不到。手势条和虚拟按键——安卓的底部手势条、iOS 的 Home 指示条会覆盖屏幕最底部十几个像素，这块区域实际上没法用纯色覆盖。

我的处理是把底部约 20px 的区域单独标注一下，提示用户"底部条状区域受人机交互栏遮挡，如需检测请临时隐藏手势条"。这个细节虽小，但确实有人拿着底部一道亮线的手机来找我，结果那是手势条的白色指示器。

6.3 视觉误差：你的眼睛比你想的更容易被骗

同时对比效应：同一块灰，放在白底上看着更暗，放在黑底上看着更亮。所以判断均匀性时绝对不能盯着看，要眯眼、要退远、要来回扫视。马赫带效应：两个相邻的明暗区域边界处，人眼会自动"增强"对比，让你觉得边界特别明显，实际上过渡是平滑的。残像效应：长时间盯着一个高对比图案（比如栅格页），移开视线后会看到反色的残影，这不是屏幕问题，是你视网膜的问题，几十秒就消失了。

还有一类误差来自屏幕本身的"扶正"算法。不少高端显示器内置了均匀性补偿，出厂时对每个分区做了亮度校准，这在正常使用下是优点，但在检测时会让你觉得"特别均匀"——这不算作弊，但你要知道它的存在，别因为同一型号别人测出来不均匀、你测出来很匀就怀疑别人在瞎说。

6.4 常见问题速查表

6.5 几条只有踩过才懂的经验

别在验机前装系统、装驱动、改分辨率。很多人拿到新机器第一件事就是装系统调设置，结果一通操作猛如虎，真出了问题已经过了七天，而且多了"是不是你自己设置搞坏的"这个争点。正确顺序是先开箱验屏，再做别的。

别只用一张纯色图验屏。我见过有人拿一张白色 jpg 当检测图，图本身带压缩噪点和渐变，屏幕上的小暗点完全被淹没。必须用纯 CSS 填充的纯色，一个色值就是 255,255,255，没有任何压缩损失。

别在强光下判断漏光。白天靠窗测出来的"漏光"有九成是环境光反射。要判断漏光，拉窗帘、关灯，让环境光降到最低，再回到日常亮度看一眼，记住"日常使用下能不能看出来"才是唯一的判断标准。

别忽略屏幕膜。新机出厂贴的膜、自己贴的钢化膜，都可能带气泡、带细微划痕、甚至带一层淡淡的雾面效果。膜上的气泡在纯色背景下就是一个标准的"圆点"，非常容易被当成坏点。验屏前要么撕膜，要么明确知道膜上有什么。

别相信"用软件修复坏点"。网上流传的快速闪烁色块"修复"坏点的方法，理论上对极少数"卡死"的子像素（液晶分子卡在某个位置）有一点点概率起作用，但对真正的坏点完全无效，而且长时间高频闪烁对眼睛不友好。我试过几次，成功率低到可以忽略，不建议浪费这个时间。

7. 我自己的几点使用体会

这个工具写完之后用得最多的其实不是我自己，是身边那些买二手设备的人。有个朋友收了一台二手笔记本，卖家说"屏幕完美无瑕疵"，他在我这页面上跑到纯白那张，右下角一个暗点清晰可见，直接拿着录屏去议价，砍下来三百块，工具的开发成本瞬间回本。还有个更典型的，有人一直抱怨自己的显示器"色彩不均匀、看着累"，测下来发现是面板右侧整体偏暗，属于均匀性问题，换了台新的之后症状消失——这种问题靠日常使用根本说不清，必须有一个标准化的画面来做对照。

我后来还顺手把页面加了几个小功能：用 URL 参数直接跳到指定页面（比如?p=white），方便做快捷方式；把当前页面的编号和名称显示在角落，两秒后自动隐藏，避免自己忘了当前在测哪一项；支持用鼠标滚轮切换页面，这样在触摸板笔记本上单手就能操作。这些都是很小但很实用的改动，属于典型"自己天天用才会想到"的需求。

如果你也想做一个类似的工具，我的建议是先把"检测顺序"和"判读标准"想清楚，代码反而是最简单的那部分。真正决定这个工具有没有价值的，是它能不能让一个完全不懂行的人，在五分钟内得出一个靠谱的、能拿去和卖家对话的结论。至于界面好不好看、动效炫不炫，在这件事上一点都不重要——屏幕全黑的时候，没人会记得你的渐变色卡。