content-box仅在必须严格匹配内容区尺寸时被动使用：SVG viewBox映射、老系统JS逻辑兼容、可拖拽textarea直觉交互三类场景需显式设置，且须避免伪元素被通配符重置。
content-box只在“尺寸必须等于内容区”时才被动使用
它不是一种主动选择的布局策略，而是当业务逻辑或外部系统强制要求 width 和 height 严格对应内容区域（不包含 padding、border）时，不得不保留的兼容边界。现代项目中几乎从不“选用”，而是“绕开”或“隔离”。
SVG容器内嵌 viewBox 需要 content-box
当一个 <svg> 元素直接设置 width 和 height，且其 viewBox 值与内容区域需一一映射时，box-sizing: content-box 是唯一能保证缩放比例不失真的方式。例如：
<svg width="200" height="100" viewBox="0 0 200 100"> <rect x="10" y="10" width="180" height="80"/> </svg>
若此时误加 padding: 10px 并设为 border-box，实际渲染内容区会被压缩，导致 viewBox 映射错位。
- 必须显式写
box-sizing: content-box，不能依赖默认值（因为某些框架会全局重置） - 避免对 SVG 添加任何
padding或border，否则需用transform或外层 wrapper 隔离 - 这类组件建议加注释：// viewBox 精确映射，禁用 border-box
对接老系统或 legacy JS 尺寸计算逻辑
部分遗留系统（如十年前写的 CMS 后台、定制化报表工具）中，JS 直接读取 offsetWidth 并假设它 = contentWidth + padding + border；而另一些则硬编码了 clientWidth 与 contentWidth 的差值。一旦你全局启用 border-box，这些逻辑会误判尺寸变化。
立即学习“前端免费学习笔记（深入）”；
- 只对特定 class（如
.legacy-report-card）覆盖：.legacy-report-card { box-sizing: content-box; } - 不要用通配符重置影响它，否则
::before伪元素可能意外触发偏移 - 调试时重点检查
getBoundingClientRect().width与offsetWidth是否一致——不一致往往意味着盒模型混用
可拖拽 textarea 的交互直觉要求
当用户拉伸一个带 resize: both 的 <textarea>，其直觉是“拉宽 = 内容区变宽”，而非“拉宽 = 总宽度变宽”。此时若设为 border-box，padding 会吃掉用户拖出来的空间，导致输入区域增长不明显，体验割裂。
- 仅限明确启用了
resize且暴露了padding的场景（如带边框+内边距的富文本编辑器底栏） - 必须同步处理溢出：加
overflow: auto，并确保min-width不低于内容最小所需 - 注意：多数 UI 库（如 Ant Design 的
Input.TextArea）已封装该逻辑，勿在封装组件内部再手动覆盖
最容易被忽略的是伪元素：哪怕你只在一个组件里局部用 content-box，也得确认它的 ::before 和 ::after 没被通配重置覆盖——否则装饰图标、遮罩层会突然“变小”或错位，而且很难定位。
