会，flex-basis 会覆盖 width；当 flex-basis 值不为 auto 时，它优先作为主轴初始尺寸，width 仅在 flex-basis: auto 或未声明时作回退依据。
flex-basis 会覆盖 width 吗？
会，但仅限于 flex-basis 值不为 auto 且大于内容自然宽度时。浏览器在计算 flex 项目主轴尺寸时，优先采用 flex-basis 作为基础值；width 只在 flex-basis: auto（默认）或未声明 flex-basis 时才被当作回退依据。
常见错误现象：width: 200px 写了却没生效，检查是否误加了 flex-basis: 150px —— 后者直接接管主轴尺寸计算，前者被忽略。
-
flex-basis: 100px+width: 200px→ 实际初始尺寸是100px -
flex-basis: auto+width: 200px→ 初始尺寸通常接近200px（仍受内容影响） -
flex-basis: 50px+ 内容撑开到220px→ 最终宽度是220px（flex-basis只是“起点”，不是“上限”）
为什么 flex-basis: auto 不等于 width？
flex-basis: auto 的行为是：先看元素内容尺寸，再 fallback 到 width 或 height（取决于 flex-direction），最后受限于 min-width/max-width。它不是简单地“读取 width 值”，而是参与一套内容感知的计算流程。
使用场景：当你希望 flex 项按文字/图片等实际内容自适应，又保留伸缩能力（比如配合 flex-grow: 1），就该用 flex-basis: auto，而不是硬写 width。
立即学习“前端免费学习笔记（深入）”；
- 纯文字容器设
width: 120px但内容超长 → 可能溢出或换行，不受 flex 调控 - 同容器设
flex-basis: auto→ 宽度随文字长度变化，之后再按flex-shrink压缩 - Safari 10 以下存在 bug：若只设
width和flex-shrink，可能错误地用height当作收缩基准 —— 这正是推荐统一用flex-basis的历史原因
flex-basis 和 width 在响应式中谁更可控？
flex-basis 更可控。因为它明确属于 flex 布局空间分配的第一步，和 flex-grow/flex-shrink 构成完整伸缩链；而 width 是静态盒模型属性，在 flex 容器中容易被绕过或产生歧义。
性能与兼容性影响：现代浏览器对 flex-basis 解析一致，但 IE11 对负值 flex-basis 不支持（视为无效，降级用 width）；width 虽兼容性好，但在 flex 场景下反而增加维护成本。
- 响应式断点中改
flex-basis: 100%→ 项目占满整行，flex-grow自动失效 - 同位置改
width: 100%→ 在 flex 容器中可能被压缩，行为不可预测 - 想限制最大宽度？用
max-width配合flex-basis，别依赖width——max-width会真正约束最终尺寸
什么时候必须同时用 width 和 flex-basis？
极少需要。只有两种真实场景值得破例：
一是内容溢出控制：flex-basis: 100px 设初始宽，width: 150px 作为软上限（配合 overflow: hidden 或 word-break: break-word 防英文撑开）；
二是跨布局复用样式：某 class 同时用于 flex 项和普通块元素，需兼顾两者，此时可写 width: 200px; flex-basis: 200px;，但要清楚在 flex 容器中只有后者起效。
容易踩的坑：以为 width 能“兜底”或“加强” flex-basis，结果发现它既不参与 flex 计算，又干扰 CSS 可维护性 —— 大多数情况下删掉 width 反而更干净。
