优先用 CSS 控制 textarea 尺寸，设 width/height 而非 rows/cols；resize 生效需满足 overflow 允许且内容溢出；自适应高度须先设 height: auto 再读 scrollHeight，并清空内联样式防累积。
HTML 中怎么让 <textarea></textarea> 变大
直接设 rows 和 cols 最简单，但容易失效——尤其在响应式布局里。浏览器默认会按字符格算 cols，而 CSS 的 width/height 才真正控制尺寸。别混着用，优先用 CSS。
-
rows="10"是提示浏览器“大概显示 10 行”，实际高度仍受height、line-height、内边距影响 - 写
style="width: 100%; height: 200px;"比硬编码cols更可靠 - 如果父容器宽度变化（比如移动端），只靠
cols会撑破布局，必须加width: 100%
为什么加了 resize 属性还是拖不动
默认就能拖，但很多人忘了关掉 overflow: hidden 或写了 max-height 却没配 resize: both。拖拽依赖两个条件：样式允许 + 内容足够溢出。
- 确保没有
style="overflow: hidden"或overflow-x: hidden盖住了垂直滚动条区域 -
resize: vertical只允许上下拉；resize: both才能四向拖，但需配合overflow: auto - 如果内容很少，
resize不生效——它只在有滚动需求时才激活手柄
<textarea></textarea> 自适应高度的坑在哪
监听 input 事件 + 动态设 height 看似合理，但会闪、卡、跳动。根本原因是没等字体渲染完成就量高，或没清掉之前内联 height 导致累积。
- 别用
scrollHeight后立刻赋值style.height，先设height: auto触发重排，再读scrollHeight - 每次计算前要重置
style.height = ""，否则旧高度会干扰新测量 - 移动端 iOS Safari 对
scrollHeight计算偏保守，常少一行，可加padding-bottom: 1px补偿
用 <div contenteditable> 替代 <code><textarea></textarea> 值不值得
仅当你需要富文本、@ 提及、实时语法高亮时才考虑。纯文本输入框强行上 contenteditable 是给自己埋雷——光光光标丢失、换行行为不一致、表单提交取不到值就够折腾。
立即学习“前端免费学习笔记（深入）”；
<div contenteditable="true"> 默认不进表单序列化，得手动绑定 <code>formdata事件或额外同步到隐藏<input>- 回车键行为各浏览器不统一：有的插
<div>，有的插 <code><br>，解析文本时得统一清洗 - 移动端软键盘弹起后，
contenteditable元素经常失焦或定位错乱，<textarea></textarea>原生支持更好
实际项目里，95% 的“大输入框”需求，用带 CSS 尺寸和
resize 的 <textarea></textarea> 就够了。真要自适应，重点不是算法多巧，而是每次重设高度前清空内联样式、等渲染帧完成再读高——这点容易被忽略。
