bottom: 0始终相对于父元素content box底边计算，而非padding box；父元素若有padding-bottom，则子元素底边距可视底部留空，典型表现为“悬空”；可靠解法是隔离padding（如用wrapper）或改用flex布局。
bottom值为什么不是从父容器padding-bottom开始算？
因为bottom是相对于定位上下文的content box边缘计算的，不是padding box或border box。即使父容器有padding-bottom: 20px，bottom: 0仍会把元素底边对齐到内容区底部——也就是离父容器可视底边还有20px空隙。
父容器padding导致absolute元素“悬空”的典型现象
常见于导航栏、卡片遮罩、全屏弹层等场景：元素设置了bottom: 0，但实际没贴到底，下方留白；用开发者工具检查发现父容器确有padding，而子元素的layout框停在了content box边界处。
- 临时移除父容器
padding，bottom: 0立刻生效——这是最快速验证方式 - 若必须保留padding，不能靠调
bottom硬凑像素值（响应式下会失效） - 用
calc()补差（如bottom: calc(0px + 20px)）只适用于固定padding，不推荐
真正可靠的解法：换参考系，而不是调数值
与其让bottom去适应padding，不如让定位上下文本身“不带padding干扰”：
- 给父容器加
box-sizing: border-box（通常已有，确认即可） - 把padding挪到一个内部wrapper上，让absolute子元素的定位上下文（即父容器）纯content box
- 或者改用
flex布局：父容器设display: flex; flex-direction: column;，子元素用margin-top: auto推到底部——完全绕过定位与padding的耦合
为什么top/bottom双向拉伸时padding干扰更隐蔽？
当同时写top: 0; bottom: 0;想撑满父容器时，如果父容器有padding，元素确实会填满整个content box，但内容区域会被padding“挤窄”，且文字/子元素可能被裁剪。此时overflow: hidden容易掩盖问题，而overflow: auto又会意外出现滚动条。
立即学习“前端免费学习笔记（深入）”；
关键点在于：绝对定位不自动感知padding，也不提供“避开padding”的语义。它只认content box四条边。这个限制在复杂嵌套和响应式缩放中会突然暴露——比如手机端padding按vw设置，但bottom: 0仍固执地对齐到动态变化的content box底部。
