绝对定位下left与right同时设非auto值可触发拉伸，前提是：position为absolute/fixed、父容器提供有效包含块宽度、元素未声明width且left/right均非auto；此时width=包含块内容宽−left−right−左右border−左右padding。
因为 left 和 right 同时为非 auto 值时，浏览器会按定位尺寸计算规则推导出 width，前提是元素为 position: absolute 或 fixed，且父容器提供可计算的包含块宽度。
left + right 触发拉伸的必要条件
这不是“写了就生效”的魔法，而是有明确前提的计算行为：
-
position必须是absolute、fixed或已触发的sticky；relative下写left和right是“斗争”关系，只生效一个 - 父容器必须构成有效的包含块——通常需设
position: relative（或absolute/fixed），否则包含块退化为视口，而视口宽度虽明确，但若子元素有width: auto且内容极短，仍可能不显式拉伸 - 元素自身不能声明
width（包括width: 100%、width: fit-content等），否则会覆盖自动计算逻辑 -
left和right都不能是auto；任一为auto，该方向就不参与约束，拉伸失效
浏览器到底怎么算出 width？
当满足上述条件时，浏览器执行的是确定性尺寸计算：
宽度 = 包含块内容区宽度 − left 值 − right 值 − 左右 border-width − 左右 padding
注意：left 和 right 始终从边框外边缘起算，box-sizing 不影响这个减法过程，只影响最终内容区大小。
例如：left: 80px; right: 20px;，父容器内容宽为 1000px，左右 border 各 1px，padding 各 12px，则实际 width = 1000 − 80 − 20 − 2 − 24 = 874px。
为什么有时写了 left 和 right 却没拉伸？
常见卡点不在语法，而在上下文缺失：
- 父容器没设
position: relative→ 包含块变成body或视口，但若body没设宽高、内容又少，其宽度可能被压缩为最小内容宽，导致计算结果趋近于 0 - 元素自己写了
width: 100%→ 直接覆盖自动计算，且100%是相对于最近已定位祖先的内容宽；若祖先本身塌陷，100%就是 0 - 用了
transform（如translateX）→ 拉伸逻辑仍在，但旧版 Safari 可能因 transform 干扰包含块宽度估算，多算几像素，引发意外横向滚动条 - 在
flex或grid容器里直接套absolute子项 → 父容器主轴未约束尺寸（比如flex: 1但外层无宽高），导致包含块宽度不可解
inset 能替代 left/right 吗？
可以，但要看场景和兼容性：
-
inset: 0等价于top: 0; right: 0; bottom: 0; left: 0，语义更清晰，拉伸行为完全一致 -
inset: 10px 20px等价于top: 10px; right: 20px; bottom: 10px; left: 20px，水平拉伸宽度 = 包含块宽 − 40px − 边框 − 内边距 - Chrome 89+、Firefox 63+、Safari 14.1+ 支持；Safari 13 或 Edge 18− 用户量仍不可忽略，此时退回
left/right更稳妥 - 仍要遵守相同禁忌：不能和
width共存，父容器仍需提供包含块宽度
真正容易被忽略的不是怎么写 left: 0; right: 0;，而是父容器是否真的“有宽度”——它可能视觉上撑开了，但 CSS 计算中仍是 0；这种隐性塌陷，比语法错误更难排查。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
