ch单位能控制每行字符数，因其等于当前字体中“0”的宽度，随font-size和字体变化，天然适配缩放与多语言混排；需配合width: 100%和max-width防溢出，慎与vw/vh混用。
ch单位为什么能控制每行字符数？
因为1ch等于当前字体中“0”字符的宽度，等宽字体下它≈1个字符宽；非等宽字体下是平均估算值，但足够用于阅读宽度约束。它不依赖像素或视口，只随font-size和字体变化，天然适配缩放、系统字体设置、多语言混排（比如中英数字并存时，“0”的宽度仍稳定）。
常见错误现象：直接写width: 60ch却发现文字在小屏上溢出容器——这是因为没配合max-width和width: 100%，导致60ch在大字号下撑爆屏幕。
- 必须搭配
width: 100%让元素先弹性收缩 - 用
max-width兜底，防止ch在大字号/大屏下失控（例如max-width: 960px） - 对正文容器加
margin: 0 auto居中，避免靠左挤成窄条
如何用ch + calc()实现“舒适行宽”自适应？
纯60ch在手机上可能过宽（比如16px字号时60ch≈960px），在超大屏又太窄。用calc()混合ch与百分比，才能兼顾可读性与弹性。
典型写法：max-width: calc(100% - 4ch)适用于侧边栏固定字符宽度的布局；更通用的是max-width: min(960px, calc(100% - 2ch))（需@supports (max-width: min())支持），但兼容性有限，稳妥做法仍是分层控制。
立即学习“前端免费学习笔记（深入）”；
- 小屏（≤768px）：
max-width: 100%，不设ch限制 - 中屏（769–1200px）：
max-width: 65ch，约50–60英文字符/行 - 大屏（≥1201px）：
max-width: 80ch，上限放宽但不放任拉伸
ch单位在不同字体下的表现差异
ch永远基于“0”，不是“w”或“m”。这意味着在思源黑体、Noto Sans等无衬线字体中，1ch≈0.5em左右；但在Georgia这类衬线体中，0偏窄，1ch会低估实际平均字符宽度；而等宽字体（如Fira Code、JetBrains Mono）下最准。
容易踩的坑：用ch限制中文内容宽度时，误以为40ch≈40个汉字——其实中文字符宽度通常≈1em，而1ch≈0.5–0.6em，所以40ch实际只撑开约20–24个汉字，容易留白过多。
- 中英文混排建议按英文字符数定基准（如
60ch），再微调padding或letter-spacing - 用
CSS @font-face加载等宽字体时，ch才真正可靠 - 避免在
font-family回退链里混入差异巨大的字体（如"Monaco", "Segoe UI", monospace），会导致ch跳变
ch与vw/vh混用是否合理？
不推荐。vw/vh锚定视口，ch锚定字体度量，二者逻辑层级不同。强行组合如width: calc(50vw + 20ch)会导致缩放行为不可预测：用户调大系统字体时，ch变大，但vw不变，结果反而失衡。
真正需要的是“字体相关弹性”+“视口相关边界”，这时应分层处理：
- 用
ch控内容密度（如max-width: 72ch） - 用
clamp()控根字号（如html { font-size: clamp(16px, 2.5vw, 20px); }） - 用
100dvh控全屏高度，和ch无关但常共存于同页
最易被忽略的一点：ch单位在打印样式表（@media print）中依然生效，且打印机字体往往不是网页所用字体——若未用@supports或@media隔离，打印PDF时可能出现意外换行或截断。
