企业官网建设流程全解析

上周改一版宣传物料，设计在群里甩了一句：“这张图按 8cm 宽出，给我像素值。”底下三个人回了三个数——227、302、945。谁都没算错，可谁也只对了一半。像素和厘米的换算就是这么个东西，它表面上是道除法题，实际上是一道“你打算把这 8cm 放在哪儿”的工程题。放在网页上、印在纸上、贴在手机屏幕上，答案能差出四倍。这篇就把8cm 等于多少像素这件事从头拆一遍：公式怎么来的、不同场景该套哪个密度、设计稿和前端怎么对齐、以及我自己在这些换算上栽过的几个跟头。看完你至少能做到两件事——别人报个厘米数你能立刻给出靠谱像素值，以及别人给你像素值你能反推它到底能不能用。

1. 8cm 到底是多少像素：先接受“没有唯一答案”

1.1 三个人给出三个数，其实都没毛病

先把结论摆出来：8cm 换算成像素，必须附带一个密度参数，否则这个换算不成立。密度就是常说的 DPI 或 PPI，前者多用于印刷，后者多用于屏幕，本质都是“每英寸塞多少个点”。

按最常用的几个密度算一遍，8cm 分别对应：

那张表里 227 是 72DPI 的答案，302 是 CSS 里8cm被浏览器解析出来的值，945 是按商业印刷 300DPI 算的。三个人各自站在自己的场景里说话，谁也没错，错的是没把场景说清楚。

我现在的习惯是，只要有人问“X 厘米是多少像素”，第一句先反问：这个是给屏幕看的，还是给打印机看的？这一句能省掉后面八成的返工。

1.2 像素是“点”，厘米是“长度”，中间缺的那一环叫密度

理解这件事的关键，是把两个概念分清楚。

像素是离散的计数单位，它没有物理尺寸。一个像素可以小到肉眼看不见，也可以大到像马赛克砖。它只回答“有多少个点”，不回答“有多大”。

厘米是连续的物理长度，它只回答“有多长”，不回答“由多少个点构成”。

要把这两者接上，必须引入第三个量：单位长度里塞多少个点，也就是密度。三者关系是一条很朴素的式子：

像素数 = 物理长度（英寸） × 密度（每英寸点数）

厘米要先换成英寸，因为密度的分母是英寸。1 英寸 = 2.54 厘米，这一步是所有换算的地基，记错这一个数，后面全盘皆输。

打个生活化的比方：像素像是地砖的块数，厘米像是房间的米数，密度就是“每米铺几块砖”。同一个 8 平米的房间，铺 30×30 的小砖和铺 80×80 的大砖，块数完全不同，但房间还是那个房间。你问“8 平米需要多少块砖”，不告诉我砖多大，我只能反问你。

1.3 为什么“改图片 DPI”不会让图变清晰

这是我在带新人的时候最常纠正的一个误解。很多人以为把一张图的 DPI 从 72 改成 300，图就变高清了。实际上一张图的总像素数是写死的，改 DPI 只改变了它在打印时默认铺开的物理尺寸。

举个具体例子：一张 1200×1200 像素的图，元数据标 72DPI 时，软件默认按 1200÷72 ≈ 16.7 英寸（约 42cm）宽来铺；你把 DPI 改成 300，软件就按 1200÷300 = 4 英寸（约 10cm）宽来铺。像素一个没多，只是“默认尺寸”缩水了，看起来变密了而已。

反过来说，一张手机拍的 4000×3000 照片，元数据里可能写着 72DPI，但这不代表它只能印 42cm 宽。你要印 8cm 宽，需要 8cm 对应的像素数，4000 像素远远够用，绰绰有余。判断一张图能不能用，看的是总像素数够不够，不是看元数据里那个 DPI 数字。

我自己的检查方法很土但很有效：拿到图先看像素尺寸，用成品尺寸反算密度。8cm 宽、945 像素的图，密度就是 945 ÷ (8÷2.54) ≈ 300DPI，合格；如果只有 400 像素，那密度才 127DPI，印出来会发虚。

2. 把公式拆开：手算 8cm 的完整推导路径

2.1 从 1 英寸 = 2.54 厘米推出通用式子

推导过程没什么玄机，两步走：

第一步，把厘米换成英寸：

英寸 = 厘米 ÷ 2.54 8cm ÷ 2.54 = 3.1496 英寸

第二步，英寸乘以密度得到像素：

像素 = 英寸 × DPI 3.1496 × 300 = 944.88

合并成一个式子就是：

像素 = 厘米 ÷ 2.54 × DPI

反过来，已知像素求厘米：

厘米 = 像素 ÷ DPI × 2.54

这两条式子是整篇文章的核心，建议直接抄在便签上。实际工作中百分之九十的换算都是这两条的变形。

拿 8cm 依次代进去验算一遍，跟前面表格里的数字对得上，说明路子是对的。我在教别人的时候会强调：别背结果，背式子。结果会忘，式子推一遍只要十秒。

2.2 CSS 里的 cm 和 mm 是“名义单位”，跟尺子量出来的不一样

这一段是网页方向的人最容易踩的坑。

CSS 规范里明确规定了一组绝对单位的换算关系：1in = 96px，1cm = 96/2.54 ≈ 37.795px，1mm = 3.7795px，1pt = 1/72in ≈ 1.333px，1pc = 12pt = 16px。

按这个规定，width: 8cm在浏览器里就是 302.36px。

问题在于，这个 96px 是规范写死的锚点，跟设备真实的物理密度没关系。你把浏览器窗口拖到不同显示器上，8cm元素的物理宽度会跟着变，因为浏览器根本不问显示器到底多大、每英寸多少个点。它只认“1 英寸等于 96 个 CSS 像素”这条规矩。

所以，如果你在网页里用cm想做出“拿尺子在屏幕上量正好 8 厘米”的效果，基本不可能。这是 CSS 单位的设计取舍，不是 bug。

那 CSS 里这些绝对单位还有没有用？有，但主要用在打印样式上。写@media print的时候，用cm、mm、pt描述页面尺寸和字号是有意义的，因为这时候浏览器会跟打印系统交接真实尺寸。我做过一个标签打印的页面，成品是 8cm×5cm，就是用@page { size: 80mm 50mm; }配合mm单位做的，打出来拿尺子量基本准。

2.3 三个容易算错的地方：取整方向、四舍五入、单位错位

手算的时候有几个细小但致命的问题，我列一下自己遇到过的。

取整方向。算出来 944.88 像素，取 944 还是 945？印刷场景我建议向上取整，宁多一点不能少。少 0.12 个像素听起来无所谓，但如果是一张整版图，尺寸差一点点在拼版时会被拉伸，肉眼能看出来。屏幕场景反过来，向下取整更安全，避免多出一个像素撑破容器触发换行。

四舍五入的累积误差。如果一版物料里有几十个元素都按厘米标注、都要换算，每个都四舍五入，误差会累积。我一般保留两位小数参与后续计算，只在最终输出时取整。手算的话，中间过程别急着舍入。

单位错位。这是最隐蔽的一种。有些文档写的“8cm 需要 302 像素”，那个 302 是按 96DPI 算的，如果你把它当成 300DPI 的结果拿去印刷，实际印出来宽度只有 2.56cm 左右，缩了三分之二。看到任何换算结果，第一件事是确认它用的是什么密度，而不是直接拿来用。

我见过一个更离谱的案例：有人把毫米当成厘米输入，8mm 算成了 8cm 的像素值，印出来的字大了一圈，整批物料报废。从那以后我给自己定了条规矩——所有尺寸标注必须带单位，表格里单独设一列写单位，不允许裸数字。

3. 分场景套用：印刷、网页、移动端、设计稿各走各的路

3.1 印刷品：8cm 按 945 像素起稿，顺手把出血算进去

印刷是这套换算里要求最严的场景，因为它有物理交付物，错了没法改。

商业印刷的通用标准是300DPI，意思是每英寸 300 个点，肉眼在正常阅读距离下已经看不出颗粒。所以8cm 宽在印刷场景下就是 945 像素。

实际起稿的时候还要多算两笔：

第一笔是出血。印刷品裁切会有 1~3mm 的偏差，所以设计稿要在成品尺寸外扩一圈，通常上下左右各留 3mm。8cm 宽 + 左右各 3mm = 8.6cm，对应像素是 8.6 ÷ 2.54 × 300 ≈ 1016 像素。少了这一圈，裁切偏一点就会出现白边。

第二笔是安全区。重要的文字、logo 要离裁切线至少 3~5mm，不然有可能被切到。这个距离同样要换算成像素来做参考线：3mm ≈ 35 像素（300DPI 下）。

有一张常用尺寸的对照表，我常年贴在显示器边上：

A4 那一行的 2551×3583 是行业里被引用最多的数字之一，很多人背下来直接用。但我建议还是理解着记：297mm + 6mm = 303mm，303 ÷ 25.4 × 300 ≈ 3578.7，向上取整到 3583 是因为有些流程会额外留一点余量。

还有一个容易被忽略的点：印刷用 CMYK，屏幕用 RGB。你按 945 像素做的 RGB 图，转成 CMYK 之后颜色会变，尤其是鲜艳的绿色和蓝色。所以真正交付前，我一般会先转色再检查一遍，别等印出来才发现偏色。

3.2 网页与 CSS：96PPI 是写死的锚点，别指望物理精确

网页这边的规则前面提过，1cm = 37.795px，8cm = 302.36px。这个数值在所有遵循规范的浏览器里是一致的，可以放心用。

但有一个现实问题：用户的实际屏幕密度的确在变。一台普通的办公显示器可能是 96PPI，一台高分屏笔记本可能是 220PPI，手机更是 400PPI 往上。同样是 302 个 CSS 像素，在不同设备上占的物理宽度能差两三倍。

所以我做网页时的原则是：能用相对单位就别用绝对单位。布局用rem、%、fr、vw，字号用rem，间距用em或rem。px只用在确实需要固定值的场合，比如 1px 边框、图标尺寸。cm、mm、in基本只在打印样式表里出现。

如果你确实需要在网页上做一个“跟物理尺寸对齐”的东西，比如一个屏幕标尺，那就得靠 JS 探测真实密度，或者让用户手工校准。这类工具的实现思路是：先渲染一个已知 CSS 长度的元素，用设备接口拿到它的物理尺寸，算出比例，再据此缩放。这件事能做成，但很麻烦，而且需要用户配合，一般项目不会这么干。

顺便说一句分辨率适配：现代页面都得加一行<meta name="viewport" content="width=device-width, initial-scale=1">，否则手机会按 980px 的虚拟宽度渲染再缩放，所有尺寸全乱。这一行是移动端适配的地基，忘了它后面怎么调都是错的。

3.3 移动端与设计稿：750 宽、375 逻辑像素、8cm 的位置在哪

移动端设计稿的换算跟物理厘米基本脱钩了，它走的是另一套逻辑：逻辑像素 + 倍图。

以常见的 750px 宽设计稿为例，它对应的是 375 逻辑像素宽、2 倍密度的设备。设计稿上量出 100px，代码里写 50pt（或 50 个逻辑像素），渲染时系统再乘 2 变成 100 个物理像素，正好对上。

这套体系里，“8cm”这个概念几乎不会出现。偶尔出现，一般是两种情况：

一种是从物理尺寸反推。比如要做一个宽度占屏幕 8cm 的卡片，先算设备屏幕的物理宽度。假设某款手机屏幕宽 6.5cm、逻辑分辨率 375，那 8cm 超出了屏幕宽度，这个需求本身就不成立。这类需求要先跟产品确认——他要的可能是“占屏幕宽度的某个比例”，而不是真的 8 厘米。

另一种是打印类的小程序页面。比如电子发票、快递面单，最终要落到纸上，这时候就得老老实实按 300DPI 算，8cm = 945 像素，然后在生成 PDF 或图片的时候按这个像素数输出。

移动端还有一个坑是devicePixelRatio 的取值不一定是整数。有些设备是 2.75、3.5 这样的值，1px 边框在这些设备上会被渲染成非整数物理像素，出现模糊或者粗细不均。解决办法是用transform: scale()做 0.5px 的伪元素，或者直接用细边框的替代方案（比如背景渐变、box-shadow）。这个技巧跟厘米换算没直接关系，但只要做移动端就绕不开。

3.4 图片素材：物理尺寸和像素尺寸是两条独立的线

做设计交付的时候，我习惯同时给出两个数：像素尺寸和建议物理尺寸。前者是硬指标，后者是建议值。

比如一张 8cm 宽的 banner 图，我交付时会写：945×300px，建议 8cm×2.54cm @300DPI。这样印厂拿到手不用猜，网页那边拿到手也能直接用像素值。

反过来，如果只给物理尺寸不给像素，就会出现前面说的“三个人三个答案”；如果只给像素不给物理尺寸，印厂可能按默认 DPI 铺开，尺寸对不上。

还有一个实操细节：导出图片时不要勾选“缩小到指定尺寸”之类的选项，除非你确认过它按什么密度换算。很多工具的这个选项默认用的是 72DPI，勾了之后 945 像素的图会被重采样成 227 像素，画质直接崩掉。我一般导出原始像素，物理尺寸写在文件名或者交付说明里。

4. 我在换算上栽过的几个坑

4.1 设计稿标 8cm，前端做出来小了一圈

这个坑印象最深。设计师在稿子上标了一个 8cm 宽的模块，我在 CSS 里写了width: 8cm，本地看着还行。上线之后有人在低分辨率显示器上看，说模块明显偏窄。

排查过程是这样：先确认 CSS 有没有被覆盖，没有；再看浏览器实际计算值，DevTools 显示 302.36px，符合规范；然后量物理宽度，在我这台 96PPI 的显示器上是 8cm 没错，但在另一台 110PPI 的显示器上只有 7cm 左右。

根因就是前面说的：CSS 的 cm 是名义单位，不跟真实密度挂钩。修法很简单，把width: 8cm改成width: 302px（或者更好，改成百分比），至少在同样的像素密度下表现一致。想真正跨设备一致，只能放弃物理尺寸诉求，改用相对布局。

从那以后我给自己定了规矩：网页里不写 cm。看到设计稿标厘米，先问清楚这个尺寸是给屏幕的还是给打印的，屏幕的就换算成像素或者比例，打印的才保留厘米。

4.2 名片边缘被切掉一条白边

另一个案子是印名片。设计给的文件是标准的 90×54mm，我直接拿去印，结果裁切之后有几张边缘露白。

查下来是出血没留。90×54mm 是成品尺寸，实际文件应该是 96×60mm（四周各加 3mm）。设计以为“我按成品尺寸做的就行了”，印厂的机器又不可能百分百精准，偏差 1~2mm 很常见，于是就露白了。

修复流程是：把画布扩到 96×60mm，背景色和底图延展铺满，重要内容往里收 3mm。换算成像素（300DPI）就是 1134×709，安全区距边 35 像素左右。

这个教训让我养成了一个习惯：凡是印刷类需求，先问三句话——成品尺寸多少、出血留多少、有没有专色。三句话问完，后面基本不会翻车。

顺便说一下，出血这部分内容如果做成了渐变或者纯色底，延展很容易；如果是照片，就得在边缘做镜像或者模糊填充，不能直接拉伸，否则会被看出来。

4.3 高分屏上那条 1px 边框“消失”了

这个严格说不算厘米换算的坑，但同属“尺寸单位”这一类，一起说。

场景是给一个卡片加 1px 边框，在普通屏上正常，在高分屏上肉眼几乎看不见，或者粗细不均。原因是设备像素比是 2，1 个 CSS 像素对应 2 个物理像素，边框渲染时被分配到非整数位置，抗锯齿之后颜色变淡。

尝试过几种方案：

最后选了伪元素 + transform 的方案，写成一套可复用的样式类。这件事的启发是：像素不是绝对的最小单位，它只是 CSS 里的一个逻辑刻度。理解了这一层，很多尺寸问题就迎刃而解了。

5. 把换算自动化：几个能直接用的小工具

5.1 一段可复用的换算函数

手算容易出错，我习惯把换算封成函数，随手调用。下面这两段可以直接抄。

JavaScript 版本：

// 厘米转像素 function cmToPx(cm, dpi = 300) { return Math.round((cm / 2.54) * dpi); } // 像素转厘米 function pxToCm(px, dpi = 300) { return (px / dpi) * 2.54; } // 输出保留两位小数，方便核对 console.log(cmToPx(8, 300)); // 945 console.log(cmToPx(8, 96)); // 302 console.log(pxToCm(945, 300)); // 8.00

Python 版本，做批量处理的时候更好用：

def cm_to_px(cm: float, dpi: int = 300) -> int: return round(cm / 2.54 * dpi) def px_to_cm(px: float, dpi: int = 300) -> float: return round(px / dpi * 2.54, 2) # 批量换算一张常用尺寸表 sizes_cm = [3, 5, 8, 10, 15, 21, 29.7] for s in sizes_cm: print(f"{s}cm -> {cm_to_px(s, 300)}px @300DPI")

跑一遍输出，3cm 是 354px，5cm 是 591px，8cm 是 945px，10cm 是 1181px，15cm 是 1772px，21cm 是 2480px，29.7cm 是 3508px。最后两个数字眼熟吧——正好是 A4 纸在 300DPI 下的标准像素尺寸。验算对上了，说明函数没问题。

5.2 怎么快速确认一个文件的真实密度

手边没有工具的场合，我一般这么干：

第一步，看像素尺寸。绝大多数系统里右键属性或者详细信息就能看到，或者用命令行的图像信息工具读出来。

第二步，看物理尺寸。印刷文件一般会在文件名或者图层里标注，没有的话按成品尺寸算。

第三步，两个数一除。像素宽 ÷ (物理宽 ÷ 2.54) = 实际密度。低于 300 就提醒一下可能不清晰，低于 150 基本就得重做了。

这个三步法我用了很多年，比任何软件的 DPI 显示都可靠，因为它算的是真实值，不受元数据干扰。

5.3 反向使用：从像素反推能不能印

这是更常见的场景——别人扔给你一张图，问“这个能印 8cm 宽吗”。

我的判断标准写在下面：

这套标准不是绝对的，还要看观看距离。户外大牌可能 30DPI 就够，因为没人贴着看；名片 300DPI 起步，因为拿在手里。判断的时候把距离因素加进去，结论会更准。

提示：如果拿到的是矢量文件（PDF、SVG、AI 之类），就不用纠结这个表了。矢量图没有固定像素，输出多大尺寸就按多大尺寸重新渲染，密度天然够用。

6. 一些零碎但有用的补充

6.1 常见厘米尺寸的像素速查

把常用值整理成一张表，300DPI 和 96DPI 两列都列上，省得每次重算：

这张表我打印出来贴在工位上，用久了基本能记住几个关键值：1cm 在 300DPI 下约 118 像素，10cm 约 1181 像素，A4 的长度约 3508 像素。有这三个锚点，其他值都能估算出来。

6.2 换算里最容易被忽略的“观看距离”因素

严格来说，密度需求跟观看距离强相关。行业里有个粗略的经验值：最小可分辨细节约为观看距离的 1/3000。按这个推，30cm 阅读距离需要大约 300DPI，2 米观看距离需要大约 45DPI，10 米外 10DPI 就够。

这就解释了为什么户外喷绘用 72DPI 甚至更低也没问题，而名片必须 300DPI 起步。同样是“8cm 宽”，贴在广告牌上和拿在手里，需要的像素数能差一个数量级。

做方案的时候把这个因素摆出来，能省掉很多争执。有人坚持“必须 300DPI”，你把观看距离一说，他可能就改成 150DPI 了，文件体积小一半，处理速度快好几倍。

6.3 我现在的固定工作流

最后说下我处理这类换算的固定流程，基本不会出错：

一是先定场景，屏幕还是印刷，这一句决定用哪套密度。

二是把物理尺寸转成目标像素，用函数或者查表，保留精确值参与计算。

三是加余量和安全区，印刷加 3mm 出血，屏幕留响应式空间。

四是回头验算，用反推公式把最终像素再算回厘米，看看跟需求对不对得上。这一步经常能抓到前面算错的地方。

五是在交付物里写清楚，像素尺寸、建议物理尺寸、密度三个数一起给，别让人猜。

这套流程听起来啰嗦，但跑熟了也就一两分钟的事。真正省时间的是后面——不用返工。

最后再分享一个小技巧：不管用什么工具算，算完都拿一张 A4 纸比划一下。A4 是 21×29.7cm，这个尺寸人人有直觉。你把结果按比例折一下，8cm 大概就是 A4 短边的一半略少一点，如果算出来的尺寸跟这个直觉差得远，那大概率是单位或者密度搞错了。这个土办法帮我抓出过好几次错，比重新推导一遍还快。