表单控件因默认 content-box 盒模型导致宽度计算异常，引发对齐错乱、溢出和响应式失效；根本解法是全局设置 , ::before , *::after { box-sizing: border-box; } 并验证各控件实际盒模型。
因为 content-box 让 width 和 padding 叠加计算，表单控件在不同浏览器、不同组件库中尺寸行为不一致，导致对齐错乱、横向溢出、响应式失效——这不是写错了，是盒模型默认逻辑在“合理地捣乱”。
为什么表单 input 的 width: 100% 总是撑破容器？
后台表单常见结构是 <div class="field"><input type="text" class="input"></div>，你设了 width: 100% 和 padding: 8px，结果 input 比父容器宽出 16px。这是因为 content-box 下：总宽 = 内容区宽度 + 左右 padding + 左右 border。父容器没设 box-sizing: border-box，子元素又没重置，就必然溢出。
- Chrome 和 Firefox 表现一致，但 Safari（尤其旧版）对
input的默认box-sizing更顽固，常回退到content-box - 第三方 UI 库（如 Bulma、Ant Design）虽已全局重置，但如果你在自定义表单组件里漏写了
*::before, *::after，伪元素触发的下拉箭头或清空按钮就会尺寸错位 -
flex布局中，input设flex: 1+padding，content-box会让它挤占兄弟元素空间，甚至换行
为什么表单栅格对齐总在 Safari 里偏移几像素？
后台常用 columns 或 grid 排列多字段，比如两列 is-6 的 field。一旦某个 input 有 border: 1px，而另一个只有 border: 0，content-box 会让前者实际宽度多出 2px —— 在 Safari 的 sub-pixel 渲染下，这 2px 就可能触发重排或视觉错位。
- 不是所有表单控件都默认继承父级
box-sizing：input、textarea、select在部分浏览器中会无视继承，坚持用content-box - 用
calc(100% - 16px)手动减去 padding 是临时解法，但一旦设计稿改 padding 为 12px，就得全局搜索替换，且无法响应缩放或 rem 动态计算 - Bulma 的
.input类本身设了box-sizing: border-box，但如果你用input[type="date"]等原生控件，它的 shadow DOM 内部仍走content-box，外部样式无法穿透
如何验证和修复表单里的 content-box 遗留问题？
别靠猜，直接看 DevTools 的 Computed 面板：选中任意 input，搜 box-sizing，确认值是不是 border-box；再看 Box Model 图示里，width 是否等于 “实际占用宽度” 减去 padding 和 border。
立即学习“前端免费学习笔记（深入）”；
- 全局重置必须包含伪元素：
*, *::before, *::after { box-sizing: border-box; }—— 漏掉*::after，Bulma 的navbar-burger或 Ant Design 的Tooltip就可能错位 - 对老项目，优先在表单容器上加
form { box-sizing: border-box; }，比通配符更安全，避免影响table或canvas等特殊元素 - 如果用了 CSS-in-JS（如 Emotion），确保 reset 规则注入在所有组件样式之前；Vite 用户可在
main.css顶部引入，而非通过@import，防止加载顺序错乱
真正麻烦的不是加那行 CSS，而是当你的表单在 Chrome 里严丝合缝，在 Safari 里却飘出 1px，而你翻了三遍代码都没发现某处 input 被第三方脚本动态加了 style="box-sizing: content-box" —— 这种干扰，只能靠 Computed 面板逐个点开看。
