rows="4"是最稳妥的默认高度起点，按行数计算更可靠，避免像素高度在高DPI或缩放下的截断问题，且兼容性更好。
textarea 默认高度设多少才不被用户吐槽
直接设 rows="4" 是最稳妥的起点，既不会太矮导致文字被截，也不至于一打开就占半屏。浏览器默认 rows="2"，但实际输入时连一行带换行的 sql（比如 select * from users where id = ?;）就容易撑出滚动条，用户第一眼会觉得“框太小了”。rows 比用 height 更可靠——它按行数算，不受字体、缩放、padding 影响，兼容性也更好。
常见错误：用 style="height: 100px;" 硬设像素高度，结果在高 DPI 屏或放大页面时文字被切掉；或者设 min-height 却没配 resize: vertical，用户想拉大却拖不动。
-
rows="4"覆盖大多数单语句查询场景 - 如果预设内容较长（如带注释的建表语句），可初始化时用 JS 计算行数再动态设
rows - 避免同时设
rows和height，CSS 高度会覆盖 HTML 属性，行为不可控
textarea 自适应高度的关键不是监听 input，而是 scrollHeight
靠 input 事件 + offsetHeight 对比来判断是否要撑开，容易漏掉粘贴、快捷键（Ctrl+V / Cmd+Enter）或右键粘贴的场景。真正稳的方式是每次内容变后读 scrollHeight，它反映的是内部内容真实所需高度。
典型坑：用 clientHeight 或 offsetHeight 做判断，这两个值包含 padding/border，且不随内容溢出变化；而 scrollHeight 只要内容变多就涨，哪怕还没触发滚动条。
- 监听
input和paste两个事件就够了，不用加keydown - 设
style.height = 'auto'再赋值scrollHeight + 'px'，防止动画抖动 - 加个
min-height: 100pxCSS，避免空内容时塌成一条线
固定高度 + 手动滚动 vs 自适应：什么时候该锁死高度
当 SQL 输入框嵌在 Modal 或紧凑布局里（比如侧边栏工具面板），自适应反而坏事——内容一多，整个界面被顶开、按钮移位、甚至触发外层滚动。这时候宁可用固定高度 + 显式滚动条，控制感更强。
关键区别在交互预期：DB 工具类应用（如 DBeaver Web 版）默认固定高，因用户习惯“写完再执行”，不指望实时看全貌；而低代码平台的查询组件常自适应，因用户边写边调参，需要一眼看到上下文。
- 固定高度推荐设
height: 160px（约 10 行），并确保overflow-y: auto - 禁用
resize: none，否则用户无法手动调整——很多人会拖一下试试 - 如果后端返回结果也挤在同一区域，固定高度能避免执行前后布局跳动
IE11 下 scrollHeight 失效？用 getBoundingClientRect() 回退
IE11 对空内容或含换行符的 textarea 计算 scrollHeight 常不准，尤其在 display: none 的 Tab 页里首次显示时。这时候得用 getBoundingClientRect().height 作为 fallback，它测的是渲染后的真实尺寸。
但别直接替换——现代浏览器下 getBoundingClientRect() 触发重排，频繁调用伤性能。只在检测到 IE11 且 scrollHeight ≤ clientHeight 时才启用。
- UA 判断用
navigator.userAgent.indexOf('Trident/') > -1就够，不用整套检测库 - 回退逻辑必须加防抖（
setTimeout延迟 50ms），否则连续输入会卡顿 - 测试重点：IE11 下粘贴多行 SQL 后，高度是否立即匹配，而不是点一下才更新
自适应高度最难的不是计算，是决定“什么时候不该自适应”——布局约束、协作编辑、移动端软键盘弹起，都会让 scrollHeight 算出来的东西变得毫无意义。
