网页字体如何随屏幕变化？从两个端点推导 CSS clamp 计算器
深圳技术大学
代码仓库
响应式字号常见的矛盾是：固定字号在手机上显得拥挤，纯 vw 又会在大屏上无限增长。clamp 可以把理想值约束在最小和最大字号之间，但实际项目需要的并不是记住一个示例，而是根据设计稿端点计算自己的表达式。把所有输入都生成同一段固定 CSS，看起来有输出，实际上并没有解决问题。
本项目接受最小字号、最大字号、最小视口和最大视口四个参数，推导线性插值，再生成可复制的 font-size。右侧使用独立 iframe 作为真正的预览视口，滑块改变 iframe 的宽度，浏览器自己计算其中的 vw。
用一条直线连接两个设计端点
设最小视口为 x，最大视口为 y，对应字号分别为 a 和 b。希望中间字号满足 f(w)=m×w+c，只需要令斜率 m=(b-a)/(y-x)，截距 c=a-m×x。由于一个 vw 等于当前视口宽度的百分之一，CSS 中 vw 前面的系数应为 m×100，而不是直接使用 m。最后把 a、这条直线和 b 组合进 clamp。
默认参数取十六像素、三十二像素、四百像素和一千二百像素。斜率是零点零二，截距是八，因此得到 clamp(16px, 2vw + 8px, 32px)。在四百像素视口中，理想值为十六；八百像素时为二十四；一千二百像素时为三十二。小于左端点继续使用最小字号，大于右端点保持最大字号。三个可核对的结果比单纯说“自动适应”更明确。
输出采用 px 端点，以避免把根字号配置混入第一版的参数模型。它不宣称同时完成 rem、用户字体偏好或所有无障碍策略。clamp 的语法和边界语义可参考 MDN clamp 文档。在真实站点落地时，还需要结合内容密度、缩放和用户偏好评估字体方案。
数学公式也需要输入契约
两个视口必须严格递增，否则分母为零或表达式方向相反。两个字号允许相同，此时输出等价于固定字号；最大字号不能小于最小字号，避免第一版同时承担反向插值的解释成本。字号范围限定为六到二百像素，视口限定为一百到一万像素，既保留实用范围，也防止误输入几个数量级。
所有参数都先检查空白，再转换为 Number，并用 Number.isFinite 拒绝非法值。单靠 HTML 的 min、max 不能保证核心函数被其他调用方使用时仍然安全。计算结果格式化到六位小数，在可读性和精度之间取一个明确平衡。由于最后会舍入，极端参数下可能存在很小的端点误差，不宜把生成式称为任意精度数学输出。
截距还可能是负数。生成 CSS 时先判断符号，再输出加号或减号与绝对值，避免形成容易误读的“加负数”表达式。最小与最大字号相等时，斜率为零仍然是有效输入。核心测试专门覆盖这两种情况，因为它们比默认的正斜率、正截距示例更能检验表达式生成是否完整。
以下代码摘自交付项目的 core.js：
(function(root){'use strict';functioncalculate(minFont,maxFont,minView,maxView){constvalues=[minFont,maxFont,minView,maxView];if(values.some(v=>String(v).trim()===''))throwError('请填写全部参数');const[a,b,x,y]=values.map(Number);if(![a,b,x,y].every(Number.isFinite))throwError('参数必须是有效数字');if(a<6||b>200||a>b)throwError('字号范围应为 6～200 px，最大字号不能小于最小字号');if(x<100||y>10000||x>=y)throwError('视口范围应为 100～10000 px，最大视口必须大于最小视口');constslope=(b-a)/(y-x),intercept=a-slope*x;constround=n=>Number(n.toFixed(6));constcss=`clamp(${a}px,${round(slope*100)}vw${intercept<0?'-':'+'}${Math.abs(round(intercept))}px,${b}px)`;return{css,slope,intercept,minFont:a,maxFont:b,minView:x,maxView:y};}functionatWidth(config,width){returnMath.max(config.minFont,Math.min(config.maxFont,config.slope*width+config.intercept));}root.ToolCore={calculate,atWidth};if(typeofmodule!=='undefined')module.exports=root.ToolCore;})(globalThis);预览中的 vw 必须有真正的视口
如果只把普通 div 的 width 改成八百像素，而文字仍然使用外层页面的 vw，字体并不会按 div 宽度计算。用户拖动滑块时看到的容器在变化，文字却由整个浏览器宽度决定，这种预览会给出错误直觉。本项目把文本放进 iframe，iframe 的内容文档拥有自己的视口，滑块改变的正是这个视口宽度。
预览外层允许局部横向滚动，在窄窗口中也能查看大于卡片宽度的独立视口。页面本身不因此横向撑开。滑块当前覆盖二百到一千六百像素，适合快速演示常见页面尺寸；参数允许的视口范围更大，因此超出滑块范围的端点仍然可以生成 CSS，但不能假装已经通过滑块展示所有可能宽度。
计算字号卡片由同一份斜率、截距和上下限计算，iframe 则由浏览器 CSS 引擎实际排版。两条路径可以互相核对。浏览器验证不是只读取数字卡片，而是进入 iframe 查询 getComputedStyle，分别检查端点和中点字号。这样能发现公式正确但样式未应用、iframe 宽度未更新或 vw 仍引用外层视口的问题。
错误状态不能继续复制旧结果
表单采用即时计算，用户删掉一个值或把两个视口设成相同时，会进入错误状态。此时取消当前配置，代码区显示修正提示，预览文档清空，复制按钮禁用，计算字号改为破折号。不能只在页面底部显示红色消息，却继续允许复制上一次成功的 CSS，否则用户很难判断拿到的是哪组参数。
当参数恢复有效，页面重新计算并恢复复制。生成区只有一条完整的 font-size 声明，便于粘贴到实际样式规则中。复制成功必须等剪贴板 Promise 完成后提示；权限被拒绝时保留可选择文本，告知手动复制。剪贴板行为由浏览器环境决定，因此工具的数学计算与复制能力被分开处理，复制受限不会让有效计算结果消失。
从公式正确走到交互可信
实现过程围绕三层职责展开：core 负责参数约束、插值和表达式；app 把输入、滑块和预览联动；界面解释单位、约束与滚动方式。普通脚本按顺序加载，避免直接打开本地文件时依赖模块加载器。文档记录真实命令与浏览器版本，读者既能运行页面，也能重跑纯逻辑断言。
测试中直接比较端点、中点与范围外结果，再检查负截距和固定字号。浏览器层进一步操作实际输入控件与 iframe，确认无效参数让复制失效，并覆盖剪贴板拒绝。手机宽度检查用于验证页面容器没有整体溢出，不代表已经完成所有手机浏览器的触屏和字体渲染测试。
后续可以增加 rem 输出、多个断点或响应式间距计算，但应保持“参数单位—公式—预览视口”三者一致。如果引入根字号参数，就必须在公式解释与 iframe 根样式里同步应用，不能只把输出中的 px 替换成 rem。这个工具最有价值的部分，正是把一条数学关系完整地落到浏览器能执行、用户能验证的界面上。
精度、单位与实际阅读体验
计算器使用浮点数，输出小数经过格式化，而浏览器排版又会受到子像素计算影响。因此测试对实际字号采用很小容差，不要求所有字符串在不同引擎中逐字相同。纯数学路径仍用可确定的参数验证精确示例，这样既没有放宽主要公式，也没有把显示层正常舍入误判成错误。对设计交付而言，更应关注端点、增长方向和可接受范围是否一致。
字号线性变化并不保证任意标题都能维持相同换行。文字长度、字体、字重、行高和容器宽度也会影响排版。工具预览只展示一段固定中英文文本，便于观察字号趋势；接入实际项目时，应再用真实标题和正文验证。不能把一个 font-size 表达式宣传成已经完成整站响应式排版。
预览滑块与四个公式参数也有不同职责。改变滑块只选择观察点，不重新定义设计端点；改变参数才更新 CSS 和预览文档。把两者混在一起会让用户拖动预览时意外改写输出。当前分离方式让生成规则保持稳定，用户可以反复浏览多个宽度再复制同一份样式，这是交互辅助工具比静态公式说明更实用的地方。
运行、文件职责与本次验证记录
本项目目录为05-clamp-calculator，采用原生 HTML、CSS 和 JavaScript，没有后端、外部字体或运行时 CDN。直接打开 index.html 可以使用主要功能；本次也通过真实浏览器验证了 file 协议下的主要交互。更推荐进入该目录执行下列命令，以 localhost 方式运行，便于获得一致的网页源和浏览器 API 行为。静态服务只监听本机回环地址，不需要配置账户或上传个人数据。
node serve.cjs.4279# 打开 http://127.0.0.1:4279/node--test test.cjsindex.html 负责语义结构和资源引用；styles.css 负责卡片、表单与移动宽度布局；core.js 保存本工具独立逻辑，同时导出给 Node 测试；app.js 负责事件绑定、状态变化和页面渲染。ui.js 提供状态提示、复制及本地下载等通用能力。脚本使用 defer 并按核心、通用界面、应用顺序加载，既等待 DOM 就绪，也让依赖关系明确。修改核心规则时先运行对应测试，再检查界面是否继续解释同一规则。
测试结果分成两层：Node 核心测试本次执行2 项，2 项通过、0 项失败、0 项跳过；真实 Chrome 155.0.8059.84 浏览器验证5 项通过、0 项失败、0 项跳过。浏览器的每项记录是一个包含多个断言的验证场景，不应与纯逻辑测试条数混算成同一种数量。原始记录保存在 docs/unit-results.tap 与 docs/browser-results.json，可以核对日期、场景和控制台检查，而不是只引用文章中的结论。
本次浏览器场景如下：
- iframe 真实字号命中两端和中点，CSS 随参数变化
- 无效端点阻止复制并清理旧预览
- 真实剪贴板复制与拒绝权限提示
- file:// 独立加载并执行主要交互，无页面或控制台错误
- 390px 手机宽度没有页面横向溢出
浏览器检查通过 Playwright 驱动实际 Chrome 页面，执行输入、点击、键盘或文件操作，并保存本文三张截图。相关脚本位于工具合集的 scripts/browser-check.cjs；使用合集复现时先运行 npm start，再在另一终端安装对应 Playwright 依赖并执行 npm run test:browser。本次使用环境已有运行库，没有要求运行页面的读者安装构建链。单独项目只需现代浏览器；Node 用于本地静态服务与纯逻辑测试，两个用途彼此独立。
本次页面错误与控制台错误记录均为空。三百九十像素宽度检查确认页面没有整体横向溢出，局部代码区、预览或表格允许自身滚动。这只是当前 Chrome 环境的布局证据，并非已经实测所有手机、旧浏览器或辅助技术。其他现代浏览器预计可以使用相关原生 API，但 Firefox、Safari 与实体移动设备本次未实测；若业务依赖特定平台，应按目标环境追加验证。
