底部固定评论输入框需协同解决三件事：动态监听键盘高度并计算bottom值、每次点击重置focus状态、用独立scroll-view隔离评论区域滚动。
直接说结论：底部固定评论输入框在 uni-app 里不是“加个 position: fixed 就完事”，核心矛盾是「软键盘弹起时输入框被顶起、滚动错位、iOS 定位漂移、安卓聚焦失效」——这些必须靠三件事协同解决：动态 bottom 值监听、focus 状态重置、scroll-view 高度隔离。
uni.onKeyboardHeightChange 监听键盘高度并动态计算 bottom
不能只写 bottom: 0 或硬编码 bottom: 200rpx，键盘高度在不同机型、横竖屏、系统版本下差异极大（尤其 iOS 的安全区 + 键盘高度叠加逻辑）。必须用官方 API 实时响应：
-
uni.onKeyboardHeightChange是唯一可靠方式，uni.getSystemInfoSync().windowHeight在键盘弹出后已滞后，不可用于计算 - 监听回调中拿到的
res.height是键盘实际高度（单位 px），但需注意：它不包含状态栏/安全区，所以最终bottom应设为res.height + safeAreaInsets.bottom（iOS）或仅res.height（Android） - 务必在
onHide中调用uni.offKeyboardHeightChange，否则页面卸载后监听器仍存在，造成内存泄漏和跨页干扰 - 初始
bottom值建议设为'0px'，避免首次渲染时输入框遮挡内容
:focus="isFocused" 必须每次点击都重置为 false 再 true
这是“只能聚焦一次”的根本原因：Vue 的 v-model 绑定和 :focus 属性是响应式驱动，但 true → true 不触发更新。不重置就永远卡住：
- 点击评论图标时，先执行
this.isFocused = false，再this.$nextTick(() => { this.isFocused = true }) - 不能省略
$nextTick：否则 DOM 还没更新，focus属性变更无效，尤其在 H5 和部分小程序平台 - 如果用了
u-input或其他封装组件，确认其内部是否透传focusprop；有些组件会忽略连续的false → true切换，需额外调用ref.focus() - 提交评论后，要主动调用
uni.hideKeyboard()，否则键盘残留，下次点击图标可能无法唤醒
评论列表必须用独立 scroll-view，禁用父容器滚动
把整个页面包进 scroll-view 是灾难源头：评论动态增加时，内容高度变化会触发父级滚动条重算，导致 iOS 上「滚动跳动」「定位偏移」「最新评论看不见」：
- 评论区域单独套一层
<scroll-view scroll-y class="comment-list">，并设置固定高度（如height: 400rpx），不要用100%或flex: 1 - 父级容器（如页面根
view）必须移除scroll-y，改用overflow: hidden或明确禁止滚动 - 滚动到底部不能依赖
scroll-into-view：安卓上常失效，iOS 上定位不准。应手动计算：this.commentScrollTop = this.totalCommentHeight - this.visibleHeight，再赋值给scroll-top - 新增评论后，必须等 DOM 渲染完成再滚动，用
this.$nextTick(() => { this.scrollToBottom() })，否则高度取值为旧值
iPhone X 及以上机型的安全区适配不能只靠 env()
env(safe-area-inset-bottom) 在微信小程序基础库 2.27.0+ 才稳定支持，低版本会 fallback 为 0，导致输入框被刘海/圆角遮挡：
- CSS 中同时写两行：
padding-bottom: constant(safe-area-inset-bottom)和padding-bottom: env(safe-area-inset-bottom)，前者兼容老版 iOS - JS 层也要兜底：在
onLoad中调用uni.getSystemInfoSync()获取safeAreaInsets.bottom，作为bottom的最小偏移基准 - 不要把输入框直接放在
position: fixed容器内还加transform或scale，这会破坏键盘联动逻辑，尤其在 iOS 微信中 - H5 端无键盘事件，需用
document.activeElement?.blur()手动收起键盘，uni.hideKeyboard()对浏览器无效
最易被忽略的是：评论列表的 scroll-view 高度必须「固定」且「可预测」，不能随内容撑开——否则它和底部输入框之间会产生不可控的间隙或重叠，这个细节在原型阶段看不出问题，上线后大量用户反馈「点评论没反应」，其实只是输入框被挤出了可视区。
