flex-basis不是比width优先，而是属于flex主轴分配的第一步入口值，width是通用盒模型属性，两者分属不同渲染阶段；flex-basis非auto时浏览器直接跳过width解析，仅flex-basis: auto时width才作为脆弱fallback参考。
flex-basis 不是“比 width 优先”，而是根本不在同一计算流程里
width 是通用盒模型属性，参与常规流布局；flex-basis 是 flex 布局主轴空间分配的**第一步入口值**，两者属于不同渲染阶段。浏览器一旦进入 flex 主轴尺寸计算（flex-basis → 剩余空间 → flex-grow/flex-shrink），就直接跳过 width 的解析——不是覆盖，是压根不读。
常见错误现象：width: 200px; 和 flex-basis: 150px; 同时存在，结果就是 150px；哪怕 width 写在后面、加了 !important，也无效。
只有当 flex-basis: auto（或未声明）时，浏览器才会尝试回退到 width（水平主轴）或 height（垂直主轴）作为 fallback，但这一步本身就很脆弱：
- 内容宽度（如长英文单词、图片原始尺寸）可能远超
width值 -
min-width: auto（flex 项目默认）会强制撑开到内容宽度 - 父容器未设宽高时，
width: 100%计算结果为 0px
flex-direction 改变时，flex-basis 管的是 height 还是 width？
它不管属性名，只看主轴方向：flex-direction: row（默认）时，flex-basis 控制水平尺寸，等效接管 width；flex-direction: column 时，主轴变为垂直，flex-basis 就接管 height，而 width 变成交叉轴约束，完全不参与 flex 分配。
典型踩坑场景：响应式中用媒体查询把 flex-direction 切成 column，但保留 flex-basis: 200px，结果元素被强制设为高度 200px，而父容器没设 height，内容被裁剪或溢出。
此时若想让水平宽度也被 flex 逻辑控制，得改用 flex-basis + align-self，或在外层再套一层 flex 容器。
为什么 flex: 0 0 200px 比 width: 200px 更可靠？
width: 200px 在 flex 容器里只是个弱 fallback，受内容、flex-shrink、父容器约束多重干扰；flex: 0 0 200px 是显式锁死三件事：flex-grow: 0（不拉伸）、flex-shrink: 0（不压缩）、flex-basis: 200px（起点尺寸）。这三者合起来才真正实现“固定尺寸不伸缩”。
其他常用组合：
-
flex: 0 1 200px→ 允许压缩，禁止拉伸，适合响应式收窄 -
flex: 1 1 200px→ 先按 200px 分配，再均分剩余空间（注意：200px 是起点，不是上限） -
flex: none→ 等价于flex: 0 0 auto，此时width才恢复为主控属性（但需注意 display 类型是否支持）
百分比 flex-basis（如 50%）在 Android WebView 4.4–5.1 中解析不准，建议优先用 px 或 vw。
JS 动态修改 width 为什么没反应？
因为 flex-basis 的计算发生在 layout 阶段早期，一旦确定，后续仅靠 JS 改 style.width 不会触发 flex 基准重算——除非整个 flex 容器重排（比如改 flex-direction、display，或父容器尺寸变化）。
调试时如果发现 width 改了但布局没变，第一反应不是检查 JS 是否执行成功，而是查 flex-basis 是否被显式设为非 auto 值，从而锁死了主轴起点。
真正容易被忽略的是：flex 布局中，width 不是控制尺寸的主动手段，而是被动 fallback；想稳定干预主轴行为，必须动 flex-basis 或完整的 flex 缩写。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
