bottom: 0 不贴底，主因是父元素存在 padding-bottom，因其对齐的是父 content box 底边；若需视觉贴底，应保持 bottom: 0 并配合 transform: translateY(正值) 补齐 padding，而非修改 bottom 值。
bottom: 0 不贴底，先看父元素有没有 padding-bottom
绝对定位元素设了 bottom: 0，却离父容器底边有空隙，大概率是父元素设置了 padding-bottom。因为 bottom: 0 对齐的是父元素的 content box 底边，不是整个盒模型的最底部。如果父元素有 padding-bottom: 20px，那子元素底边实际离父容器可视底边就有 20px 距离。
实操建议：
- 用浏览器开发者工具检查父元素 computed 样式，重点看
padding-bottom值 - 若需“视觉上贴到底部”，不要调大
bottom值（比如写成bottom: -20px），容易在响应式或缩放时错位 - 更稳的做法：保持
bottom: 0，再加transform: translateY(20px)（值等于父元素padding-bottom）
box-sizing: border-box 会影响 bottom 定位的计算基准吗
不影响。无论 box-sizing 是 content-box 还是 border-box，bottom: 0 的参考线始终是父元素 content box 的底边——它只和父元素的 padding、border 有关，和子元素自身的 box-sizing 无关。
但注意一个常见干扰点：如果父元素自己也用了 box-sizing: border-box，而你又给它设了 height 和 padding，那它的 content box 高度会变小，间接影响子元素可用的定位空间。这时候问题表现在“子元素被截断”或“bottom: 0 后还露出空白”，而不是定位不准。
立即学习“前端免费学习笔记（深入）”；
实操建议：
- 排查时优先确认父元素的
padding和border，而非子元素的box-sizing - 若父元素高度固定且含 padding，用
calc()显式控制子元素高度（如height: calc(100% - 40px)），比依赖bottom+top更可控
为什么加了 margin-bottom 反而让子元素离底更远
绝对定位元素虽然脱离文档流，但它自身的 margin-bottom 依然生效——只不过不是推其他元素，而是把整个盒模型往下“撑开”。也就是说，bottom: 0 对齐的是该元素的 border box 底边，而它的 margin-bottom 是从 border box 往下延伸的，所以最终内容离父底边的距离 = margin-bottom 值。
这跟普通流内元素的 margin 行为一致，只是效果更隐蔽。
实操建议：
- 绝对定位子元素慎用
margin-bottom；如需留空，改用padding-bottom或直接调整bottom值 - 若必须用 margin（比如兼容旧样式），记得在计算偏移时把它算进去，例如想离父底边 10px，且子元素有
margin-bottom: 5px，那就设bottom: 5px - 用
outline临时调试（outline: 1px solid red），能清晰看到 margin 区域是否意外参与定位
IE 和旧 Safari 下 bottom + height: auto 渲染不一致
当绝对定位元素同时声明 top: 10px 和 bottom: 10px，且没设 height，浏览器要反推高度。IE 和旧版 Safari（≤ iOS 12）对这个推算逻辑不同：有的按 parentHeight - top - bottom，有的忽略 bottom 直接按内容撑高，导致高度忽大忽小甚至折叠。
这不是 bug，是规范未强制规定 auto 高度在双 offset 下的行为。
实操建议：
- 避免同时用
top和bottom控制高度，除非明确需要弹性高度且已测试过目标环境 - 若需自适应高度，改用
inset（现代写法：inset: 10px auto 10px auto），但注意 Safari ≤ 15.6 不支持 - 兼容性要求高时，用 JS 获取父高后动态设
height，比纯 CSS 更可靠
真正卡住人的，往往不是 bottom: 0 写错了，而是父元素的 padding、border 或 transform 悄悄改写了定位上下文——尤其当多个 CSS 层叠在一起时，得一层层 inspect computed 值，不能只信 styles 面板里写的那几行。
