企业官网建设流程全解析

最近连着处理了三个移动端视频播放器白边问题，三次的根因都不一样。一次是视频本身是 4:3，页面容器却是 16:9；一次是竖屏视频硬塞进了横屏的播放器；还有一次根本和视频比例没关系，是封面图加载前容器高度塌了。这三类问题在需求文档里往往都被写成同一句话：播放器不能出现白边。但如果只对着这句话改样式，第二天线上就会被打回。这篇就把移动端视频播放器白边问题从头到尾梳理一遍：先判断白边从哪来，再选适配策略，最后给一套可以复制到原生端、H5 和 Canvas 的坐标计算方案。适合正在做音视频 SDK、信息流播放器或者自定义播放页的同学参考。

1. 先别急着改代码：白边到底是怎么来的

1.1 视频尺寸与容器尺寸的“错位”

所有白边问题的起点，都是同一个矛盾：视频的宽高比和播放器容器的宽高比不一致。

举个最直白的例子，容器是 16:9 的横向画框，视频却是 9:16 的竖屏内容。你想让整个视频画面都显示出来，播放器就只能把视频整体缩小，直到视频的宽度等于容器宽度。可这样一来，视频高度远远不到容器高度，上下必然空出来两块。这两块区域本身没有视频内容，背景色是白色，就成了用户嘴里的白边。

反过来也一样：横屏视频放进竖屏容器，为了“完整显示”，播放器会按高度适配，左右两边就会空出来。用户不关心这是不是播放器默认的“等比缩放”行为，他们只看到一圈白边，然后就会提一个“播放器有bug”的工单。

所以要记住第一个结论：只要容器比例和视频比例不相等，又要求视频完整可见，白边就不可能通过“修正代码”彻底消失，你只能在“留白”和“裁剪”之间做选择。

1.2 白边不是只有一个方向：先分清形态再动手

白边出现的位置，直接暴露了视频和容器谁更“宽”谁更“高”。我一般先截一张真机图，肉眼判断一下：

再补充一个容易忽略的细节：白边不一定是纯白的。如果播放器容器的背景色是黑色，用户会叫它“黑边”；如果容器背景是产品定义的浅色，用户看到的就是“白边”。本质上都属于未填充区域，解决方案完全一样，只是视觉表现不同。因此排查时不要只看颜色，要看“播放器画面四周有没有和视频无关的空白区域”。

2. 适配之前，先选好策略：全屏、嵌入式与封面图是三条线

2.1 全屏播放：让画面填满，还是让画面完整？

全屏播放时，很多产品经理会直接说“全屏当然要铺满屏幕”。但这里有一个隐藏约束：全屏的屏幕比例是固定的，视频比例是千奇百怪的。

如果视频是 16:9，屏幕也是 16:9，没有任何问题。可一旦视频是 9:16 或者 1:1，你再要求“铺满不裁切”，数学上就不成立。这时候需要先和业务确认一个核心取舍：

• 画面完整优先：视频等比缩放后完整显示，四周允许留黑/白边。
• 画面填满优先：视频按屏幕比例裁剪，牺牲部分画面内容，达到无白边效果。

我们团队在做一个短视频播放页时，产品明确要求“不能有白边”，最后采用的是 cover 方案：视频统一按容器比例裁剪填满。为了避免把人物头部或字幕裁掉，还约定所有上传内容必须把主体放在画面中央区域。这个约定很重要，否则播放器是没白边了，但人像被切掉一半，用户投诉更猛。

2.2 嵌入式列表/宫格：容器尺寸由业务定，视频去适应它

信息流里的视频播放器，容器尺寸往往不是视频比例决定的，而是排版决定的。比如首页宫格固定 1:1，横滑卡片固定 16:9。这种情况下，容器已经定死了，能变的只有视频的显示方式。

我的建议是：嵌入式场景默认用 cover。原因很简单，列表页的视频本来就是一个“入口”，用户不会盯着看完整内容，用裁剪换整齐的排版是划算的。代码上也不复杂，用 CSS 的object-fit: cover或者对应原生播放器的填充模式就能实现。

但这里要补一个经验：不要让视频元素的宽高去适配某一个视频的宽高。很多同学拿到视频宽高后，直接给容器也设成同样的宽高比，结果列表页里有的卡片高、有的卡片矮，非常乱。正确做法是容器保持统一，视频元素在容器内部自适应，容器外面加overflow: hidden。

2.3 封面图和首帧：别把白边从“加载前”带到“播放后”

白边问题不只在播放中，加载前也可能出现。

有些播放器在视频未加载时显示封面图，封面图是一张图片，图片本身也有自己的宽高比。如果封面图和视频画面的宽高比不一致，就会出现一个很尴尬的现象：加载前看着封面图没白边，点击播放后画面突然闪一下，变成有白边。或者反过来，封面图有白边，视频正常播放后反而没有。

处理原则很简单：封面图、视频、容器三者使用同一个适配策略。容器是 1:1，封面图和视频都用 cover，那播放前后视觉上就是连贯的。不要给封面图单独写一套自适应逻辑，那是在给自己埋坑。

2.4 裁剪显示与“内容安全区”的取舍

选择 cover 并不意味着可以随便裁。移动端视频经常带字幕、弹幕、人物头部、产品 logo，这些内容都有明确的“安全区”。

比如竖屏视频转成横屏封面，cover 会把上下部分裁掉。如果视频底部有字幕，字幕很容易被裁掉一半。这时候可以调整裁剪锚点，用类似object-position: center bottom或自定义 source 区域的方式，把视频的底部内容保留住。反过来如果是顶部有固定标题，就锚定到顶部。

这个思路不仅适用于播放器，也适用于视频封面生成、短视频转场、直播卡片预览。凡是“固定容器 + 任意比例视频”的场景，都需要在适配函数里暴露一个可调的锚点参数，而不是写死居中。

3. 核心实现：一个“去白边”的适配计算器

3.1 第一步：拿到媒体真实宽高，远离“假数据”

不管用什么方案，第一步都是拿到视频的原始宽高。很多白边问题是因为布局时用了容器宽高，或者用了播放器视图的当前宽高，而不是视频的原始宽高。

以 H5 为例，要等loadedmetadata事件触发后再读取videoWidth和videoHeight：

const video = document.getElementById('player'); video.addEventListener('loadedmetadata', () => { const vw = video.videoWidth; const vh = video.videoHeight; if (vw > 0 && vh > 0) { applyAdaptiveLayout(vw, vh); } }, { once: true });

这里有一个坑：在loadedmetadata没触发之前，videoWidth和videoHeight很可能都是 0。如果页面初始化时就拿这两个值去算容器高度，算出来就是 0 或者不合理的比例，白边/黑边自然就出来了。

另外还要注意视频文件里可能携带“旋转元数据”。有些手机拍摄的竖屏视频，内部存储的宽高可能是横屏的，靠旋转标记来正常显示。如果不做处理，拿原始宽高直接算，适配结果会和用户看到的画面方向不一致。遇到这类视频，可以在拿到 metadata 后先确认播放器是否已经自动应用旋转，再决定是否互换宽高值。

3.2 第二步：contain 模式下的精确居中与补边计算

contain 模式的目标是“视频完整可见”，对应的数学操作是：取一个缩放比例，让视频缩放到能放进容器的最大尺寸。

function adaptRect(containerW, containerH, mediaW, mediaH, fit = 'cover') { const scale = fit === 'cover' ? Math.max(containerW / mediaW, containerH / mediaH) : Math.min(containerW / mediaW, containerH / mediaH); if (fit === 'contain') { const drawW = mediaW * scale; const drawH = mediaH * scale; return { fit, sourceX: 0, sourceY: 0, sourceW: mediaW, sourceH: mediaH, drawX: (containerW - drawW) / 2, drawY: (containerH - drawH) / 2, drawW, drawH, }; } // cover 模式下，计算需要从原始视频中裁剪的源区域 const sourceW = containerW / scale; const sourceH = containerH / scale; return { fit, sourceX: (mediaW - sourceW) / 2, sourceY: (mediaH - sourceH) / 2, sourceW, sourceH, drawX: 0, drawY: 0, drawW: containerW, drawH: containerH, }; }

contain 的公式用Math.min，意思是“取较小的缩放比例”，保证视频的宽和高都能落进容器。计算出的drawW和drawH是视频实际绘制出来的尺寸，drawX和drawY是视频在容器中的偏移量。

举个例子：容器是 1080x1920，视频是 1920x1080。scale = Math.min(1080/1920, 1920/1080) = 0.5625，视频绘制出来就是 1080x607.5，垂直方向居中后，上下各有约 656 像素的空白。这不是计算错了，而是 contain 模式本来就允许留白。

如果你用的播放器是系统自带的，你不需要手写这个函数，只要设置“等比缩放”模式即可。但如果后续要做 Canvas 自定义渲染、裁剪封面、或者实现复杂的画中画布局，这套坐标计算就必须吃透。

3.3 第三步：cover 模式下的裁剪坐标计算

cover 模式的目标是“铺满容器且不留白”，代价是裁剪掉视频的一部分。

同样用上面的例子，容器 1080x1920，视频 1920x1080。scale = Math.max(1080/1920, 1920/1080) = 1.7778。视频放大到 3413x1920，这样高度刚好覆盖容器，但宽度远超容器。于是我们需要从视频原始画面中截取一个横向区域：

• 源区域宽度 = 容器宽度 / scale = 1080 / 1.7778 = 607.5
• 源区域高度 = 容器高度 / scale = 1920 / 1.7778 = 1080
• 源区域 x 起点 = (1920 - 607.5) / 2 = 656.25
• 源区域 y 起点 = (1080 - 1080) / 2 = 0

也就是说，横屏视频放进竖屏容器后，cover 模式会保留画面中间的 607.5 像素宽度，这个宽度在原视频里只占约三分之一。如果关键信息不在中间，就必须调整sourceX，而不是继续用居中锚点。

这一步非常关键，因为很多同学以为 cover 就是“等比放大然后裁剪”，但并不知道具体裁哪里。裁哪里，完全由sourceX和sourceY决定。在 H5 里，可以用object-position控制裁切锚点；在原生端和 Canvas 里，就用这个坐标计算函数手动控制。

3.4 第四步：兼容设备像素比、圆角与安全区

计算函数只是第一步，落地时还有三个容易忽略的细节。

第一，Canvas 渲染要处理设备像素比。很多自定义播放器把视频画到 Canvas，如果 canvas 的宽高直接用 CSS 像素，高分屏下画面会发虚。正确做法是：

const dpr = window.devicePixelRatio || 1; canvas.width = cssWidth * dpr; canvas.height = cssHeight * dpr; canvas.style.width = cssWidth + 'px'; canvas.style.height = cssHeight + 'px'; ctx.setTransform(dpr, 0, 0, dpr, 0, 0);

绘制时再调用ctx.drawImage(video, sourceX, sourceY, sourceW, sourceH, drawX, drawY, drawW, drawH)，这样既能裁剪，又能保证清晰度。

第二，圆角容器要配合overflow: hidden。如果播放器卡片本身有圆角，但视频绘制/渲染时没有裁剪到圆角范围内，视频的直角会盖在圆角上，视觉上就像出现了额外的白色或异形边。H5 里直接把border-radius和overflow: hidden放在同一个容器上即可，原生端则要对播放器视图的 layer 做圆角 mask。

第三，全屏播放要留意手机安全区。有些真机在全面屏模式下，播放器视图高度没有包含顶部和底部安全区，用户看到的是一条和背景色一致的细边。这种情况和视频比例无关，需要单独处理安全区高度，否则无论如何调 cover 参数都消不掉。

4. 实战避坑：我踩过的几个白边相关坑

4.1 首帧闪白/闪黑：metadata 加载时机没控制好

我遇到过最隐蔽的白边问题，是播放器已经正常铺满屏幕，但视频加载的一瞬间会闪一下白边。

排查后发现，布局代码在 DOM 渲染后立刻执行，此时视频 metadata 还没加载完，videoWidth是 0，代码按默认的 16:9 去做布局。等视频真正加载完，宽高比变了，布局却没有重新计算。于是页面先按错误比例显示，再在某个时刻被系统播放器重新纠正，视觉上就闪了一下。

解决方案是在loadedmetadata、resize、进入全屏、退出全屏这四个时机都重新调用适配函数。不要只在初始化时执行一次，移动端环境变化太多了。

4.2 旋转屏幕/横竖屏切换后白边“复活”

移动端播放器最常见的问题是：竖屏启动正常，横屏全屏也正常，但从横屏退回竖屏的一瞬间，白边出现了。

原因大多是旋转后容器尺寸变了，但适配函数没有重新执行。浏览器或原生 WebView 在旋转时会触发resize，但触发时机可能比布局更新早，此时读取容器宽高会拿到旧值。稳妥做法是在resize回调里加一个短延迟，或者用requestAnimationFrame重新读取布局参数：

window.addEventListener('resize', () => { requestAnimationFrame(() => { const rect = container.getBoundingClientRect(); applyAdaptiveLayout(rect.width, rect.height); }); });

如果播放器用到了原生全屏 API，退出全屏后也要主动调用一次适配。

4.3 视频文件自带黑边：播放器“无辜”但用户不认

还有一类问题不在播放器适配层面，而是视频源本身就有黑边。比如某些录屏视频上下自带黑边，某些老电影左右自带黑边，某些摄像机拍的视频没做裁剪就上传了。

这类视频在播放器里无论怎么 contain 或 cover，都会显示源视频内置的黑边。我的排查方法是：把视频某一帧截图，用工具看画面四周是否有明显的纯色区域。如果有，就要在服务端统一做裁剪，或者在播放器端用 cover 把源视频的空白区域裁掉。这里不建议用“放大一点再居中”这种粗暴方案，最好还是根据实际内容的宽高比重新计算源裁剪区域。

4.4 背景色与内容边缘重叠：看起来像白边，其实是误判

最后一个小坑：视频画面本身是浅色，比如白色背景的教学视频、白底产品演示，用户可能会把视频内容和容器边缘之间的微小间隙误认为白边。

这种问题往往不是适配错误，而是容器边框、阴影、或相邻元素间距造成的视觉误差。处理方式不是调适配，而是检查播放器容器是否设置了边框、内边距或相邻元素的间距。曾经有一个项目，播放器本身完美铺满，但容器的父级多了一个padding: 1px，真机上看起来就像有一条极细的白线，排查了很久才发现。

5. 不同技术栈的落地方案速查

5.1 H5/WebView：一条 CSS 规则解决大部分白边

如果你的播放器是 H5 页面里的<video>或<img>，大部分白边问题都可以用object-fit解决：

.player { width: 100%; height: 100%; position: relative; overflow: hidden; background: #000; } .player video, .player img { width: 100%; height: 100%; object-fit: cover; object-position: center; }

object-fit: cover等价于上文代码中的 cover 模式，object-fit: contain则保留完整画面并留白。如果容器不想固定，还可以用aspect-ratio配合 metadata 动态设置容器比例：

.player { aspect-ratio: 16 / 9; }

但要注意，aspect-ratio解决的是“容器不知道该多高”的问题，解决不了“视频比例和容器比例不一致”的问题。两者不能混为一谈。

5.2 原生端播放器的缩放模式

原生端虽然没有 CSS，但思路一样，只是 API 名称换了。

iOS 端播放器有一个视频重力参数，通常有“等比缩放完整显示”和“等比缩放裁剪填满”两种模式。Android 端的 VideoView、TextureView 也有对应的缩放类型。如果不想手写坐标，直接设置这些模式就能解决大部分白边问题。

用模式虽然方便，但它只能固定锚点居中裁剪。一旦遇到“竖屏视频转横屏但要保留顶部标题”这类需求，模式就不够用了，最终还是需要回到计算函数，自己设置源裁剪区域。

5.3 Canvas 自定义渲染：最可控也最需要算准坐标

用 Canvas 做自定义播放器渲染时，上面的adaptRect函数直接可用。拿到返回值后，通过drawImage把源视频的指定区域绘制到画布上：

const rect = adaptRect(canvasCssW, canvasCssH, videoWidth, videoHeight, 'cover'); ctx.drawImage( video, rect.sourceX, rect.sourceY, rect.sourceW, rect.sourceH, rect.drawX, rect.drawY, rect.drawW, rect.drawH );

Canvas 方案适合做复杂的转场、画中画、多视频拼接，但调试成本也最高。我建议在开发阶段把视频源区域画一个半透明边框，方便观察裁剪范围，确认无误后再去掉。

5.4 跨平台开发框架的思路迁移

很多跨平台 UI 框架里也有类似 cover/contain 的布局属性，命名可能不同，但底层逻辑一致。做跨平台适配时，我通常把adaptRect这个纯函数直接复制过去，然后只改绘制层的 API 调用。纯函数不依赖任何平台，输入容器宽高和媒体宽高，输出坐标，天然适合复用。

6. 上线前自查清单：五个检查动作帮我拦下 80% 的白边

6.1 用“极端比例视频”做回归

不要只拿产品准备好的 16:9 视频测试。我的测试素材库里固定放几段极端比例视频：1:1 方形、9:16 竖屏、4:3 老视频、21:9 宽屏。每一段都分别在竖屏容器和横屏容器中播放，才能确认适配函数不会在边缘比例下出错。

6.2 真机旋转 + 进出全屏 + 弱网重试

浏览器模拟器很难复现旋转时序问题，所以我习惯用真机做三连操作：播放中旋转、播放中进出全屏、弱网下连续切换清晰度。每一个操作后都看一眼画面四周有没有白边。这三类操作覆盖了大部分动态布局变更场景。

6.3 封面图和首帧画面并排检查

我会把封面图和视频首帧截图放到同一个容器里并排比较，确认两者的裁切比例和锚点一致。不一致就说明封面图的适配逻辑和播放器脱节了，需要统一。

6.4 检查背景色与播放器容器边框

最后再盯一眼播放器容器的父级元素。很多时候白边不是视频适配问题，而是容器背景色、padding、border 造成的视觉缝隙。设置背景色时，最好把播放器容器的背景色和视频画面默认填充区域区分开，避免用户把两者混为一谈。

我个人在实际操作中还有一个习惯：不管需求文档怎么强调“不能有白边”，我都会把“完整显示”和“填满裁剪”的取舍写清楚再动手。很多白边问题根本不在技术，而在产品预期没对齐。你把这层逻辑讲透了，后面写代码反而快很多。