uni-app详情页底部输入框不能直接用position:fixed，因微信小程序中会被tabBar等截断，H5端键盘弹出后位置异常；需监听键盘高度动态设置bottom值，并处理scroll-view滚动与输入框共存的细节问题。
uni-app 详情页底部输入框为什么不能直接用 position: fixed
因为微信小程序中，position: fixed 的 view 会被原生 tabBar、下拉刷新容器或导航栏截断，导致输入框在滚动时“消失”或位置错乱；H5 端虽能固定，但键盘弹出后常卡在屏幕中间，不随键盘上推。这不是样式没写对，而是渲染层隔离导致的跨端行为差异。
必须监听键盘高度变化并动态计算 bottom
核心是把输入框外层容器设为 position: fixed，再用 uni.onKeyboardHeightChange 实时更新其 bottom 值。注意：初始值必须是 '0px'（带单位），否则样式绑定失效；且需在页面 onHide 时调用 uni.offKeyboardHeightChange 防止内存泄漏。
-
onLoad中注册监听：uni.onKeyboardHeightChange((res) => { const sys = uni.getSystemInfoSync(); // 计算键盘真实高度（减去安全区和窗口偏移） const kbHeight = res.height - (sys.screenHeight - sys.windowHeight + sys.safeAreaInsets.bottom); this.bottom = `${kbHeight > 0 ? kbHeight : 0}px`; }); - 模板中绑定：
<view class="input-wrap" :style="{ bottom: bottom }"></view> - CSS 必须加
padding-bottom: env(safe-area-inset-bottom)，否则 iPhone 底部按钮被遮挡
textarea 自增高度 + 防止键盘收起需设 adjust-position="false"
默认 textarea 聚焦时会触发页面上推，但微博类详情页通常需要保持内容可见、仅输入框上浮。设 adjust-position="false" 可禁用自动上推，配合上面的 bottom 动态计算，实现“悬浮感”。同时，auto-height 属性可让 textarea 随内容撑高，但要注意最大高度限制（如 /deep/ .uni-textarea-wrapper { max-height: 180rpx; }）。
- 不要用
v-model直接绑定长文本后立即focus()，iOS 下可能触发两次键盘 - 发送按钮点击后，若需保持键盘打开，不要调用
uni.hideKeyboard() - Android 端
auto-height有时不生效，可 fallback 到手动监听input事件 +scrollHeight计算
scroll-view 滚动到底部与输入框共存时的冲突处理
详情页主体通常是 scroll-view，而输入框固定在底部。当新评论提交后，既要滚动到底部，又不能让输入框被顶出视口——此时不能依赖 scroll-into-view，它在频繁更新时极易失焦。应改用 scroll-top + 尺寸查询。
-
scroll-view必须设固定高度（如height: calc(100vh - 120rpx)），否则滚动无效 - 每次追加评论后，在
nextTick里用uni.createSelectorQuery().select('.comment-list').fields({ scrollHeight: true, clientHeight: true })获取真实尺寸 - 计算
scrollTop = scrollHeight - clientHeight，赋给scroll-top绑定的变量 - 如果输入框高度变化（如从单行变为三行），要重新触发一次滚动计算，否则底部留白
细节上最易忽略的是：键盘弹起后，scroll-view 的 clientHeight 实际变小了，但很多开发者仍用旧值计算 scrollTop，结果永远差一截。必须在键盘高度变化回调里，同步重算滚动位置。
