width: 100% 溢出主因是 box-sizing 默认为 content-box、父容器无 max-width 或子元素含固定 padding/border；须全局设 box-sizing: border-box，禁用 html/body 固定宽，断点按内容断裂而非设备尺寸，混用 vw/% 导致缩放不一致，应统一用 rem+clamp() 和 %，小屏点击区域用伪元素扩展。
为什么 width: 100% 还是会溢出或错位
常见错觉是“用了百分比就自适应了”，但实际中容器父级没设 max-width、子元素含固定宽（如 padding: 20px 或 border: 1px solid）或未重置 box-sizing，都会导致计算偏差。尤其在小屏上，100% + 20px padding 就直接撑破视口。
必须统一加：
*, *::before, *::after {
box-sizing: border-box;
}
否则所有百分比宽度都不可靠。另外，避免对 html 或 body 设固定 width 或 min-width，它们会锁死缩放行为。
媒体查询断点该按设备写还是按内容写
按设备（如 @media (max-width: 768px)）容易过时——iPad 竖屏是 768px，但很多安卓平板横屏也接近这个值；更可靠的是按内容断裂点来设：导航栏换行了？卡片从三列挤成两列？文字开始换行太碎？这时才是真正的断点。
立即学习“前端免费学习笔记（深入）”；
推荐用以下三档渐进式断点（单位全用 em，适配字体缩放）：
-
@media (max-width: 40em)—— 小屏（约 640px），收起导航，堆叠卡片 -
@media (min-width: 40.0625em) and (max-width: 64em)—— 中屏（641–1024px），双列布局，保留部分横向空间 -
@media (min-width: 64.0625em)—— 大屏，三列或完整导航栏
注意：断点之间留 0.0625em 间隙，防止某些浏览器因浮点精度把两个媒体查询同时命中。
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
vw 和 % 混用时字体和间距为啥忽大忽小
vw 是视口宽度的百分比，随窗口拖拽实时变化；% 是父容器宽度的百分比，只在父级重排时响应。混用会导致字号用 2.5vw、行高用 1.5em、边距用 2%——三者基准不同，缩放节奏不一致，视觉跳变明显。
统一方案：字体用 rem + 根字体动态调整，间距/容器用 % 或 clamp()。例如：
:root {
font-size: clamp(1rem, 4vw, 1.25rem);
}
h1 { font-size: 1.5rem; margin-bottom: 1.2rem; }
.card { width: 90%; max-width: 1200px; margin: 0 auto; }
这样字体有上下限，容器始终占满可用宽度又不撑爆大屏。
移动端点击区域太小，media query 里怎么补救
单纯放大元素会破坏布局流，正确做法是在小屏下提升交互容错率：增大点击热区，但不改变视觉尺寸。用 ::before 伪元素扩展可点击范围：
@media (max-width: 40em) {
.btn {
position: relative;
}
.btn::before {
content: '';
position: absolute;
top: -10px;
right: -10px;
bottom: -10px;
left: -10px;
z-index: -1;
}
}
这样按钮视觉大小不变，但点击区域向外延展 10px，符合移动端至少 44×44px 的触控建议。别忘了给 .btn 加 touch-action: manipulation 减少 300ms 延迟。
真正难的不是写多少媒体查询，而是每次改布局前先问：这个组件在 320px 宽度下，用户手指能不能稳稳点中它？
