企业官网建设流程全解析

做WebGL开发，十有八九会在高清屏上栽跟头：画面糊成一片、边缘锯齿明显、文字像蒙了一层雾，更诡异的是明明啥都没改，换台电脑画质就变了。今天这篇就用零基础的视角，把高清屏适配这件事彻底讲透，从底层原理到可以直接抄的代码再到排查技巧，一次补齐。

1. 高清屏适配到底在解决什么问题

1.1 模糊和锯齿的根源

先想一个问题：同一个WebGL页面，在普通屏幕上显示挺正常，换到高分屏上就发虚，这是为什么？很多人第一反应是“图像被放大了”，但这个说法不准确，更接近真相的说法是“图像没有生成足够多的像素点”。

普通屏幕上一个CSS像素基本对应一个物理像素，而高清屏（比如dpr为2的设备）一个CSS像素对应2乘2共4个物理像素。假如我们的Canvas画布在CSS里设置了800像素宽，但绘制缓冲区的宽度只设了800，那在这块高清屏上，浏览器就要把这800个像素点的画面拉伸到1600个物理像素点上去显示。拉伸的过程没有新增信息，只能靠插值估算颜色，画面自然就糊了。

可以做个生活化类比：一张邮票大小的照片，你硬要打印成海报尺寸，结果就是满屏马赛克。WebGL的Canvas也是如此——它生成的是一张位图，这张位图最终要被浏览器缩放显示在屏幕上，源图分辨率不够，再怎么缩放都救不回清晰度。

很多人以为“高清屏适配”只是让画面变清晰，其实漏了一个隐藏问题：如果你不做适配，同样的代码在不同dpr的设备上，视觉大小也不一致。因为WebGL的默认坐标系是归一化的，左右范围是-1到1，它映射的其实是整个绘制缓冲区。缓冲区像素少，绘制结果占据的物理区域就小，再经过拉伸，画面尺寸飘忽不定。所以适配的本质，是解决“清晰度”和“尺寸一致性”两件事。

1.2 两套尺寸的博弈

搞懂适配，必须分清Canvas身上两套完全不同的尺寸：

• 绘图缓冲区尺寸：对应canvas元素的width和height属性，单位是物理像素，决定了WebGL实际渲染的分辨率。
• CSS显示尺寸：对应canvas元素的style宽度和高度，或者说它被布局到页面后占的格子大小，单位是CSS像素。

这两套尺寸平时可以不一样。浏览器显示canvas时，会把缓冲区内容拉伸或者缩小到CSS尺寸对应的区域。很多新手写Canvas只设了CSS尺寸，忘了设width和height，结果buffer一直保持默认的300乘150，画面当然又小又糊。

高清屏适配的核心思路，就是把这两套尺寸的比例拉开：缓冲区尺寸 = CSS尺寸 × devicePixelRatio。这样缓冲区生成的物理像素数量正好覆盖屏幕的物理像素，浏览器显示时是一比一映射，没有缩放，清晰度自然拉满。

2. 适配方案的核心思路：让缓冲区和物理像素对齐

2.1 devicePixelRatio就是那个关键数字

window.devicePixelRatio（简称dpr）表示一个CSS像素等于几个物理像素。dpr为1是普通屏，dpr为2或3是常见的高分屏。它不是固定值，用户可以缩放浏览器窗口、调整系统缩放比例，甚至拖动窗口到不同分辨率的显示器上，它都会变化。

所以适配不能只在页面加载时算一次，随时可能变。我的经验是：把dpr当作动态变量处理，而不是常量。每次渲染前都读一次最新的window.devicePixelRatio，这样跨显示器拖动窗口时也能自动适应。

这里有个细节：读取dpr后要取整并做上限截断。比如某台设备的dpr是2.5，这种非整数倍的值在高分屏上很常见。取整建议用Math.floor而不是Math.round，保证缓冲区尺寸不超过物理像素上限，避免非整数倍缩放造成的额外模糊。

2.2 核心公式与适配策略

适配逻辑可以浓缩成一句话：让canvas的width和height等于它CSS尺寸乘以dpr后的物理像素值，同时让gl.viewport覆盖整个缓冲区。

要取CSS尺寸，我推荐用canvas.clientWidth和canvas.clientHeight，而不是去读style.width或getBoundingClientRect。clientWidth返回的是元素实际布局后的CSS像素宽度，不受CSS变形、边框等干扰，而且它是整数，省去不少取整的心智负担。注意clientWidth包含padding但不包含边框，如果canvas外面套了一层有边框的容器，需要减去边框宽度，或者干脆用getBoundingClientRect().width再取整。

再看viewport。WebGL的viewport决定了渲染结果写到缓冲区的哪个区域，默认是(0, 0, canvas.width, canvas.height)，这看起来好像不用管。但如果你改了缓冲区尺寸后没显式调用gl.viewport，部分浏览器在某些时序下会用旧尺寸，导致画面只渲染在左上角一小块区域。所以每次resize之后，必须重新调用gl.viewport(0, 0, 新物理宽, 新物理高)，这是适配里最容易漏的一步。

3. 手写一个完整的适配模块（可直接抄）

3.1 初始化阶段的适配代码

直接上一份我在实际项目里用的最小实现，配合注释解释关键点。

function initWebGL(canvas) { const gl = canvas.getContext('webgl', { antialias: true }); if (!gl) { throw new Error('浏览器不支持WebGL'); } // 适配函数：让缓冲区尺寸跟随CSS尺寸和dpr变化 function resize() { // 1. 读取当前dpr，并做上限截断，避免过高分辨率拖垮性能 const dpr = Math.min(window.devicePixelRatio || 1, 2); // 2. 读取canvas的CSS布局尺寸（单位是CSS像素） const cssWidth = canvas.clientWidth; const cssHeight = canvas.clientHeight; // 3. 计算物理像素尺寸，并向下取整 const pixelWidth = Math.floor(cssWidth * dpr); const pixelHeight = Math.floor(cssHeight * dpr); // 4. 只有尺寸真的变化时才重新赋值，避免每帧重置上下文状态 if (canvas.width !== pixelWidth || canvas.height !== pixelHeight) { canvas.width = pixelWidth; canvas.height = pixelHeight; } // 5. 同步viewport到整个缓冲区 gl.viewport(0, 0, pixelWidth, pixelHeight); } resize(); window.addEventListener('resize', resize); return { gl, resize }; }

这里有一个非常关键的细节：为什么先比较再赋值？因为给canvas.width赋值会引发一连串副作用，包括清空画布、重置WebGL状态。如果每帧都无条件赋值，即使值没变，有些浏览器也会重新初始化上下文，导致shader、buffer全部丢失，画面直接黑掉或者报错。先比较再赋值，是防止这个坑的最简单手段。

3.2 运行时窗口变化的监听与处理

上面的代码用window.addEventListener('resize', resize)监听窗口变化，这能应付大多数场景。但在项目实战中，还有几种情况需要单独处理。

第一，F11全屏或者浏览器视图大小变化时，window的resize事件会触发，但如果canvas本身是被某个动态布局的容器包裹，容器尺寸变化不一定触发window的resize。这种情况建议用ResizeObserver监听canvas自身尺寸变化，或者监听它父容器。

const observer = new ResizeObserver(() => { resize(); }); observer.observe(canvas);

注意ResizeObserver在某些老浏览器不支持，现代浏览器基本没问题。如果跑的是老环境，退回到window的resize事件加一个防抖节流就够了。我的习惯是两套都挂：ResizeObserver监听元素级变化，window的resize事件兜底。

第二，初始化时机很重要。代码里的resize()依赖canvas.clientWidth，而这个值需要canvas已经插入DOM且布局完成才能正确读取。如果你在脚本早期就调用initWebGL，canvas还没布局，clientWidth会是0，缓冲区尺寸就变成0乘0。稳妥做法是把初始化放在DOMContentLoaded之后，或者确认canvas已挂载再执行。

第三，如果canvas是做成全屏背景的，CSS要保证它占满视口且没有margin和padding，否则clientWidth比窗口小一圈，画面周围的留白和拉伸会很诡异。全屏场景下可以直接用window.innerWidth和window.innerHeight作为CSS尺寸，但要注意window.innerWidth包含滚动条宽度，如果页面禁用了滚动，这是最省事的取值方式。

3.3 参数为什么这么选：坐标计算与性能取舍

完成适配后，很多人在下一步就踩坑了：坐标体系怎么算？假设你的业务里需要画一个CSS像素大小为100乘100的正方形，如果用归一化坐标，需要自己计算它在缓冲区里占多少像素。而如果使用了正交投影矩阵，很多人会直接这样设置：

const projection = mat4.create(); mat4.ortho(projection, 0, canvas.width, canvas.height, 0, -1, 1);

这样写本身没错，但canvas.width是物理像素，dpr为2时你的“100乘100正方形”会画成200物理像素宽，物理尺寸变成两倍大。为了保证逻辑尺寸在不同dpr下保持一致，应该用CSS像素作为逻辑单位：

const projection = mat4.create(); mat4.ortho(projection, 0, canvas.width / dpr, canvas.height / dpr, 0, -1, 1);

这样在dpr为1和dpr为2的设备上，逻辑坐标范围都是CSS像素的区域，画出来的东西物理尺寸一致，不会出现“一台电脑大、一台电脑小”的问题。

这也是适配里最容易忽视的第三层：缓冲区尺寸适配了，viewport适配了，投影矩阵里的坐标单位没适配，照样出乱子。我把这三层归纳成一个检查顺序，写代码时按这个顺序排查，基本不会漏：

• 第一层：缓冲区尺寸 = CSS像素 × dpr
• 第二层：viewport = 缓冲区尺寸
• 第三层：逻辑坐标系 = 以CSS像素为单位的投影

性能取舍上也说一句。dpr到3甚至更高的设备已经不罕见，缓冲区尺寸是CSS尺寸乘dpr再平方，像素总量增长是平方级的。一个1920乘1080的CSS画布，在dpr为3的设备上缓冲区是5760乘3240，像素数接近1900万，这个量级对GPU和内存都是压力。我在代码里用Math.min限制dpr最大为2，这是一个平衡方案：画质损失肉眼几乎看不出来，性能却能省一大截。如果你的场景是数据可视化、文字线条这类对清晰度敏感的内容，可以把上限放宽到2.5或者3，但记得用帧率统计验证，别盲目拉满。

4. 常见问题排查与避坑技巧

4.1 模糊、虚边、锯齿，分别该调哪里

很多人把模糊和锯齿混为一谈，调了半天发现没效果，其实这是两个完全不同的症状。

模糊的典型表现：整体画面发虚、边缘柔和、文字看不清。根源基本是缓冲区尺寸小于物理像素，也就是没乘dpr或者dpr取错了。排查方法是在代码里打印canvas.width、canvas.clientWidth和window.devicePixelRatio，用“canvas.width = clientWidth × dpr”这个公式去验证。我见过一个正好反过来踩坑的案例：某开发者把canvas.width固定成1920，在普通屏上没事，在dpr为2的高分屏上反而过采样了，显示出来要缩小一半，性能白白浪费。

锯齿的典型表现：斜线边缘有明显的阶梯状折线，尤其是几何图形的轮廓。适配做对了，这种锯齿依然可能存在。原因是WebGL默认光栅化就是对像素做二值判断，没有抗锯齿。解决手段有几种：创建上下文时开启antialias选项（就是代码里的{ antialias: true }）、使用MSAA，或者在后处理阶段做FXAA/TAA。注意antialias在部分移动端浏览器上会被忽略，不能完全依赖它。

虚边则是另一个故事。它通常出现在纹理采样或者半透明物体边缘，表现为物体轮廓外面有一圈灰白或者半透明的光晕。这是纹理过滤方式和使用线性采样时边缘像素权重分配导致的，和屏幕适配关系不大，但在高分屏上更容易被看出来。排查思路是重新检查纹理的minification filter和mipmap设置，必要时对纹理边缘做clamp到边缘处理。

4.2 resize循环抖动的排查

我见过最迷惑的bug：窗口resize之后，画面在正常和破损之间反复横跳，或者一直闪。这种情况十有八九是resize触发链形成了死循环。

典型链路是这样的：window的resize事件里调用了resize函数，resize函数里改了canvas的width和height，而canvas尺寸变化又触发了ResizeObserver的回调，回调里又调用了resize函数，于是无限循环。值没变的时候靠“先比较再赋值”能挡掉一部分，但如果绘画逻辑里还有根据canvas尺寸动态改CSS样式的操作，循环就会重新建立。

我建议的解决办法：

• 用requestAnimationFrame包裹resize逻辑，把多次触发合并到同一帧执行。
• 在ResizeObserver的回调里判断尺寸是否真的变化，没变化直接return。
• 不要在resize函数里做任何会影响布局的操作，比如改style.width、style.height。

还有一个经典坑：某些浏览器在窗口resize期间会连续触发大量事件，如果每帧都重新编译shader或者重建buffer，页面会卡成幻灯片。把shader编译、buffer上传都移到初始化阶段，resize阶段只更新viewport和投影矩阵，性能会好很多。

4.3 性能不够时的降级方案

适配完成后在普通屏上流畅跑，换到高分屏上帧率一下掉一半，这是常见的性能瓶颈。原因前面说了：像素总量平方级上涨。这时候我不会直接砍适配，而是做动态降级。

方案一：降低dpr上限。把dpr从3降到2，像素总量从9倍降到4倍，体感帧率提升最明显。

方案二：动态检测帧率。维护一个滑动窗口的帧率统计，如果连续一段时间低于某个阈值，自动降低dpr，并支持在性能恢复时回升。这在高分屏设备上是实打实的体验优化。

方案三：降低后处理的渲染分辨率。如果场景里用了后期处理（Bloom、SSAO这类），可以只把后处理链路的内部分辨率降到50%，再在最后一步上采样到全分辨率。复杂效果开销大，但视觉清晰度损失很小。

降级的原则是“先保住交互流畅性，再谈极致画质”。渲染卡成PPT，画面再清晰也没意义。

5. 框架里的适配与后续进阶

5.1 常见框架中适配是怎么处理的

如果你用的是Three.js这类常见WebGL框架，很多适配工作已经被封装好了。以Three.js为例，初始化时调用renderer.setPixelRatio(window.devicePixelRatio)就能解决大部分问题，框架内部会帮你把canvas缓冲区尺寸调整到物理像素级别。

但这里有两个容易忽略的坑。

第一，setPixelRatio之后，如果你手贱又手动改了canvas.style.width，会把适配的底层逻辑打乱。Three.js内部是基于canvas的clientWidth乘pixelRatio来设置buffer尺寸的，外部改动style导致clientWidth变化，渲染结果会出现错位或模糊。

第二，窗口resize时，你需要手动调用renderer.setSize(cssWidth, cssHeight, false)。第三个参数false表示不修改canvas的CSS样式，只调整缓冲区和viewport。如果你传了true，框架会直接改style样式，适配体系同样会被破坏。

我自己写框架封装时，会做一个统一入口：

function resize(renderer, canvas, updateCamera) { const dpr = Math.min(window.devicePixelRatio || 1, 2); renderer.setPixelRatio(dpr); const w = canvas.clientWidth || 1; const h = canvas.clientHeight || 1; renderer.setSize(w, h, false); if (updateCamera) { updateCamera(w, h); } }

这里面把dpr、setPixelRatio、setSize全部收敛到一个函数里，避免各写各的互相打架。如果项目里还接了其他渲染库或者自绘UI，保持这个单一入口特别重要。

5.2 可以继续深挖的方向

高清屏适配在入门之后还能往好几个方向扩展，这里挑几个我实际用过的。

方向一：离屏渲染和离线截图。如果页面需要导出高清图片，不能直接用渲染canvas的当前buffer，因为它的尺寸受dpr限制，可能不够大。更优雅的方式是单独创建一个离屏canvas，将dpr设为导出需求比如2倍或3倍，重新渲染一帧再做导出。这里要注意离屏canvas的上下文同样要做viewport适配，逻辑和主canvas一模一样。

方向二：动态切换dpr。现在很多设备可以折叠、外接显示器，dpr会变。监听到dpr变化后，如果只是重新resize，shader里写死的像素尺寸逻辑可能还停留在旧值。建议把dpr也塞进uniform，让shader能感知到当前像素密度。

方向三：纹理采样与Canvas 2D的混用。有时你在WebGL里渲染一个Canvas 2D生成的纹理，2D Canvas默认不带dpr适配，画出来的纹理放到高分屏上会发虚。这种情况下要在Canvas 2D那边也乘上dpr，保证纹理源的物理分辨率足够。

还有一个想特别提一下的：调试适配问题时，最直接的手段是拿手机或者浏览器开发者工具模拟设备，然后截图放大看边缘像素，再把canvas.width打印出来对照。任何理论分析都不如肉眼直接确认像素排列来得快。我习惯在开发模式下做一个隐藏调试面板，实时显示当前dpr、buffer尺寸、CSS尺寸、viewport和帧率，这样客户报问题的时候，我能第一时间定位是适配问题还是别的环节。

最后再分享一个小技巧：给canvas外层的容器加CSS属性image-rendering: pixelated，可以在适配失效时让画面呈现出明显的锯齿而不是模糊。它的作用仅限于调试，生产环境千万别加。我用它来快速判断“当前页面到底有没有做高清适配”——如果画面巨糊，说明适配没生效或还没执行，锯齿则说明buffer尺寸已经对了但抗锯齿没开或者采样参数不对。这几行调试代码能帮你省下大量猜测时间。