flex-wrap必须设为wrap，否则子项强行挤在一行导致响应式失效；配合flex-direction: row使用，column下wrap无意义；移动端建议默认设置，并注意Safari兼容性及子项宽度触发条件。
Flexbox容器的flex-wrap属性为什么必须设为wrap
不设 flex-wrap: wrap 时，子项会强行挤在一行，超出视口也不换行，响应式就失效了。尤其在小屏下，内容被裁剪或出现横向滚动条，用户根本看不到完整布局。
实际用法中，flex-wrap 要和 flex-direction: row（默认值）配合使用；如果设成 column，再加 wrap 就没意义——列方向无法“换列”。
- 移动端优先开发时，建议默认写
flex-wrap: wrap，后续媒体查询里不用反复覆盖 - 某些旧版 Safari（iOS 9–10）对
flex-wrap: wrap-reverse支持不稳定，生产环境避免使用 - 当子项设置了固定宽度（如
width: 200px），wrap才真正触发换行；纯flex: 1且无最小宽度限制时，可能始终不折行
媒体查询中哪些断点值最实用且兼容性好
别迷信“标准断点”，实际项目里用设备逻辑比像素数字更可靠。主流框架（如 Bootstrap）的断点本质是经验沉淀，不是技术强制要求。
推荐三档起步，覆盖绝大多数场景：
立即学习“前端免费学习笔记（深入）”；
-
@media (max-width: 576px)：窄屏手机竖屏（iPhone SE、老安卓小屏），此时常切换为单列堆叠 + 增大内边距 -
@media (min-width: 577px) and (max-width: 992px)：平板横屏、折叠屏半展开、大屏手机横屏。适合两列布局，flex-direction: row保持，但调整flex-basis或子项数量 -
@media (min-width: 993px)：桌面端起点，可启用三列、侧边栏等复杂结构
注意：576px 和 992px 是整数，避开某些 Android WebView 对小数断点解析异常的问题；也避免用 768px——iPad 竖屏是 768px，但很多安卓平板也是这个分辨率，却未必是平板体验，容易误判。
flex-grow / flex-shrink / flex-basis 在不同屏幕下的行为差异
这三个属性组合决定子项如何“争抢”剩余空间，但在媒体查询中它们的权重会被重置，不是继承关系。也就是说，你在 @media 里不重新声明，就沿用默认值（flex: 0 1 auto），很可能和预期不符。
- 小屏下想让导航菜单收成汉堡按钮？别只靠
display: none，先设flex: 0 0 100%让它独占一行，再配合order调整视觉顺序 - 卡片列表从三列变两列时，若每张卡设
flex: 1 1 300px，在 600px 宽度下会因min-width冲突导致换行异常；改成flex: 1 1 calc(50% - 1rem)更可控 -
flex-shrink: 0在小屏下慎用——它会让元素拒绝缩小，可能直接撑破容器，引发溢出
为什么justify-content在媒体查询里经常要从space-between改成center
因为 justify-content: space-between 依赖“多个子项存在且有足够空间”才好看。一旦媒体查询把子项数量减少（比如隐藏侧边栏）、或容器变窄，两端子项会被拉到边缘，中间大片留白，视觉失衡。
这不是 bug，是设计逻辑使然。真实项目中常见处理方式：
- 在移动端断点里统一改用
justify-content: center，再配合align-items: flex-start控制垂直对齐 - 如果必须保留间距感，改用
gap配合justify-content: flex-start，更稳定且支持响应式单位（如gap: clamp(0.5rem, 2vw, 1rem)） - 某些 Flex 容器嵌套较深时，外层
justify-content可能被内层margin干扰，调试时优先检查是否意外设置了margin-left/right: auto
Flexbox 的响应式不是“一套代码适配所有”，而是分场景控制弹性行为。最容易被忽略的是：子项的 min-width 和容器的 padding 会实质性影响 flex-wrap 触发时机，调试时得一起看，不能只盯 flex 相关属性。
