Flex圣杯布局不用float或position因order能重排视觉顺序而不破坏语义流，避免BFC塌陷、脱离文档流等问题，兼顾响应式、无障碍与打印样式。
Flex圣杯布局为什么不用float或position
因为order能直接重排DOM视觉顺序，不破坏语义流，也不用靠负margin或z-index硬调位置。float会触发BFC导致父容器塌陷，absolute会让元素脱离文档流——这两者在响应式切换、无障碍阅读、打印样式里都容易出问题。
常见错误现象：header在DOM里写在main前面，但用float: right把侧边栏“挤”到右边后，屏幕阅读器仍按源顺序读，造成逻辑错乱。
- 使用场景：三栏PC端（左栏导航、中栏内容、右栏广告/推荐），且要求HTML结构保持语义优先（如
main在中间写） -
order值越小越靠前，但只影响视觉顺序，不影响tab键焦点顺序——如果要同步，得额外加tabindex - 兼容性：IE10+支持
flex和order，但IE10不支持order在flex-wrap: wrap下的多行行为，建议设flex-wrap: nowrap
order属性怎么配合flex-direction控制三栏顺序
关键不是死记数值，而是理解“主轴方向”和“order作用域”。默认flex-direction: row，主轴从左到右，order就决定元素从左往右的排列次序。
示例：HTML中按header→aside→main→footer书写，但想实现圣杯（aside左、main中、aside右），就得让main视觉上居中：
立即学习“前端免费学习笔记（深入）”；
main { order: 2; }
aside:nth-of-type(1) { order: 1; } /* 左栏 */
aside:nth-of-type(2) { order: 3; } /* 右栏 */注意：order默认是0，所有没设的元素都在main之前显示，所以必须显式设main为2，否则它会被压到最右。
- 如果改用
flex-direction: column（比如移动端竖排三栏），order就控制从上到下的顺序，此时圣杯结构就失效了——别硬套，该用flex-wrap或媒体查询切布局 -
order不能跨flex容器生效，父子级flex嵌套时，子容器的order只在父容器内起作用
为什么圣杯布局的container必须设min-height: 100vh
因为Flex容器默认不撑高，当main内容少时，footer会塌到页面顶部，看起来像没生效。这不是order的问题，是高度计算逻辑被忽略。
错误写法：.container { display: flex; flex-direction: column; } —— 没设高度，子项flex: 1也无处可伸展。
- 必须加
min-height: 100vh（不是height: 100vh，否则内容超长时会遮挡footer） - 若容器外还有固定header，需用
calc(100vh - 60px)，但注意Safari对calc内单位空格敏感，写成calc(100vh-60px)更稳 - 某些安卓WebView里
100vh会把地址栏高度算进去，导致滚动条，这时改用100dvh（Chrome 105+/Safari 16.4+支持）
order带来的tabindex和SEO隐性风险
order只改视觉顺序，不改DOM顺序，所以键盘用户按Tab键仍按HTML书写顺序跳转，可能先聚焦到右栏再跳回左栏，体验割裂。搜索引擎也按源码顺序判断内容主次。
常见错误现象：用order把main视觉置中后，SEO工具仍把第一个aside标为“主要内容”，排名权重被稀释。
- 解决tab顺序：给每个可聚焦元素手动加
tabindex，例如<main tabindex="2"></main>，但别滥用，tabindex="0"以外的值会破坏自然流 - SEO层面无法靠CSS修复，只能接受——圣杯布局本质是视觉妥协，重要内容仍应放在HTML靠前位置；如果
main必须语义优先，就老老实实写在DOM第一，用order: 0保持原位 - 测试方法：关掉CSS，看纯文本是否仍符合信息层级；用Chrome DevTools的“Rendering > Emulate vision deficiencies”检查阅读顺序
真正难的不是写对order，是判断什么时候不该用它——比如后台管理页有固定侧边栏，用position: sticky比Flex圣杯更轻量，也绕开了所有顺序陷阱。
