scroll-margin-bottom只在部分设备生效，因其仅对具备明确overflow-y和非零高度的可滚动容器内定位元素有效；失效主因包括父容器脱离文档流、未设min-height、第三方组件遮挡滚动上下文。
scroll-margin-bottom 为什么只在部分设备生效？
这个 CSS 属性是目前最轻量、最标准的解法，但它不是“写了就管用”。它依赖两个硬性前提：scroll-margin-bottom 只对**可滚动容器内的定位元素**起作用，且该容器必须有明确的 overflow-y: auto 或 scroll，同时高度不能是 height: 0 或未设限的 min-height。
常见失效场景包括：
- 父容器用了
position: fixed或transform，导致元素脱离文档流，getBoundingClientRect()坐标错乱 - 输入框被包裹在
display: flex; flex-direction: column的根容器里，但没设min-height: 100dvh（或降级为100vh），浏览器无法判断“可滚动区域”在哪 - 用了第三方 UI 框架（如 Vant、Naive UI）的弹层组件，其内部
overflow被重置或遮挡了原生滚动上下文
padding-bottom 动态调整比 height 更安全吗？
是的，而且必须用 padding-bottom，而不是 height 或 margin-bottom。因为：
-
height会破坏 flex 布局中flex: 1的伸缩逻辑，容易导致内容截断或空白溢出 -
margin-bottom不参与盒模型计算，无法撑开父容器高度，对滚动锚点无效 -
padding-bottom是唯一既能“视觉腾出空间”，又不影响子元素定位流、不触发重排（re-layout）的方式
实操建议：
- focus 时给最外层滚动容器加
style.paddingBottom = '240px'（iOS 实测常用值，Android 可试280px） - blur 时必须立刻清空，否则键盘收起后留白；别加
transition动画，会导致scrollIntoView错位 - 如果容器本身有
overflow: hidden，padding 不会生效——要确保它的父级能响应内边距变化
为什么不能监听 resize 事件来判断键盘状态？
因为软键盘弹出本质上不改变视口尺寸（window.innerWidth/window.innerHeight），它只是临时压缩了 visualViewport.height，而这个行为在不同平台差异极大：
- iOS Safari：基本不触发
resize，即使触发也延迟严重；visualViewport.height更新滞后且抖动 - Android Chrome：部分版本会触发，但时机不可控，且与键盘动画不同步
- 国产 WebView：行为五花八门，有的直接改
document.documentElement.clientHeight，有的完全静默
真正稳定可用的信号只有 focus 和 blur。配合 setTimeout(() => input.scrollIntoView({ behavior: 'smooth', block: 'nearest' }), 80) 才能避开动画竞态。
contenteditable 容器如何避免意外编辑行为？
把 contenteditable="true" 加到输入框父容器上，是为了让键盘“锚定”在容器而非单个 <textarea></textarea>。但这样会引入新问题：用户可能误触容器并开始编辑空白区域。
必须拦截默认行为：
- 给容器加
@onkeydown="HandleContainerKeyDown"（Blazor）或addEventListener('keydown', e => e.preventDefault())（JS） - 禁用粘贴：
@onpaste="e => e.preventDefault()"，否则 iOS 会允许在容器空白处粘贴文本 - CSS 补位：
user-select: none; -webkit-user-select: none;防止长按选中文本 - 确保
<textarea></textarea>仍是唯一可输入区域，所有 keydown 逻辑仍走它，容器只负责“保活焦点”
这个方案在 Blazor 移动端聊天场景中已验证有效，但要注意：它不适用于表单提交前需校验整个容器内容的场景——因为容器本身不可提交。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
