shadow dom 不改变 css3 盒模型行为，仅创建样式作用域边界；盒模型仍由 box-sizing、width、padding 等控制，内部元素默认 content-box，:host 与普通元素规则一致，封装性依赖开发者主动约束而非自动优化。
直接说结论：Shadow DOM 本身不改变 CSS3 盒模型行为，它只是创建了一个样式作用域边界；盒模型仍由 box-sizing、width、padding 等常规属性控制，但封装性提升的关键在于「隔离」而非「重定义」。
Shadow DOM 的盒模型和普通 DOM 完全一致
Shadow DOM 容器（如通过 element.attachShadow({mode: 'open'}) 创建）内部的元素，其盒模型计算方式与普通 HTML 元素完全相同：默认是 box-sizing: content-box，width 只含 content，padding 和 border 额外增加尺寸。不存在所谓“Shadow专属盒模型”。
常见误解是认为 Shadow DOM 自动启用 border-box 或重写了尺寸逻辑 —— 实际上它只隔离了样式作用域，不干预渲染引擎对盒模型的解析。
- 你在 Shadow DOM 内写
.item { width: 200px; padding: 16px; }，最终占用宽度仍是232px（除非显式设box-sizing: border-box） -
:host伪类选中的宿主元素，其盒模型也遵循同样规则；它的width是对外暴露的尺寸，不受内部 Shadow 内容影响 - 父级样式无法穿透到 Shadow 内部（除非用
::slotted或/deep/已废弃），但盒模型计算完全自治
封装性优化真正依赖的三个盒模型实践点
提升 Web 组件封装性，不是靠 Shadow DOM “自动优化盒模型”，而是靠开发者在 Shadow 内部主动约束盒行为，让组件尺寸可预测、不泄漏、易组合。
- 统一设
:host, :host * { box-sizing: border-box; }：避免子元素意外撑开容器，尤其当组件接受用户传入的任意 HTML 片段时 - 用
:host控制对外接口尺寸：例如:host { display: block; width: 100%; min-width: 0; }，配合min-width: 0防止 flex 容器中溢出破坏布局 - 慎用
margin在:host上：外部调用者可能已对其设置 margin，叠加会导致间距失控；推荐用padding或通过 slot 分配留白
容易被忽略的盒模型“越界”场景
即便用了 Shadow DOM，盒模型相关问题仍会从缝隙中漏出，主要发生在边界交互处：
-
slot内容若带display: block且无box-sizing，其padding会撑大组件高度，而:host无法重置其盒模型 —— 必须在 slot 样式层或文档流上游统一规范 -
:host-context(...)匹配外部环境时，若外部设置了font-size或line-height，会影响内部em/ex单位的盒尺寸，导致响应错位 - 使用
ResizeObserver监听:host尺寸时，获取的是包含border和padding的contentRect，但若内部元素用了box-sizing: content-box，实际内容区可能更小，造成测量与渲染偏差
真正难的不是写对一个 box-sizing，而是确保从宿主、slot、子组件到文本节点，所有层级的盒模型行为在隔离环境下仍保持语义一致 —— 这需要设计阶段就约定单位体系（推荐 px 或 rem）、约束 box-sizing 传播链，并在测试中验证极端内容注入下的尺寸稳定性。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
