textarea盒尺寸失控主因是未禁用resize: both且未设box-sizing: border-box；必须显式声明resize: none和box-sizing: border-box，否则padding会破坏布局。
textarea 的盒尺寸在加 padding 后“失控”，根本不是样式写错了，而是没关掉它的默认行为——resize: both 和没设 box-sizing: border-box 共同导致的。
必须先关掉 resize 才能谈尺寸控制
textarea 默认右下角可拖拽，这个 resize: both 不只是交互开关，它会隐式影响渲染盒的最小尺寸计算。尤其当设置了 min-width 或容器宽度受限时，浏览器会优先保障拖拽区域可用空间，把内容区往里压缩，导致你写的 padding: 12px 看起来“被吃掉”了。
- 统一禁用：
textarea { resize: none; }（推荐加在全局重置里） - 如果需保留水平缩放，只开横向：
resize: horizontal;，但垂直方向仍会干扰高度计算 - 禁用后，
width/height+padding才真正可预期
box-sizing: border-box 不是可选项，是前提
哪怕你写了 * { box-sizing: border-box }，textarea 在 Safari、旧版 Chrome、多数安卓 WebView 中依然按 content-box 渲染——它的 UA 样式逻辑独立，不继承通配符重置。
- 必须显式声明：
textarea { box-sizing: border-box; } - 否则
width: 100%; padding: 12px;实际占位 = 容器宽 + 24px，直接撑破父容器 -
getBoundingClientRect().width返回值会比 CSS 声明的width大2 * padding + 2 * border-width，这是 content-box 的必然结果，不是 bug
padding 值选型直接影响文字对齐与响应性
textarea 是文本密集型控件，padding 不只是留白，还决定光标位置、行首缩进、多行文字视觉节奏。用错单位或顺序，第一眼看不出问题，但换字体、缩放、换设备就露馅。
- 避免百分比：
padding: 5% 8%以包含块宽度为基准，垂直方向留白会随屏幕变宽而变大，文字行距失衡 - 慎用
em：padding: 0.75em 1em继承父元素font-size，嵌套深了容易失控；若textarea自身设了font-size: 14px，em却不按它算 - 推荐像素值：
padding: 12px 16px，稳定、直观、易调试；移动端可配合min-height防缩放裁剪：min-height: 120px; - 简写顺序别乱：
padding: 12px 16px 8px是上/左右/下，不是“上右下”，漏掉左值会导致右侧 padding 被覆盖
第三方组件库常偷偷覆盖你的重置规则
像 Vant 的 .van-field__control、Ant Design 的 .ant-input-textarea 这类封装好的 textarea，往往用更具体选择器（如带 class + tag）覆盖你的全局 textarea 规则，导致 box-sizing 或 resize 失效。
- 检查 computed styles，确认最终生效的是哪条规则
- 提高权重：用
textarea.van-field__control { box-sizing: border-box !important; resize: none; } - 或改用属性选择器穿透：
textarea[placeholder] { ... }，避开 class 冲突 - 注意：加
!important是临时解法，长期应推动组件库暴露样式 hook
最易被忽略的一点：即使 box-sizing 和 resize 都设对了，textarea 的字体度量（ascent/descent）仍会让首行文字看起来“偏上”。这不是 padding 没起作用，而是行高未对齐——此时要搭配 line-height 或固定 height 微调，而不是继续加 padding-top。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
