为什么通配符里设 box-sizing: border-box 会出问题
直接在 * { box-sizing: border-box; } 里声明，看似一劳永逸，实际会干扰第三方组件、表单控件甚至某些 CSS 框架的默认布局逻辑。比如 textarea、select 在部分浏览器中依赖 content-box 计算内边距，强行改成 border-box 后，高度可能塌陷或文字被截断。
更隐蔽的问题是：伪元素（::before / ::after）也会被纳入这个规则，而它们常被用来做装饰性尺寸控制，一旦盒模型被统一覆盖，反而要额外重置。
- 不要对
*全局设box-sizing，尤其当项目引入了 Bootstrap、Element Plus 或自定义 UI 库时 - 若必须统一，优先用继承链更可控的方式——从
html或body开始声明，并用!important避免被子选择器意外覆盖（但慎用） - 检查 DevTools 的 Computed 面板，确认关键表单元素的
box-sizing值是否符合预期，别只信样式表顺序
真正安全的写法：用 html 根元素 + inherit
现代主流方案不是靠通配符，而是利用 CSS 继承特性。把 box-sizing: border-box 设在 html 上，再让所有后代元素继承——这样既避开通配符的性能和副作用问题，又保证绝大多数容器类元素自动生效。
html {
box-sizing: border-box;
}
*, *::before, *::after {
box-sizing: inherit;
}注意第二行：它只是确保伪元素也继承父级的 box-sizing，而不是重新设死值。这意味着如果某个组件内部显式写了 box-sizing: content-box，它依然能生效，不会被通配符暴力覆盖。
立即学习“前端免费学习笔记（深入）”；
-
html元素本身不参与布局渲染，设在这里零副作用 -
inherit比直接写border-box更柔性，兼容需要特殊盒模型的场景 - 部分老版本 Safari 对
*::before, *::after的匹配有 bug，可拆成两行分别声明以保兼容
哪些地方必须手动覆盖回 content-box
不是所有元素都适合 border-box。最典型的是 input[type="search"] 和某些 WebKit 内核下的 input[type="number"]，它们的默认内边距和边框在 border-box 下会挤压内容区，导致光标错位或文字截断。
还有 SVG 中的 text 元素、Canvas 导出的图片容器，以及用 transform: scale() 做缩放适配的模块——这些地方的尺寸计算逻辑与盒模型强耦合，硬套 border-box 反而增加调试成本。
- 常见需重置的元素：
input,textarea,select,button,svg text - 建议集中写在一个重置块里，避免散落在各组件样式中：
input, textarea, select, button { box-sizing: content-box; } - 不要只测 Chrome，务必在 Safari 和 Firefox 下验证表单控件的光标位置和文字溢出表现
PostCSS 插件能省事，但别让它替你思考
像 postcss-normalize 或 postcss-preset-env 确实能自动注入 box-sizing 规则，但它们默认策略往往过于激进——比如无差别给所有元素加 border-box，连 img 和 iframe 都不放过。
这类插件适合新项目起步阶段快速对齐基础样式，但一旦进入中后期迭代，就必须关掉相关规则，转为手动维护。否则某天发现某个弹窗里的 iframe 高度异常，排查起来要翻好几层构建配置。
- 启用前先读插件文档里关于
box-sizing的具体行为说明，有些插件提供exclude选项 - 构建产物里搜
box-sizing，确认生成的 CSS 是否包含你没写过的规则 - CI 流程中加入视觉回归测试（如 Chromatic），能提前暴露因盒模型变更引发的布局偏移
事情说清了就结束。真正的难点不在怎么写那行 CSS，而在判断哪些元素该被“规范”，哪些该被“放过”。这得看具体组件的渲染逻辑，而不是靠一个通配符一锤定音。
