根本原因是width: 100%在content-box下叠加padding/border导致溢出；需统一box-sizing: border-box，特别加固textarea及处理100vw、滚动条宽度、flex min-width等组合效应。
根本原因不是 padding 本身，而是 width: 100% 默认按 content-box 计算，padding 和 border 会额外叠加在 width 之外，导致总宽度超过父容器内容区 —— 浏览器只能拉宽并强制触发横向滚动条。
box-sizing: content-box 是罪魁祸首
CSS 默认盒模型是 content-box：当你写 width: 100%，它只管内容区；padding: 12px 和 border: 1px 会额外加在两边，总宽度 = 父内容宽 + 24px + 2px。哪怕父容器刚好是视口宽，子元素也必然溢出。
- 用 DevTools 查看该元素的
Computed→width值，再对比scrollWidth，差值就是 padding+border 的“账外支出” -
* { box-sizing: border-box }能覆盖绝大多数元素，但对伪元素（::before/::after）默认无效 - uni-app、微信小程序里部分原生组件（如
textarea）可能绕过该规则，需单独加固
textarea 是高频翻车现场
textarea 默认 box-sizing: content-box，且在移动端 WebView 或小程序中还自带不可覆盖的内边距偏移（约 2–4px），叠加用户写的 padding 后极易突破边界。
- 必须显式写
textarea { box-sizing: border-box; width: 100%; padding: 12px; } - 若仍溢出，尝试
width: calc(100% - 8px)预留原生内边距余量 - 避免给
textarea的父容器设padding，改用margin推开间距，防止嵌套叠加
别信“父容器没 padding 就安全”
即使父容器没设 padding，只要它自身用了 100vw 或存在垂直滚动条，就可能间接引发横向溢出：
立即学习“前端免费学习笔记（深入）”；
-
100vw包含滚动条宽度（Windows 下常为 17px），而document.documentElement.clientWidth不包含 —— 导致100vw > 可视宽度 - 浮动布局中，父容器若未清除浮动（
overflow: hidden或display: flow-root），高度坍塌后 body 可能被撑开，间接扩大计算基准 - flex 容器中
textarea若未设display: block，其 inline-level 行为会导致width: 100%计算失准
真正难处理的从来不是单个属性，而是 100vw、滚动条宽度、原生组件内建 padding、以及 flex 默认 min-width: auto 这几者在不同环境下的组合效应。每次遇到横向滚动，先执行 $$('*').forEach(el => el.style.outline = '1px solid red') 快速定位“凸出来”的元素，比反复改 overflow 有效得多。
