每次做 Canvas 图文海报、数据可视化大屏或者那种带文字截断的图表标签都会被同一个问题卡住文字到底占多宽写死的宽度在开发机上一看刚好合适换台电脑或者换个字体文字直接溢出画布、互相叠字或者被截断成半截丑得没法看。遇到这种场景就该轮到measureText上场了。它是 Canvas 2D 上下文自带的方法专门用来测量指定文本在当前位置和字体状态下的实际渲染宽度。你只需要传入字符串它就能返回一个TextMetrics对象里面带着width等精度极高的测量结果然后你就可以用这个值去做换行、居中对齐、省略号截断、动态列宽计算彻底告别“拿脑袋估宽度”的野路子。这篇文章就围绕measureText把相关的内容一次讲透。从基本用法到精度问题、换行算法、字体加载的坑、DPR 适配、离屏测量、性能优化再到我实际项目里踩过的几个典型问题全部整理出来给同样在 Canvas 文字排版上折腾过的朋友做个参考。不管你是刚接触 Canvas 的新手还是已经在做图表库、海报生成器的老手这篇都值得花几分钟看完。1. measureText 基础先搞懂它到底量了什么1.1 基本用法与返回结构measureText的调用方式非常简单但很多人其实没有认真看过它返回的对象导致后面用起来含糊。const canvas document.createElement(canvas); const ctx canvas.getContext(2d); ctx.font 16px PingFang SC, Microsoft YaHei, sans-serif; const metrics ctx.measureText(前端打工人); console.log(metrics.width); // 实际渲染宽度单位是 CSS 像素 console.log(metrics.actualBoundingBoxLeft); // 文字左边界到起始点的距离 console.log(metrics.actualBoundingBoxRight); // 文字右边界到起始点的距离 console.log(metrics.actualBoundingBoxAscent); // 文字上边界到基线的距离 console.log(metrics.actualBoundingBoxDescent);// 文字下边界到基线的距离 console.log(metrics.fontBoundingBoxAscent); // 字体整体上边界到基线的距离 console.log(metrics.fontBoundingBoxDescent); // 字体整体下边界到基线的距离绝大多数场景下width就是我们最关心的值。但你如果做文字垂直居中、做带背景色的标签、做文字和图标混排的细腻对齐actualBoundingBoxAscent和actualBoundingBoxDescent会比width更有用。因为它们反映的是每个字符串实际“画出来”的区域而不是字体默认的行高。这里有一个很容易忽略的细节measureText的测量结果是上下文当前状态下的结果。也就是说font、letterSpacing、textAlign、direction等属性都会影响测量结果。尤其是font设置不同字体、不同字号同一个字符串量出来的宽度可能差别巨大。ctx.font 14px sans-serif; const widthA ctx.measureText(测测测).width; ctx.font 28px serif; const widthB ctx.measureText(测测测).width; // widthA 和 widthB 完全不同每次测量前必须先设置好ctx.font和其他相关属性否则量出来的大概率是上一次调用残留的状态或者是最初始的默认值10px sans-serif这会直接导致后续排版全部错位。1.2 为什么不用“估字符宽度”的土办法很多人在遇到文字换行问题时第一反应是“一个汉字大概等于字号大小一个英文大概等于半个汉字”于是写一个估算函数function estimateWidth(text, fontSize) { let width 0; for (const char of text) { if (/[\u4e00-\u9fff]/.test(char)) { width fontSize; } else { width fontSize * 0.6; } } return width; }这个方案在纯中文场景下勉强能用但只要碰到数字、英文、标点、空格混排误差就非常明显。同样的字号下全角标点和半角标点宽度不同大写字母和小写字母宽度不同数字和字母宽度不同更不用说还有各种非衬线字体里等宽与比例字形的区别。举一个实际场景表格列头“2024年营收增长率”如果用估算方案可能算出来宽度是 190px但实际渲染宽度可能是 176px也可能超过 200px。差别一旦超出一两个字符表格就会溢出或者出现大片留白。measureText存在的意义就是把这个估算过程变成精确测量。它调用的是浏览器排版引擎的测量能力返回的结果和canvas实际绘制出来的宽度是一致的这样就保证了“量出来多少画出来就是多少”。1.3 影响测量宽度的隐藏因素除了font字号之外还有几个容易忽视的因素会影响measureText的结果。第一个是letterSpacing。当你设置了ctx.letterSpacing 2px每个字符之间的间距会增加width结果也会相应变大。这个属性在个别浏览器上兼容性一般但只要有设置测量结果就包含了字间距。第二个是字体栈的实际匹配结果。你设置了ctx.font 16px SomeFont, PingFang SC, sans-serif如果用户电脑上没装SomeFont浏览器会用PingFang SC渲染测量结果也是按PingFang SC的实际字形算的。所以绝不能拿着设计稿里的某个字体宽度到处套用一定要在目标环境里实测。第三个是textAlign。measureText返回的width不受textAlign影响但actualBoundingBoxLeft和actualBoundingBoxRight会受影响。这点容易绕晕记一个原则如果你只是想拿文本宽度做布局计算统一用width就够了如果你要精确知道文字左边缘和右边缘相对绘制起点的位置关注actualBoundingBox系列。2. 宽度测量高频坑精度、DPR 与字体加载2.1 浮点精度与取整策略measureText返回的width是一个浮点数比如136.5625。这个精度很高但实际用于布局时我们会面临一个问题是按浮点累加还是每行取整按照浮点累加每行宽度都精确到小数点后三四位最后画出来确实准确但容易在多处坐标叠加时出现 0.5px 的模糊缝隙。按照每行四舍五入取整视觉上更干净但累计误差可能让最后一行放不下。我个人的处理方式是浮点用于测量和比较整数用于最终绘制坐标。const textLines [第一行内容, 第二行内容, 第三行内容]; const maxWidth 300; const drawLines []; for (const line of textLines) { const w ctx.measureText(line).width; drawLines.push({ text: line, width: w, drawWidth: Math.round(w) }); }比较时直接用浮点判断是否超出maxWidth绘制时用Math.round处理坐标避免半像素渲染造成文字发虚。还有一种情况是循环累加换行时宽度比较要用而不是。比如maxWidth是 100某一行文本宽度刚好量出来是99.9999用判断就可能提前换行产生一个尾巴上只挂一个字的多余行。实测中这种边界情况并不多但一旦出现视觉上非常明显。2.2 设备像素比DPR对测量结果的影响这是做可视化大屏和海报导出最容易踩的坑。measureText返回的宽度单位是 CSS 像素和 Canvas 实际绘制时的逻辑坐标一致。如果你在普通屏幕上开发在 2 倍屏上预览Canvas 的物理像素翻了倍但逻辑坐标不变测量结果也不变。问题通常出在绘制高清 Canvas的时候。很多人会这样做const dpr window.devicePixelRatio || 1; canvas.width cssWidth * dpr; canvas.height cssHeight * dpr; ctx.scale(dpr, dpr);只要ctx.scale(dpr, dpr)被调用了后续的measureText和fillText就都在缩放后的坐标系里工作测出来的宽度依然是 CSS 像素值这就没问题。但如果你为了超清导出直接设置canvas.width 2000然后用ctx.font 48px sans-serif去测量那量出来的宽度就是 2000 物理像素坐标系下的宽度和你在屏幕上习惯看到的 CSS 像素宽度完全对不上。处理办法是在测量前先统一坐标系要么ctx.scale(dpr, dpr)保持逻辑坐标系要么手动把设计稿尺寸换算成物理像素。提示ctx.font设置的字号单位是 CSS 像素不是物理像素。在设计 2 倍图导出时如果要让导出的图片用 48px 的字号清晰地呈现最终绘制状态应该是ctx.scale(2, 2)后再设置ctx.font 48px sans-serif而不是直接不缩放地设置96px。前者的measureText结果还可以直接被业务逻辑复用后者虽然也可以但要全程记得从未缩放的状态开始。2.3 字体加载前测量最大的隐形杀手measureText只能测量当前已加载的字体。如果页面里用font-face声明了一种自定义字体但通过 JavaScript 动态加载或者字体文件还在网络请求中那么ctx.font虽然设置了自定义字体但浏览器实际会回退到默认字体去渲染和测量。这种情况下你可能会遇到一个非常迷惑的现象本地开发时字体加载快测量结果和设计稿一致线上环境字体文件大、加载慢用户打开页面时第一帧文字溢出、重叠但过一会儿刷新又恢复正常。根本原因就是字体加载时序。解决思路有两个第一用document.fonts.ready等待所有使用中的字体加载完成再执行测量和绘制。async function drawWhenFontReady(canvas, drawFn) { try { await document.fonts.ready; } catch (e) { // 字体加载失败时继续执行至少不阻塞页面 } drawFn(); }第二用document.fonts.load主动加载指定字体并传入待加载的字体规则。async function loadFont(fontString, textSample) { const font new FontFace(MyFont, url(/fonts/MyFont.woff2)); await font.load(); document.fonts.add(font); }等待完成后再去设置ctx.font、再调用measureText量出来的宽度才是最终的真实宽度。这里要特别提醒一个细节字体加载完成后之前的测量结果全部作废。如果你在字体加载前已经缓存了一批文本宽度字体加载后必须清空缓存重新测量否则后续绘制依然会用错误数据。2.4 不同浏览器之间的测量差异同样是16px的sans-serif在不同操作系统、不同浏览器里默认字体不同同一个字符串的宽度也会有差别。系统字体栈的设计本来就是“优先使用用户系统里有的字体”所以这种差异无法消除。如果你做的是跨平台产品最稳妥的方式是在测量前就明确指定字体而且只指定那些你有把握在所有目标平台都有覆盖的字体或者使用 Web Font 统一字体来源。例如统一使用16px HarmonyOS Sans SC, PingFang SC, Microsoft YaHei, sans-serif虽然前两种字体在某些设备上没有但回退顺序可预测实测后可以在所有目标设备上保持一致或接近的结果。如果要求更高比如做海报生成器需要在各种终端上导出几乎一致的效果那就必须把字体文件打包加载用FontFace注册成固定名称再在ctx.font里使用这个固定名称来绘图。只有这样才能真正实现“设计稿怎么排导出就怎么排”。3. 实战文本换行、截断与对齐的完整方案3.1 在 Canvas 中实现文本自动换行Canvas 的fillText本身不支持自动换行所有换行都需要我们自己计算。measureText就是换行功能的基础。基本思路是从一个字符串开头累积字符每累加一个字符就测量当前累积字符串的宽度如果宽度超过最大宽度就把当前位置断为一行然后从下一个字符重新开始累积。这种“逐字符measureText”的写法简单直接但性能上有个隐患一个长段落几百个字符每个字符都调用一次measureText累积起来可能有上千次调用。对于一次性绘制需求这个开销还在可接受范围内但如果涉及到拖拽实时预览、动画帧重绘就可能卡顿。优化方案是二分查找对每个新起点的下标用二分逼近找到一个最大的endIndex让text.slice(start, endIndex)的宽度不超过最大宽度。这样每行的测量次数从“字符数”降到“log 字符数”。在超长文本场景下性能提升非常明显。function breakTextToLines(ctx, text, maxWidth) { const lines []; let startIndex 0; while (startIndex text.length) { let low startIndex; let high text.length; while (low high) { const mid Math.ceil((low high) / 2); const substring text.slice(startIndex, mid); const width ctx.measureText(substring).width; if (width maxWidth) { low mid; } else { high mid - 1; } } // 处理连续英文或数字时二分跳过空格的问题 if (low startIndex) { // 单个字符都超宽只能强制切分否则会死循环 low startIndex 1; } lines.push(text.slice(startIndex, low)); startIndex low; } return lines; }这个实现里有个边界处理如果low startIndex说明连一个字符都放不下这时必须手动推进一位否则会无限循环。实际业务里很少出现单字符超过容器宽度的情况但防御性代码写上总是好的。3.2 带省略号的文本截断常见的文本截断需求是“最多显示 N 行超出显示省略号”。Canvas 里做省略号要记住一个点省略号本身也占宽度。先根据最大行数和行高计算出最大可用高度再配合逐行换行逻辑如果行数超过限制在最后一行尝试追加省略号然后不断缩短最后一个可见字符重新测量直到宽度不超限。function truncateText(ctx, text, maxWidth, maxLines, lineHeight) { const lines breakTextToLines(ctx, text, maxWidth); if (lines.length maxLines) { return lines; } const result lines.slice(0, maxLines - 1); let lastLine lines[maxLines - 1]; const ellipsis …; while (lastLine.length 0) { const temp lastLine.slice(0, -1) ellipsis; if (ctx.measureText(temp).width maxWidth) { lastLine temp; break; } lastLine lastLine.slice(0, -1); } result.push(lastLine); return result; }这里有个审美上的细节省略号最好用中文省略号“…”而不是三个英文句点“...”因为中文省略号在 Canvas 中默认渲染更均匀、视觉上更像“省略”的语义。如果你使用“...”三个点实际宽度会因字体不同产生较大波动而且和中文排版风格不太搭。另外截断后的最后一行通常要左对齐而不是居中视觉上更自然。如果是居中排版截断位置可以微调为从中间或尾部开始不过大多数业务场景用左对齐简单可靠。3.3 文字水平居中与垂直居中的坐标计算水平居中很多人直接用ctx.textAlign center然后fillText(text, centerX, y)这样确实能居中。但需要留意的是textAlign: center会影响所有文本的绘制如果同一段代码里还有左对齐的文本就会互相干扰。另一种做法是不改textAlign直接通过measureText计算偏移const textWidth ctx.measureText(text).width; const startX (canvasWidth - textWidth) / 2; ctx.fillText(text, startX, y);这种做法在多段文本混排时更可控因为每个fillText的坐标都是独立算出来的不会因为全局状态被临时改动而出问题。垂直居中的坑更多。fillText的y参数是基线位置不是文字的中心位置。直接传canvasHeight / 2然后发现文字偏上这就是把基线当中心线了。所以在不知道文字实际高度的场景里用measureText拿actualBoundingBoxAscent和actualBoundingBoxDescent来算垂直中心是更准的方式。const metrics ctx.measureText(text); const textHeight metrics.actualBoundingBoxAscent metrics.actualBoundingBoxDescent; const centerY (canvasHeight - textHeight) / 2 metrics.actualBoundingBoxAscent; ctx.fillText(text, centerX, centerY);centerY的公式含义先算出文字整体高度然后让文字的中心点对齐到画布中心最后加上 ascent 偏移量把基线位置计算出来。这样不管字体如何变化文字都保持在视觉中心。3.4 图表场景中的动态列宽分配在表格型 Canvas 应用里我们经常要把一列文字均匀地放到一个宽度范围里比如柱状图的分类轴标签、表格的列头、图例项。这时候需要根据文字总体积来动态分配宽度。假设我们有多个列头文本每列至少要能放下自己的文本和一个内边距否则就会出现文字重叠。动态列宽分配的一个常见实现是先测量每一列文本的期望宽度再把剩余空间按比例分配。function distributeColumnWidths(ctx, headers, totalWidth, padding) { const measured headers.map((text) ({ text, minWidth: ctx.measureText(text).width padding * 2 })); const totalMinWidth measured.reduce((sum, item) sum item.minWidth, 0); if (totalMinWidth totalWidth) { // 空间足够按比例分配剩余空间 const extra totalWidth - totalMinWidth; measured.forEach((item) { item.finalWidth item.minWidth (extra * item.minWidth) / totalMinWidth; }); } else { // 空间不够只能截断文本 measured.forEach((item) { const maxWidth (totalWidth * item.minWidth) / totalMinWidth; item.finalWidth maxWidth; item.displayText truncateText(ctx, item.text, maxWidth - padding * 2, 1, 0)[0]; }); } return measured; }按比例分配而不是平均分配是因为不同列的文本长度本来就不一样平均分配会让短文本列浪费大量空白长文本列反而挤成一团。按比例分配相对公平视觉上也更自然。4. 进阶实践离屏测量、缓存策略与批量排版4.1 用离屏 Canvas 做纯测量每次需要测量文本时都创建一个新的 Canvas 上下文成本虽然不高但也不是零。大量重复测量时GC 压力会上升。更规范的做法是创建一个“测量专用”的离屏 Canvas它不加入 DOM不占视觉面积只负责提供上下文。let measureContext null; function getMeasureContext() { if (measureContext) { return measureContext; } const canvas document.createElement(canvas); canvas.width 1; canvas.height 1; measureContext canvas.getContext(2d); return measureContext; } function measureTextWidth(text, font) { const ctx getMeasureContext(); ctx.font font; return ctx.measureText(text).width; }用离屏 Canvas 的好处有两个第一不会受主 Canvas 当前状态的干扰第二测量前必须显式传入font字符串反而促使你写出“无状态测量”的干净代码避免漏设字体导致的脏数据。如果你的项目里已经有主 Canvas也可以直接用主 Canvas 测量但注意测量会修改ctx.font状态如果后续绘制依赖之前的字体设置就必须重新设置。离屏 Canvas 能彻底隔离这个问题不容易埋雷。4.2 文本宽度缓存加速重复绘制有些场景会反复测量同一批文本比如拖拽缩放、窗口 resize、动画重绘。每次重新测量显然浪费。一个带容量限制的 Map 缓存可以极大减少重绘开销。const textWidthCache new Map(); const CACHE_CAPACITY 5000; function getCachedTextWidth(text, font) { const key ${font}|${text}; if (textWidthCache.has(key)) { return textWidthCache.get(key); } const ctx getMeasureContext(); ctx.font font; const width ctx.measureText(text).width; if (textWidthCache.size CACHE_CAPACITY) { const firstKey textWidthCache.keys().next().value; textWidthCache.delete(firstKey); } textWidthCache.set(key, width); return width; }这里的 KEY 组合是${font}|${text}而不是只放 text。因为同一个字符串在不同字重、不同字号下宽度不同漏掉font会造成严重错误。如果你的场景里还有letterSpacing等其他影响宽度的属性也要拼进 KEY。在实际项目中我遇到过把缓存容量设成无限结果页面长时间运行后缓存几万条文本内存占用涨了不少。加一个容量上限用简单的“删除最老一条”策略就够用不必上复杂的 LRU。4.3 高频场景结合 ResizeObserver 做自适应重排大屏项目的容器宽高经常动态变化每次变化都要重新测量、重新排版、重新绘制。操作不当会在拖动窗口时明显掉帧。一个高效的做法是把“测量绘制”的流程拆成两步测量结果放进缓存只有容器尺寸发生了实质性变化比如变化超过 1px才重新测量。let lastLayoutWidth 0; let lastLayoutHeight 0; let layoutCache null; function handleResize(entries) { const width entries[0].contentRect.width; const height entries[0].contentRect.height; if (Math.abs(width - lastLayoutWidth) 1 Math.abs(height - lastLayoutHeight) 1) { return; } lastLayoutWidth width; lastLayoutHeight height; layoutCache null; requestRender(); }ResizeObserver在一些浏览器里触发频率很高加入一个 1px 的容差阈值能挡住大量无意义的重绘。之后再结合requestAnimationFrame把渲染动作合并到下一帧性能体验会好很多。4.4 富文本场景同一段落多种字体怎么量做聊天表情、标题加粗、富文本标签时一段文本里可能混合了不同字体、不同大小、不同颜色的片段。measureText一次只能测一种字体状态下的文本所以多字体富文本需要“分段测量拼接”。思路是先按样式变化切成多个片段每个片段用对应的字体和字号测量宽度累加得到整段实际渲染宽度。绘制时记录每个片段的起始 x 坐标逐个fillText。function measureRichTextSegments(ctx, segments) { let totalWidth 0; const positioned []; for (const seg of segments) { ctx.font seg.font; const w ctx.measureText(seg.text).width; positioned.push({ text: seg.text, font: seg.font, color: seg.color, width: w, startX: totalWidth }); totalWidth w; } return { totalWidth, positioned }; }这种方式还能顺带支持“点击文字命中检测”把每个片段当成一个矩形区域用点击坐标逐个判断落在哪个片段里就能实现 Canvas 上的富文本交互。这是我在做某个富文本标签需求时用到的方案比整体测宽度灵活很多。5. 常见问题排查measureText 踩坑速查与调试技巧5.1 高频问题与解决方案现象原因解决办法测量宽度和实际显示宽度不一致测量前没有正确设置ctx.font确保每次测量前重新设置font或者用离屏上下文隔离状态自定义字体加载前测量偏窄/偏宽浏览器回退字体渲染measureText测的是回退字体宽度用document.fonts.ready或FontFace.load()等待字体加载完成2 倍屏下文字发虚或宽度错位没有正确使用ctx.scale(dpr, dpr)绘制前ctx.scale(dpr, dpr)保持逻辑坐标测量和绘制一致逐字符测量导致明显卡顿measureText调用次数过多换用二分查找换行、增加文本宽度缓存相同文本在不同浏览器宽度不同系统默认字体不同导致的正常差异统一使用 Web Font 或固定字体栈导出类场景必须内嵌字体垂直方向文字偏移居中不准把fillText的y参数当成了中心线使用actualBoundingBoxAscentactualBoundingBoxDescent计算基线坐标最后一行放不下被多切一个字浮点比较时边界处理不当比较用浮点绘制坐标四舍五入边界判断用而不是的地方要小心省略号出现得很突兀直接截断字符串后硬加“...”保证省略号后整个字符串重新测量宽度不超限再提交绘制5.2 我的排查工具与方法分享一个排查measureText问题的调试思路只靠 console 打印宽度数值往往不够直观更好的办法是在页面上叠加一个半透明辅助层把每个文本的测量矩形画出来。function debugTextBounds(ctx, text, x, y, font, color rgba(255, 0, 0, 0.4)) { ctx.save(); ctx.font font; const metrics ctx.measureText(text); const width metrics.width; const left x metrics.actualBoundingBoxLeft; const top y - metrics.actualBoundingBoxAscent; const height metrics.actualBoundingBoxAscent metrics.actualBoundingBoxDescent; ctx.strokeStyle color; ctx.lineWidth 1; ctx.strokeRect(left, top, width, height); ctx.restore(); }在关键文字区域调用这个函数就能直观看到每个字符串的测量边界和实际渲染位置是否吻合。如果发现矩形框和文字本身有一两像素的偏移就有很大概率是ctx.font在测量前和绘制前不一致。还有一个排查思路把字体加载状态打印出来。document.fonts.check(16px MyFont)返回false就说明该字体还没加载完成所有基于这个字体的measureText结果都不可信。5.3 我自己踩过的两个坑第一个坑省掉了ctx.font的设置。最开始写工具函数时为了减少重复代码我提前在初始化的时候设置过一次ctx.font后续所有measureText都没有再次设置。结果在绘制逻辑里因为别的功能需要临时切换字体改动了ctx.font后续所有测量全部基于错误字体计算。这个 bug 排查了大半天最后就是把这些“隐式状态”全部改成“显式设置”每次测量前都重新赋值font问题立刻消失。第二个坑缓存 key 忘记包含字体信息。第一次做文本宽度缓存的时候我直接用文本字符串作为 Map 的 key结果发现同一个字符串在标题和正文里字号不同宽度缓存互相污染排版错乱。后来把font拼进 key 里才解决。这个错误虽然低级但很有代表性——只要你的系统里存在多种字体状态缓存 key 就必须包含所有影响宽度的状态。注意measureText的测量结果和ctx.textBaseline无关textBaseline只影响绘制时基线到文字的位置关系不影响宽度。所以不要因为在某个地方改过textBaseline而怀疑测量结果。6. 一个综合示例动态卡片排版完整代码把前面讲的技术点组合在一起做一个综合示例根据数字卡片内容自动计算出合适的文字大小和行数并在卡片里完美居中展示。function drawAutoFittedCard(canvas, text, padding) { const ctx canvas.getContext(2d); const canvasWidth canvas.width; const canvasHeight canvas.height; const maxContentWidth canvasWidth - padding * 2; const maxContentHeight canvasHeight - padding * 2; let fontSize 72; // 1. 从大到小尝试字号找到能放下内容的最大字号 let lines []; let lineHeight 0; while (fontSize 12) { ctx.font 600 ${fontSize}px PingFang SC, sans-serif; lineHeight fontSize * 1.4; lines breakTextToLines(ctx, text, maxContentWidth); const totalTextHeight lines.length * lineHeight; if (totalTextHeight maxContentHeight) { break; } fontSize - 2; } // 2. 按最终字号绘制文本垂直居中 const totalHeight lines.length * lineHeight; const startY (canvasHeight - totalHeight) / 2 lineHeight * 0.8; for (let i 0; i lines.length; i) { const lineWidth ctx.measureText(lines[i]).width; const startX (canvasWidth - lineWidth) / 2; ctx.fillText(lines[i], startX, startY i * lineHeight); } }这个示例演示了三个关键步骤先用二分换行求文本行再根据measureText结果和可用高度动态调整字号最后用测量宽度计算水平居中坐标。虽然看起来简单但已经把measureText的几个核心用途全部串联起来了。如果你手头正好有的项目用 Canvas 画过文字大概率遇到过文字溢出、字体没加载完导致排版错乱、高分屏上文字发虚这几类问题。这些问题表面原因五花八门根子上都离不开“测量”这一步。measureText就是这根准绳所有绘制前先量一量、先算一算Canvas 排版就能从“凭感觉”变成“有依据”也省得在设计稿、测试机和真实环境之间反复对样式。最后再分享一个个人实操经验measureText用熟之后最好把“换行函数”“截断函数”“缓存函数”抽成独立工具模块每个函数只依赖ctx、text、maxWidth这些显式参数不依赖全局状态。这样将来换项目、换框架代码可以直接复用排查问题也快。Canvas 文字排版看起来是不起眼的细活但一个一个坑踩平了后面做海报、做图表、做富文本编辑器都会顺手很多。 
长河君 · 2026/10/15 16:25:12 · 阅读 1.2k Canvas文本测量实战：用measureText解决文字溢出与排版难题
每次做 Canvas 图文海报、数据可视化大屏或者那种带文字截断的图表标签都会被同一个问题卡住文字到底占多宽写死的宽度在开发机上一看刚好合适换台电脑或者换个字体文字直接溢出画布、互相叠字或者被截断成半截丑得没法看。遇到这种场景就该轮到measureText上场了。它是 Canvas 2D 上下文自带的方法专门用来测量指定文本在当前位置和字体状态下的实际渲染宽度。你只需要传入字符串它就能返回一个TextMetrics对象里面带着width等精度极高的测量结果然后你就可以用这个值去做换行、居中对齐、省略号截断、动态列宽计算彻底告别“拿脑袋估宽度”的野路子。这篇文章就围绕measureText把相关的内容一次讲透。从基本用法到精度问题、换行算法、字体加载的坑、DPR 适配、离屏测量、性能优化再到我实际项目里踩过的几个典型问题全部整理出来给同样在 Canvas 文字排版上折腾过的朋友做个参考。不管你是刚接触 Canvas 的新手还是已经在做图表库、海报生成器的老手这篇都值得花几分钟看完。1. measureText 基础先搞懂它到底量了什么1.1 基本用法与返回结构measureText的调用方式非常简单但很多人其实没有认真看过它返回的对象导致后面用起来含糊。const canvas document.createElement(canvas); const ctx canvas.getContext(2d); ctx.font 16px PingFang SC, Microsoft YaHei, sans-serif; const metrics ctx.measureText(前端打工人); console.log(metrics.width); // 实际渲染宽度单位是 CSS 像素 console.log(metrics.actualBoundingBoxLeft); // 文字左边界到起始点的距离 console.log(metrics.actualBoundingBoxRight); // 文字右边界到起始点的距离 console.log(metrics.actualBoundingBoxAscent); // 文字上边界到基线的距离 console.log(metrics.actualBoundingBoxDescent);// 文字下边界到基线的距离 console.log(metrics.fontBoundingBoxAscent); // 字体整体上边界到基线的距离 console.log(metrics.fontBoundingBoxDescent); // 字体整体下边界到基线的距离绝大多数场景下width就是我们最关心的值。但你如果做文字垂直居中、做带背景色的标签、做文字和图标混排的细腻对齐actualBoundingBoxAscent和actualBoundingBoxDescent会比width更有用。因为它们反映的是每个字符串实际“画出来”的区域而不是字体默认的行高。这里有一个很容易忽略的细节measureText的测量结果是上下文当前状态下的结果。也就是说font、letterSpacing、textAlign、direction等属性都会影响测量结果。尤其是font设置不同字体、不同字号同一个字符串量出来的宽度可能差别巨大。ctx.font 14px sans-serif; const widthA ctx.measureText(测测测).width; ctx.font 28px serif; const widthB ctx.measureText(测测测).width; // widthA 和 widthB 完全不同每次测量前必须先设置好ctx.font和其他相关属性否则量出来的大概率是上一次调用残留的状态或者是最初始的默认值10px sans-serif这会直接导致后续排版全部错位。1.2 为什么不用“估字符宽度”的土办法很多人在遇到文字换行问题时第一反应是“一个汉字大概等于字号大小一个英文大概等于半个汉字”于是写一个估算函数function estimateWidth(text, fontSize) { let width 0; for (const char of text) { if (/[\u4e00-\u9fff]/.test(char)) { width fontSize; } else { width fontSize * 0.6; } } return width; }这个方案在纯中文场景下勉强能用但只要碰到数字、英文、标点、空格混排误差就非常明显。同样的字号下全角标点和半角标点宽度不同大写字母和小写字母宽度不同数字和字母宽度不同更不用说还有各种非衬线字体里等宽与比例字形的区别。举一个实际场景表格列头“2024年营收增长率”如果用估算方案可能算出来宽度是 190px但实际渲染宽度可能是 176px也可能超过 200px。差别一旦超出一两个字符表格就会溢出或者出现大片留白。measureText存在的意义就是把这个估算过程变成精确测量。它调用的是浏览器排版引擎的测量能力返回的结果和canvas实际绘制出来的宽度是一致的这样就保证了“量出来多少画出来就是多少”。1.3 影响测量宽度的隐藏因素除了font字号之外还有几个容易忽视的因素会影响measureText的结果。第一个是letterSpacing。当你设置了ctx.letterSpacing 2px每个字符之间的间距会增加width结果也会相应变大。这个属性在个别浏览器上兼容性一般但只要有设置测量结果就包含了字间距。第二个是字体栈的实际匹配结果。你设置了ctx.font 16px SomeFont, PingFang SC, sans-serif如果用户电脑上没装SomeFont浏览器会用PingFang SC渲染测量结果也是按PingFang SC的实际字形算的。所以绝不能拿着设计稿里的某个字体宽度到处套用一定要在目标环境里实测。第三个是textAlign。measureText返回的width不受textAlign影响但actualBoundingBoxLeft和actualBoundingBoxRight会受影响。这点容易绕晕记一个原则如果你只是想拿文本宽度做布局计算统一用width就够了如果你要精确知道文字左边缘和右边缘相对绘制起点的位置关注actualBoundingBox系列。2. 宽度测量高频坑精度、DPR 与字体加载2.1 浮点精度与取整策略measureText返回的width是一个浮点数比如136.5625。这个精度很高但实际用于布局时我们会面临一个问题是按浮点累加还是每行取整按照浮点累加每行宽度都精确到小数点后三四位最后画出来确实准确但容易在多处坐标叠加时出现 0.5px 的模糊缝隙。按照每行四舍五入取整视觉上更干净但累计误差可能让最后一行放不下。我个人的处理方式是浮点用于测量和比较整数用于最终绘制坐标。const textLines [第一行内容, 第二行内容, 第三行内容]; const maxWidth 300; const drawLines []; for (const line of textLines) { const w ctx.measureText(line).width; drawLines.push({ text: line, width: w, drawWidth: Math.round(w) }); }比较时直接用浮点判断是否超出maxWidth绘制时用Math.round处理坐标避免半像素渲染造成文字发虚。还有一种情况是循环累加换行时宽度比较要用而不是。比如maxWidth是 100某一行文本宽度刚好量出来是99.9999用判断就可能提前换行产生一个尾巴上只挂一个字的多余行。实测中这种边界情况并不多但一旦出现视觉上非常明显。2.2 设备像素比DPR对测量结果的影响这是做可视化大屏和海报导出最容易踩的坑。measureText返回的宽度单位是 CSS 像素和 Canvas 实际绘制时的逻辑坐标一致。如果你在普通屏幕上开发在 2 倍屏上预览Canvas 的物理像素翻了倍但逻辑坐标不变测量结果也不变。问题通常出在绘制高清 Canvas的时候。很多人会这样做const dpr window.devicePixelRatio || 1; canvas.width cssWidth * dpr; canvas.height cssHeight * dpr; ctx.scale(dpr, dpr);只要ctx.scale(dpr, dpr)被调用了后续的measureText和fillText就都在缩放后的坐标系里工作测出来的宽度依然是 CSS 像素值这就没问题。但如果你为了超清导出直接设置canvas.width 2000然后用ctx.font 48px sans-serif去测量那量出来的宽度就是 2000 物理像素坐标系下的宽度和你在屏幕上习惯看到的 CSS 像素宽度完全对不上。处理办法是在测量前先统一坐标系要么ctx.scale(dpr, dpr)保持逻辑坐标系要么手动把设计稿尺寸换算成物理像素。提示ctx.font设置的字号单位是 CSS 像素不是物理像素。在设计 2 倍图导出时如果要让导出的图片用 48px 的字号清晰地呈现最终绘制状态应该是ctx.scale(2, 2)后再设置ctx.font 48px sans-serif而不是直接不缩放地设置96px。前者的measureText结果还可以直接被业务逻辑复用后者虽然也可以但要全程记得从未缩放的状态开始。2.3 字体加载前测量最大的隐形杀手measureText只能测量当前已加载的字体。如果页面里用font-face声明了一种自定义字体但通过 JavaScript 动态加载或者字体文件还在网络请求中那么ctx.font虽然设置了自定义字体但浏览器实际会回退到默认字体去渲染和测量。这种情况下你可能会遇到一个非常迷惑的现象本地开发时字体加载快测量结果和设计稿一致线上环境字体文件大、加载慢用户打开页面时第一帧文字溢出、重叠但过一会儿刷新又恢复正常。根本原因就是字体加载时序。解决思路有两个第一用document.fonts.ready等待所有使用中的字体加载完成再执行测量和绘制。async function drawWhenFontReady(canvas, drawFn) { try { await document.fonts.ready; } catch (e) { // 字体加载失败时继续执行至少不阻塞页面 } drawFn(); }第二用document.fonts.load主动加载指定字体并传入待加载的字体规则。async function loadFont(fontString, textSample) { const font new FontFace(MyFont, url(/fonts/MyFont.woff2)); await font.load(); document.fonts.add(font); }等待完成后再去设置ctx.font、再调用measureText量出来的宽度才是最终的真实宽度。这里要特别提醒一个细节字体加载完成后之前的测量结果全部作废。如果你在字体加载前已经缓存了一批文本宽度字体加载后必须清空缓存重新测量否则后续绘制依然会用错误数据。2.4 不同浏览器之间的测量差异同样是16px的sans-serif在不同操作系统、不同浏览器里默认字体不同同一个字符串的宽度也会有差别。系统字体栈的设计本来就是“优先使用用户系统里有的字体”所以这种差异无法消除。如果你做的是跨平台产品最稳妥的方式是在测量前就明确指定字体而且只指定那些你有把握在所有目标平台都有覆盖的字体或者使用 Web Font 统一字体来源。例如统一使用16px HarmonyOS Sans SC, PingFang SC, Microsoft YaHei, sans-serif虽然前两种字体在某些设备上没有但回退顺序可预测实测后可以在所有目标设备上保持一致或接近的结果。如果要求更高比如做海报生成器需要在各种终端上导出几乎一致的效果那就必须把字体文件打包加载用FontFace注册成固定名称再在ctx.font里使用这个固定名称来绘图。只有这样才能真正实现“设计稿怎么排导出就怎么排”。3. 实战文本换行、截断与对齐的完整方案3.1 在 Canvas 中实现文本自动换行Canvas 的fillText本身不支持自动换行所有换行都需要我们自己计算。measureText就是换行功能的基础。基本思路是从一个字符串开头累积字符每累加一个字符就测量当前累积字符串的宽度如果宽度超过最大宽度就把当前位置断为一行然后从下一个字符重新开始累积。这种“逐字符measureText”的写法简单直接但性能上有个隐患一个长段落几百个字符每个字符都调用一次measureText累积起来可能有上千次调用。对于一次性绘制需求这个开销还在可接受范围内但如果涉及到拖拽实时预览、动画帧重绘就可能卡顿。优化方案是二分查找对每个新起点的下标用二分逼近找到一个最大的endIndex让text.slice(start, endIndex)的宽度不超过最大宽度。这样每行的测量次数从“字符数”降到“log 字符数”。在超长文本场景下性能提升非常明显。function breakTextToLines(ctx, text, maxWidth) { const lines []; let startIndex 0; while (startIndex text.length) { let low startIndex; let high text.length; while (low high) { const mid Math.ceil((low high) / 2); const substring text.slice(startIndex, mid); const width ctx.measureText(substring).width; if (width maxWidth) { low mid; } else { high mid - 1; } } // 处理连续英文或数字时二分跳过空格的问题 if (low startIndex) { // 单个字符都超宽只能强制切分否则会死循环 low startIndex 1; } lines.push(text.slice(startIndex, low)); startIndex low; } return lines; }这个实现里有个边界处理如果low startIndex说明连一个字符都放不下这时必须手动推进一位否则会无限循环。实际业务里很少出现单字符超过容器宽度的情况但防御性代码写上总是好的。3.2 带省略号的文本截断常见的文本截断需求是“最多显示 N 行超出显示省略号”。Canvas 里做省略号要记住一个点省略号本身也占宽度。先根据最大行数和行高计算出最大可用高度再配合逐行换行逻辑如果行数超过限制在最后一行尝试追加省略号然后不断缩短最后一个可见字符重新测量直到宽度不超限。function truncateText(ctx, text, maxWidth, maxLines, lineHeight) { const lines breakTextToLines(ctx, text, maxWidth); if (lines.length maxLines) { return lines; } const result lines.slice(0, maxLines - 1); let lastLine lines[maxLines - 1]; const ellipsis …; while (lastLine.length 0) { const temp lastLine.slice(0, -1) ellipsis; if (ctx.measureText(temp).width maxWidth) { lastLine temp; break; } lastLine lastLine.slice(0, -1); } result.push(lastLine); return result; }这里有个审美上的细节省略号最好用中文省略号“…”而不是三个英文句点“...”因为中文省略号在 Canvas 中默认渲染更均匀、视觉上更像“省略”的语义。如果你使用“...”三个点实际宽度会因字体不同产生较大波动而且和中文排版风格不太搭。另外截断后的最后一行通常要左对齐而不是居中视觉上更自然。如果是居中排版截断位置可以微调为从中间或尾部开始不过大多数业务场景用左对齐简单可靠。3.3 文字水平居中与垂直居中的坐标计算水平居中很多人直接用ctx.textAlign center然后fillText(text, centerX, y)这样确实能居中。但需要留意的是textAlign: center会影响所有文本的绘制如果同一段代码里还有左对齐的文本就会互相干扰。另一种做法是不改textAlign直接通过measureText计算偏移const textWidth ctx.measureText(text).width; const startX (canvasWidth - textWidth) / 2; ctx.fillText(text, startX, y);这种做法在多段文本混排时更可控因为每个fillText的坐标都是独立算出来的不会因为全局状态被临时改动而出问题。垂直居中的坑更多。fillText的y参数是基线位置不是文字的中心位置。直接传canvasHeight / 2然后发现文字偏上这就是把基线当中心线了。所以在不知道文字实际高度的场景里用measureText拿actualBoundingBoxAscent和actualBoundingBoxDescent来算垂直中心是更准的方式。const metrics ctx.measureText(text); const textHeight metrics.actualBoundingBoxAscent metrics.actualBoundingBoxDescent; const centerY (canvasHeight - textHeight) / 2 metrics.actualBoundingBoxAscent; ctx.fillText(text, centerX, centerY);centerY的公式含义先算出文字整体高度然后让文字的中心点对齐到画布中心最后加上 ascent 偏移量把基线位置计算出来。这样不管字体如何变化文字都保持在视觉中心。3.4 图表场景中的动态列宽分配在表格型 Canvas 应用里我们经常要把一列文字均匀地放到一个宽度范围里比如柱状图的分类轴标签、表格的列头、图例项。这时候需要根据文字总体积来动态分配宽度。假设我们有多个列头文本每列至少要能放下自己的文本和一个内边距否则就会出现文字重叠。动态列宽分配的一个常见实现是先测量每一列文本的期望宽度再把剩余空间按比例分配。function distributeColumnWidths(ctx, headers, totalWidth, padding) { const measured headers.map((text) ({ text, minWidth: ctx.measureText(text).width padding * 2 })); const totalMinWidth measured.reduce((sum, item) sum item.minWidth, 0); if (totalMinWidth totalWidth) { // 空间足够按比例分配剩余空间 const extra totalWidth - totalMinWidth; measured.forEach((item) { item.finalWidth item.minWidth (extra * item.minWidth) / totalMinWidth; }); } else { // 空间不够只能截断文本 measured.forEach((item) { const maxWidth (totalWidth * item.minWidth) / totalMinWidth; item.finalWidth maxWidth; item.displayText truncateText(ctx, item.text, maxWidth - padding * 2, 1, 0)[0]; }); } return measured; }按比例分配而不是平均分配是因为不同列的文本长度本来就不一样平均分配会让短文本列浪费大量空白长文本列反而挤成一团。按比例分配相对公平视觉上也更自然。4. 进阶实践离屏测量、缓存策略与批量排版4.1 用离屏 Canvas 做纯测量每次需要测量文本时都创建一个新的 Canvas 上下文成本虽然不高但也不是零。大量重复测量时GC 压力会上升。更规范的做法是创建一个“测量专用”的离屏 Canvas它不加入 DOM不占视觉面积只负责提供上下文。let measureContext null; function getMeasureContext() { if (measureContext) { return measureContext; } const canvas document.createElement(canvas); canvas.width 1; canvas.height 1; measureContext canvas.getContext(2d); return measureContext; } function measureTextWidth(text, font) { const ctx getMeasureContext(); ctx.font font; return ctx.measureText(text).width; }用离屏 Canvas 的好处有两个第一不会受主 Canvas 当前状态的干扰第二测量前必须显式传入font字符串反而促使你写出“无状态测量”的干净代码避免漏设字体导致的脏数据。如果你的项目里已经有主 Canvas也可以直接用主 Canvas 测量但注意测量会修改ctx.font状态如果后续绘制依赖之前的字体设置就必须重新设置。离屏 Canvas 能彻底隔离这个问题不容易埋雷。4.2 文本宽度缓存加速重复绘制有些场景会反复测量同一批文本比如拖拽缩放、窗口 resize、动画重绘。每次重新测量显然浪费。一个带容量限制的 Map 缓存可以极大减少重绘开销。const textWidthCache new Map(); const CACHE_CAPACITY 5000; function getCachedTextWidth(text, font) { const key ${font}|${text}; if (textWidthCache.has(key)) { return textWidthCache.get(key); } const ctx getMeasureContext(); ctx.font font; const width ctx.measureText(text).width; if (textWidthCache.size CACHE_CAPACITY) { const firstKey textWidthCache.keys().next().value; textWidthCache.delete(firstKey); } textWidthCache.set(key, width); return width; }这里的 KEY 组合是${font}|${text}而不是只放 text。因为同一个字符串在不同字重、不同字号下宽度不同漏掉font会造成严重错误。如果你的场景里还有letterSpacing等其他影响宽度的属性也要拼进 KEY。在实际项目中我遇到过把缓存容量设成无限结果页面长时间运行后缓存几万条文本内存占用涨了不少。加一个容量上限用简单的“删除最老一条”策略就够用不必上复杂的 LRU。4.3 高频场景结合 ResizeObserver 做自适应重排大屏项目的容器宽高经常动态变化每次变化都要重新测量、重新排版、重新绘制。操作不当会在拖动窗口时明显掉帧。一个高效的做法是把“测量绘制”的流程拆成两步测量结果放进缓存只有容器尺寸发生了实质性变化比如变化超过 1px才重新测量。let lastLayoutWidth 0; let lastLayoutHeight 0; let layoutCache null; function handleResize(entries) { const width entries[0].contentRect.width; const height entries[0].contentRect.height; if (Math.abs(width - lastLayoutWidth) 1 Math.abs(height - lastLayoutHeight) 1) { return; } lastLayoutWidth width; lastLayoutHeight height; layoutCache null; requestRender(); }ResizeObserver在一些浏览器里触发频率很高加入一个 1px 的容差阈值能挡住大量无意义的重绘。之后再结合requestAnimationFrame把渲染动作合并到下一帧性能体验会好很多。4.4 富文本场景同一段落多种字体怎么量做聊天表情、标题加粗、富文本标签时一段文本里可能混合了不同字体、不同大小、不同颜色的片段。measureText一次只能测一种字体状态下的文本所以多字体富文本需要“分段测量拼接”。思路是先按样式变化切成多个片段每个片段用对应的字体和字号测量宽度累加得到整段实际渲染宽度。绘制时记录每个片段的起始 x 坐标逐个fillText。function measureRichTextSegments(ctx, segments) { let totalWidth 0; const positioned []; for (const seg of segments) { ctx.font seg.font; const w ctx.measureText(seg.text).width; positioned.push({ text: seg.text, font: seg.font, color: seg.color, width: w, startX: totalWidth }); totalWidth w; } return { totalWidth, positioned }; }这种方式还能顺带支持“点击文字命中检测”把每个片段当成一个矩形区域用点击坐标逐个判断落在哪个片段里就能实现 Canvas 上的富文本交互。这是我在做某个富文本标签需求时用到的方案比整体测宽度灵活很多。5. 常见问题排查measureText 踩坑速查与调试技巧5.1 高频问题与解决方案现象原因解决办法测量宽度和实际显示宽度不一致测量前没有正确设置ctx.font确保每次测量前重新设置font或者用离屏上下文隔离状态自定义字体加载前测量偏窄/偏宽浏览器回退字体渲染measureText测的是回退字体宽度用document.fonts.ready或FontFace.load()等待字体加载完成2 倍屏下文字发虚或宽度错位没有正确使用ctx.scale(dpr, dpr)绘制前ctx.scale(dpr, dpr)保持逻辑坐标测量和绘制一致逐字符测量导致明显卡顿measureText调用次数过多换用二分查找换行、增加文本宽度缓存相同文本在不同浏览器宽度不同系统默认字体不同导致的正常差异统一使用 Web Font 或固定字体栈导出类场景必须内嵌字体垂直方向文字偏移居中不准把fillText的y参数当成了中心线使用actualBoundingBoxAscentactualBoundingBoxDescent计算基线坐标最后一行放不下被多切一个字浮点比较时边界处理不当比较用浮点绘制坐标四舍五入边界判断用而不是的地方要小心省略号出现得很突兀直接截断字符串后硬加“...”保证省略号后整个字符串重新测量宽度不超限再提交绘制5.2 我的排查工具与方法分享一个排查measureText问题的调试思路只靠 console 打印宽度数值往往不够直观更好的办法是在页面上叠加一个半透明辅助层把每个文本的测量矩形画出来。function debugTextBounds(ctx, text, x, y, font, color rgba(255, 0, 0, 0.4)) { ctx.save(); ctx.font font; const metrics ctx.measureText(text); const width metrics.width; const left x metrics.actualBoundingBoxLeft; const top y - metrics.actualBoundingBoxAscent; const height metrics.actualBoundingBoxAscent metrics.actualBoundingBoxDescent; ctx.strokeStyle color; ctx.lineWidth 1; ctx.strokeRect(left, top, width, height); ctx.restore(); }在关键文字区域调用这个函数就能直观看到每个字符串的测量边界和实际渲染位置是否吻合。如果发现矩形框和文字本身有一两像素的偏移就有很大概率是ctx.font在测量前和绘制前不一致。还有一个排查思路把字体加载状态打印出来。document.fonts.check(16px MyFont)返回false就说明该字体还没加载完成所有基于这个字体的measureText结果都不可信。5.3 我自己踩过的两个坑第一个坑省掉了ctx.font的设置。最开始写工具函数时为了减少重复代码我提前在初始化的时候设置过一次ctx.font后续所有measureText都没有再次设置。结果在绘制逻辑里因为别的功能需要临时切换字体改动了ctx.font后续所有测量全部基于错误字体计算。这个 bug 排查了大半天最后就是把这些“隐式状态”全部改成“显式设置”每次测量前都重新赋值font问题立刻消失。第二个坑缓存 key 忘记包含字体信息。第一次做文本宽度缓存的时候我直接用文本字符串作为 Map 的 key结果发现同一个字符串在标题和正文里字号不同宽度缓存互相污染排版错乱。后来把font拼进 key 里才解决。这个错误虽然低级但很有代表性——只要你的系统里存在多种字体状态缓存 key 就必须包含所有影响宽度的状态。注意measureText的测量结果和ctx.textBaseline无关textBaseline只影响绘制时基线到文字的位置关系不影响宽度。所以不要因为在某个地方改过textBaseline而怀疑测量结果。6. 一个综合示例动态卡片排版完整代码把前面讲的技术点组合在一起做一个综合示例根据数字卡片内容自动计算出合适的文字大小和行数并在卡片里完美居中展示。function drawAutoFittedCard(canvas, text, padding) { const ctx canvas.getContext(2d); const canvasWidth canvas.width; const canvasHeight canvas.height; const maxContentWidth canvasWidth - padding * 2; const maxContentHeight canvasHeight - padding * 2; let fontSize 72; // 1. 从大到小尝试字号找到能放下内容的最大字号 let lines []; let lineHeight 0; while (fontSize 12) { ctx.font 600 ${fontSize}px PingFang SC, sans-serif; lineHeight fontSize * 1.4; lines breakTextToLines(ctx, text, maxContentWidth); const totalTextHeight lines.length * lineHeight; if (totalTextHeight maxContentHeight) { break; } fontSize - 2; } // 2. 按最终字号绘制文本垂直居中 const totalHeight lines.length * lineHeight; const startY (canvasHeight - totalHeight) / 2 lineHeight * 0.8; for (let i 0; i lines.length; i) { const lineWidth ctx.measureText(lines[i]).width; const startX (canvasWidth - lineWidth) / 2; ctx.fillText(lines[i], startX, startY i * lineHeight); } }这个示例演示了三个关键步骤先用二分换行求文本行再根据measureText结果和可用高度动态调整字号最后用测量宽度计算水平居中坐标。虽然看起来简单但已经把measureText的几个核心用途全部串联起来了。如果你手头正好有的项目用 Canvas 画过文字大概率遇到过文字溢出、字体没加载完导致排版错乱、高分屏上文字发虚这几类问题。这些问题表面原因五花八门根子上都离不开“测量”这一步。measureText就是这根准绳所有绘制前先量一量、先算一算Canvas 排版就能从“凭感觉”变成“有依据”也省得在设计稿、测试机和真实环境之间反复对样式。最后再分享一个个人实操经验measureText用熟之后最好把“换行函数”“截断函数”“缓存函数”抽成独立工具模块每个函数只依赖ctx、text、maxWidth这些显式参数不依赖全局状态。这样将来换项目、换框架代码可以直接复用排查问题也快。Canvas 文字排版看起来是不起眼的细活但一个一个坑踩平了后面做海报、做图表、做富文本编辑器都会顺手很多。