flex-basis会直接覆盖width的主轴尺寸计算，浏览器按flex-basis→width（仅当flex-basis为auto时）→min/max-width顺序决策；flex-direction切换时flex-basis动态适配主轴维度，width则无此能力。
flex-basis 会直接覆盖 width 的主轴尺寸计算
在 display: flex 容器中，flex-basis 不是“和 width 一起算”，而是**先于 width 参与主轴尺寸决策**。浏览器的计算顺序是：flex-basis → 若为 auto 或未声明，才 fallback 到 width（或 height，取决于 flex-direction）→ 最后受 min-width/max-width 限制。
常见错误现象：width: 200px 写了但没生效，十有八九是因为同时写了 flex-basis: 150px —— 后者已接管主轴起点，前者被跳过。
-
flex-basis: 100px; width: 300px;→ 实际初始主轴尺寸是100px -
flex-basis: auto; width: 300px;→ 初始尺寸≈300px，但仍可能被内容撑大（如长英文不换行） -
flex: 1;→ 等价于flex: 1 1 0，此时flex-basis: 0，width完全无效
flex-basis 的行为随 flex-direction 动态切换主轴维度
flex-basis 不固定作用于 width 或 height，它只管当前主轴。这导致响应式中容易踩坑：比如从 row 切到 column，却忘了 flex-basis: 200px 此时控制的是高度而非宽度。
典型问题：
-
flex-direction: row; flex-basis: 200px;→ 控制宽度 -
flex-direction: column; flex-basis: 200px;→ 控制高度，若父容器没设height，可能塌缩 - 媒体查询里改
flex-direction时，建议同步检查flex-basis单位是否合理（例如用vh或px更稳，%在垂直主轴下需父容器有明确高度）
flex-basis: auto 不等于读取 width 值
flex-basis: auto 是内容感知的 fallback 流程，不是简单取 width。它的实际行为是：先看内容固有尺寸（图片原始宽、文字自然宽度），再 fallback 到 width（水平主轴）或 height（垂直主轴），最后受限于 min-width/max-width。
这意味着：
-
width: 150px; flex-basis: auto;+ 纯文字“好” → 实际宽度可能只有 24px，不是 150px -
flex-basis: 150px;+ 空内容 → 强制占 150px，哪怕内容为空 - Safari 10 以下存在 bug：仅设
width和flex-shrink时，可能错误地用height当收缩基准 —— 这正是推荐统一用flex-basis的历史原因
响应式断点中改 flex-basis 比改 width 更可预测
在媒体查询里切换尺寸时，flex-basis 直接进入 flex 布局的再分配流程；而 width 是静态值，在 flex 容器中可能被 flex-shrink 压缩、被内容撑开、甚至在旧 WebView 中解析异常。
对比示例：
-
@media (max-width: 768px) { .item { flex-basis: 100%; } }→ 项目占满整行，flex-grow自动失效，行为确定 -
@media (max-width: 768px) { .item { width: 100%; } }→ 若父容器flex-wrap: wrap且空间不足，该元素仍可能被压缩，结果不可预期 - Android 4.4–5.1 WebView 对
flex-basis: 50%解析不准，但对flex-basis: 120px或flex-basis: 25vw支持稳定
真正关键的不是“哪个更强大”，而是 flex-basis 天然嵌入 flex 的空间分配链条 —— 入场、伸缩、断点重排，每一步都可推演；width 在 flex 场景里只是个容易被绕过的遗留接口。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
