flex-basis 在 column 容器中“不生效”是正常行为，因其只作用于主轴（垂直方向），控制初始高度而非宽度；失效主因是父容器缺乏明确的高度约束。
flex-basis 在 column 容器里“不生效”是正常现象
不是 bug，是 CSS Flex 规范定义的行为：flex-basis 只在主轴方向上起作用。当 flex-direction: column 时，主轴是垂直方向，flex-basis 控制的是**高度**（即初始高度），而不是宽度。如果你给子项设了 flex-basis: 200px 却发现宽度没变，那是因为你在水平方向上误用了它——此时它试图设置的是“初始高度”，但容器可能没给足够高度空间，或者被其他样式覆盖。
- 检查父容器是否设置了明确的
height或min-height；没有高度约束时，flex-basis在 column 下无法触发拉伸或截断 -
flex-basis不等于width或height：它是弹性布局中“基础尺寸”的起点，后续仍受flex-grow/flex-shrink影响 - 常见误用：在
flex-col容器中给子项加w-64+flex-[0_0_200px]，结果宽度由w-64主导，flex-basis被忽略
flex-wrap: wrap 会彻底改变 flex-basis 的行为逻辑
一旦启用 flex-wrap: wrap（即 Tailwind 中的 flex-wrap 类），子项就不再被强制压缩进单行/单列；此时 flex-basis 的作用前提变成：“该子项是否在当前行/列中溢出”。如果没溢出，flex-basis 就只是个初始值，不会强制撑开空间。
-
flex-wrap: nowrap（默认）下，flex-basis更容易“显性生效”，因为浏览器必须在单行内分配空间 -
flex-wrap: wrap下，子项优先按自身内容宽高渲染，只有当总尺寸超过容器主轴长度时，才会根据flex-basis+flex-grow重新分配剩余空间 - 典型陷阱：在响应式卡片列表中加了
flex-col flex-wrap，期望每张卡高flex-basis: 300px，结果卡片高度参差不齐——其实是内容高度不同，且未设min-height或h-75等固定约束
为什么 Tailwind 的 flex-[0_0_auto] 类看起来“没反应”
Tailwind 的 flex-[0_0_auto] 是 flex: 0 0 auto 的缩写，它本身完全合法，但失效往往来自组合冲突：
- 和
w-full/h-full同时使用时，w-full会覆盖flex-basis的宽度控制权，尤其在 Safari 旧版本中更明显 - 在
flex-col容器中，flex-[0_0_auto]不影响宽度，只影响高度；若你还写了w-48，那宽度就由w-48决定 - 若父容器是
flex-1但没设min-height: 0，Safari 会阻止子项收缩，导致flex-basis: auto实际退化为内容高度，而非“自动适应剩余空间”
真正要检查的不是 flex-basis，而是容器的“主轴尺寸约束”
几乎所有 flex-basis 失效案例，根源都在父容器缺乏明确的主轴尺寸（width 或 height）。Flex 布局不会凭空创造空间，它只是分配已有空间。
- 对
flex-row：检查父容器是否有width、max-w-或w-类；没宽度，flex-basis就无从分配 - 对
flex-col：检查父容器是否有height、min-h-或h-类；常见坑是只设了flex-1却忘了父级也得有高度上下文（比如flex-col的祖先没设h-screen） - 动态内容场景下，用
min-w-0/min-h-0防止 Safari 对 flex 子项做隐式最小尺寸限制，否则flex-basis会被压制
flex-basis 写错，而是它依赖的整个尺寸链断裂——从根容器的 h-screen，到中间层的 flex-1，再到子项的 min-h-0，缺一不可。实机调试时，打开 Safari 开发者工具，逐层检查 computed height/width，比盯着类名更有用。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
