正文
某次修改一个页面的逻辑，页面布局比较简答，整个页面 overflow-y: auto;，页面的底部放置一个 position: fixed;的固定按钮，如下：
为了避免页面主体内容被底部的固定按钮遮挡，页面使用了一个 padding-bottom 的样式属性，大概关键布局代码和样式代码是这么写的：
<body>
<div class="main">...</div>
<div class="footer">这是固定在底部的按钮</div>
</body>
:root {
--footer-height: 50px;
}
.main {
padding-bottom: var(--footer-height);
overflow-y: auto;
}
.footer {
position: fixed;
bottom: 0;
width: 100%;
height: var(--footer-height);
}
然后我需要加一个A逻辑，当满足我这个 A逻辑的时候，底部固定按钮就不展示了，其他情况则展示
这么一来样式布局就变化了，如果符合我加的A逻辑，那么 .main的 padding-bottom 属性就得删掉了，所以我还得额外再加样式的逻辑
加这个额外的样式逻辑倒是没问题，但实际上这本来是没必要的，况且在页面业务逻辑比较复杂、测试覆盖不够全面的时候，再加上如果这个页面大部分逻辑都不是你写的，那么是很容易遗忘这一点的
一般而言，在一个项目中，为了起到复用组件的目的，底部固定按钮作为一个明显存在固定UI规范、明显可以被复用的组件，都是会被设计为通用组件的，通用组件是为了配合主体业务页面的，如果变成反过来，我为了使用你这个通用组件还得专门在主体业务页面里写额外的判断样式逻辑，那说明这个通用组件是不够通用的
我希望在使用这个底部固定按钮的时候，这个组件不应该影响到我主体页面的其他部分，例如整体的样式布局，但是实际上，针对底部固定按钮这个具体组件而言，我发现很多人都是这么设计组件的
如果换做是我来做这个组件，我会这么写：
<body>
<div class="main">...</div>
<div class="footer">
<div class="footer-content">这是固定在底部的按钮</div>
</div>
</body>
:root {
--footer-height: 50px;
}
.main {
overflow-y: auto;
}
.footer {
height: var(--footer-height);
}
.footer-content {
position: fixed;
bottom: 0;
width: 100%;
height: var(--footer-height);
}
根本不需要 .main 元素专门写一个 padding-bottom来配合底部固定按钮组件，因为组件自己会撑开高度
相比于文章开头的那种写法，我后面的写法，是多套了一层元素，这多出来的一层元素并不设置 position: fixed;，是一个位于文档流中占据实际空间的元素，且其高度与其子元素相同，其子元素才是真正有展示效果的且 fixed 固定的元素，即父元素负责撑开高度，子元素负责底部固定展示
这种方法的缺点在于，因为底部固定子元素是 position: fixed;，所以无法撑开高度，必须要确定底部固定的子元素高度才能设置父元素的高度
但一般来说这并不算是个问题，底部固定元素基本上都是以按钮的形式出现，而底部固定按钮这种通用组件，一般而言其尺寸、圆角、字号大小都是固定的，无非是颜色和文案可能需要换一换，总之高度大概率是可以提前确定的是不会变的，直接硬编码一个高度就完事
如果真的是存在高度需要变化，那么也不是问题，无非是即时测量一下罢了
当然，这个方法不仅是针对于底部固定元素，顶部固定元素也是同样的道理
小结
第二种方法的小技巧其实是我很久之前的一个个人思考的结果（当然你可能也想到了），当时我和大多数人一样，都习惯使用 padding-bottom来维持主体页面和底部固定按钮的关系，但有一次我觉得总是写 padding-bottom 很烦，而且觉得这不合理，所以思考了一下如何将其变得更好，于是我就多会了一个小技巧
写业务代码也是需要有思考的，业务代码没有什么技术上的难度，思考的是如何保证代码项目的可维护性，技术的选型、组件的设计、结构的解耦等都是可思考的方向，这些东西可能很难在绩效上体现出来，但最起码自己写起来更舒服了不是吗？
