textarea自动撑高需先设height='auto'再读scrollheight，否则ios safari和ie11计算错误；移动端需用-webkit-text-size-adjust:none防字体放大；可访问性缩放测试须覆盖os级、浏览器级及纯文本缩放三类场景。
textarea 自动撑高必须先设 style.height = 'auto'
不重置高度就直接读 scrollHeight，iOS Safari 和 IE11 会算错——旧 height 值会锁住计算逻辑，导致删文字不缩、粘贴后底部留白、光标跳动。每次 input 触发前必须加这句，否则 scrollHeight 返回的是“被压缩后的溢出高度”，不是真实内容所需高度。
常见错误写法：textarea.style.height = textarea.scrollHeight + 'px' 直接赋值；正确顺序是：
textarea.style.height = 'auto'- 等待渲染完成（iOS 用
requestAnimationFrame，IE11 可加setTimeout） - 再取
textarea.scrollHeight - 最后赋值
textarea.style.height
移动端字体放大失控要用 -webkit-text-size-adjust: none
在 iOS Safari 或部分 Android WebView 中，textarea 宽度设为 100% 后字体常异常变大，不是 CSS font-size 没生效，而是系统级文本缩放干预了渲染。仅对 textarea 单独加 -webkit-text-size-adjust: none 即可禁用该行为，且不影响其他元素的可访问性缩放。
注意：这个声明只作用于 WebKit 内核，无需加 !important，但必须写在 textarea 的直系样式里（不能只写在父容器上）。若用框架封装，需确保最终渲染的 textarea 元素确实命中该规则。
缩放测试必须覆盖三种场景：页面缩放、OS 文本缩放、纯文本缩放
可访问性要求不是“看起来没破”，而是用户在 200% 缩放下仍能完整编辑、不遮挡、不裁切。只测浏览器 Ctrl/Cmd++ 是不够的：
- Windows 设置中开启“更大文本”（125%–200%），观察
textarea是否因min-height固定像素而塌陷或溢出 - macOS 辅助功能里调大“文本大小”，验证
rem单位是否同步放大行高与 padding - 装 Chrome 扩展 “Text Zoom”，只放大文字，检查换行是否错乱、
resize: none是否仍生效
特别容易漏掉的是：viewport meta 缺失或含 user-scalable=no，这会让 OS 级缩放失效，直接违反 WCAG 1.4.4。
resize: none 不等于防缩放，只是禁拖拽手柄
加了 resize: none 还能缩放？大概率是样式没生效——可能是被框架 CSS 覆盖（如 Ant Design 的 textarea 被包在 div 里，你写的 rule 没命中）、或父容器 overflow: hidden 遮住了右下角控件（看起来不能拖，其实能）。用开发者工具看 computed 样式里的 resize 值是否真为 none。
更隐蔽的问题：移动端 Safari 不显示拖拽手柄，但长按+拖动仍可能触发缩放（系统级行为，CSS 无法拦截）。此时真正起作用的是 viewport 的 initial-scale 和 maximum-scale，而非 resize 属性。
最易被忽略的兼容点：没设 min-height 和 max-height 的 CSS，或者 JS 计算高度时用的 line-height、font-size 和实际渲染不一致——scrollHeight 依赖真实盒模型，差一个像素都会导致撑不开或撑过头。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
