不能；input 的 width: auto 会填满父容器而非包裹内容，需用 JavaScript 监听 input 事件，先设 width: auto 再读取 scrollWidth 动态设置宽度，并加 padding 缓冲。
input 元素的 width 能不能随内容自动变宽？
不能直接靠 width: auto 实现——浏览器默认把 <input type="text"> 当作替换元素，width: auto 表现为“填满父容器”，不是“包住文字”。想让它随输入内容伸缩，得绕开默认行为。
常见错误是写 width: fit-content 或 min-width: max-content，但这些在多数浏览器里对 input 无效（尤其 Chrome 和 Safari），因为规范没要求表单控件支持这些值。
- 用
size属性做粗略控制：比如<input size="10">表示显示宽度 ≈ 10 个字符，但它是固定像素换算，不响应内容长度变化 - 更靠谱的做法是监听
input事件，动态调整style.width，依据当前值的scrollWidth - 注意：中文、全角字符、emoji 的宽度和英文不同，
scrollWidth能真实反映渲染后所需宽度，比单纯数字符个数准得多
用 JavaScript 动态调整 input 宽度的最小可行方案
核心思路是让 input 的宽度始终等于其内部文字渲染所需宽度，再加一点 padding 缓冲。关键不是“设多宽”，而是“怎么测出当前该有多宽”。
下面这段代码能跑通，且兼容 Chrome/Firefox/Safari（Edge 同 Chrome）：
立即学习“前端免费学习笔记（深入）”；
<input type="text" id="autoInput">
<script>
const el = document.getElementById('autoInput');
el.addEventListener('input', () => {
el.style.width = 'auto'; // 先重置，避免缓存
el.style.width = (el.scrollWidth + 8) + 'px'; // +8 是左右 padding 总和
});
</script>
-
scrollWidth返回的是内容实际宽度（含不可见溢出部分），对单行input来说，就是文字撑开的真实宽度 - 必须先设
width: auto再读scrollWidth，否则旧宽度会干扰测量 - 别用
offsetWidth或clientWidth，它们返回的是元素自身盒模型尺寸，不是内容宽度 - 如果 input 有 border 或 box-sizing 不是
border-box，+8 这个偏移量要相应调整
为什么不用 contenteditable div 模拟？
有人会想：“干脆换成 <div contenteditable>，它天然支持 <code>width: fit-content”，但实际落地容易踩坑。
- 语义丢失：
form提交时不会收集contenteditable的值，需手动同步到隐藏input，增加复杂度 - 焦点和键盘行为差异大：比如
Enter默认换行，Tab可能跳出而非跳字段，需要额外拦截 - 移动端软键盘兼容性差：某些 Android 浏览器里，
contenteditable的光标定位、选中逻辑异常 - 样式重置成本高：要去掉默认 outline、user-select、white-space 等，稍不注意就出现换行或文字被截断
移动端适配和性能要注意什么？
在 iOS Safari 或安卓 WebView 里，scrollWidth 在某些 zoom 级别下可能不准；高频输入（比如连打）也可能导致宽度抖动。
- 加防抖：延迟 50ms 更新宽度，避免每按一次键都重绘，
setTimeout或requestAnimationFrame都可以 - 限制最小/最大宽度：比如
min-width: 60px; max-width: 300px;，防止空输入时缩太小，或长文本撑爆布局 - iOS 上如果用了
font-size: 16px以下，可能出现scrollWidth偏小，建议保持基础字号 ≥14px - 别在
input上同时用transform: scale()，会破坏scrollWidth测量结果
真正难的不是让宽度变，而是让“变”的过程不闪、不卡、不误判——尤其是中英文混排、输入法上屏瞬间、以及 resize 页面时的边界情况。这些细节没处理好，用户一眼就能感觉到“不对劲”。
