display: none 会彻底移出 flex 布局流，order 失效；visibility: hidden 配合 order 可隐藏但保留排序锚点；display: contents 则透传子元素参与布局，原元素 order 被忽略。
display: none 会彻底移出 flex 布局流，order 失效
这是最常踩的坑：以为给弹性项加 display: none 后，它只是“看不见”，order 还能影响其他项的排列顺序——其实不会。display: none 的元素完全不参与 flex 布局计算，包括 order、flex-grow、甚至容器的 justify-content 对齐都会绕过它。此时改 order 对它本身或别人都没任何视觉影响。
实操建议：
- 如果目标是「隐藏但保留占位和顺序逻辑」，别用
display: none，改用visibility: hidden+position: absolute或opacity: 0配合pointer-events: none - 如果目标是「隐藏且让其他项自动重排」，
display: none是对的，但必须同步调整剩下可见项的order值，否则顺序不会如预期变化 - 注意：
display: none触发重排（reflow），而visibility或opacity只触发重绘（repaint），高频切换时性能差异明显
用 visibility + order 实现“隐藏但保持排序锚点”
某些场景下，比如 tab 切换时希望面板 DOM 不销毁、但又不想它干扰当前 flex 排列顺序，就得让它“在场但不可见”。这时 visibility: hidden 是比 display: none 更合适的选择，但它本身不改变布局位置——所以要配合 order 把它挪到末尾（或开头），避免遮挡或撑开间隙。
示例：三个按钮按 order 排列为 1→2→3，想临时“隐藏”中间那个但不让两边挤在一起：
立即学习 “ 前端免费学习笔记（深入）”；
button:nth-child(2) {visibility: hidden; order: 99; /* 挪到最后，不影响前 / 后项的相对顺序 */ width: 0; padding: 0; margin: 0;}注意点：
-
visibility: hidden元素仍占据空间，所以需手动清空尺寸（width/padding/margin）才能真正“不占位” -
order值设为极大数（如99）比设为-1更安全，避免和其他项冲突 - 该方案不兼容 IE10 以下；若需支持，得 fallback 到
display: none+ JS 动态重算剩余项order
JavaScript 动态切换时，order 必须显式设置，不能依赖默认值
CSS 中未声明 order 的弹性项默认为 0，但 JS 批量控制显示状态时，如果只改 display 或 visibility，不统一管理 order，很容易出现顺序错乱——尤其当隐藏项恢复显示时，它的 order 还是旧值，可能卡在错误位置。
实操建议：
- 所有可能动态显示 / 隐藏的弹性项，初始 CSS 就该明确写上
order（哪怕都是0），避免 JS 读取getComputedStyle时得到normal这种非数值 - 用 JS 控制时，优先操作 class 而非内联 style：
el.classList.add('hidden')，然后在 CSS 里定义.hidden {order: 99; visibility: hidden; ……} - 不要用
el.style.order = ''清空，这会回退到normal，应设为具体数字如'0'
display: contents 是个危险但有效的替代方案
display: contents 让元素“消失”于布局树，但子元素仍作为弹性项参与排列——它不是隐藏，而是“透传”。如果你的弹性项内部有结构（比如一个 div 包着图标和文字），又想在隐藏时让子元素直接融入父 flex 容器，这个属性就很有用。
但要注意：
- 它会让元素自身失去所有盒模型特性（padding/margin/border 都无效），事件监听也会失效（因为没渲染盒子）
- 不支持 IE 和旧版 Safari；Android WebView 支持度也参差
- 一旦用了
display: contents，order就只能作用于它的子元素，原元素上的order完全被忽略 - 调试困难：DevTools 里该元素“看不见也点不中”，容易误判 DOM 结构
复杂点在于：你得判断清楚，到底是要“隐藏容器并保留子元素布局权”，还是“隐藏容器且子元素也不参与布局”——选错就全乱了。
