排序器是多数 Layer2 的单点入口：它宕机时链上已有状态仍在，但新交易可能排队、延迟或被拒收。本文从用户视角拆解排序器故障的三种表现——服务停摆、故障转移接管、强制交易上链兜底——预确认与接管窗口的关系，以及宕机公告期最需要防的仿冒钓鱼风险。

本文解释 Rollup 的强制交易（Force Inclusion）机制：用户如何绕过排序器直接把交易提交到 L1、OP Stack 与 Arbitrum 的等待窗口设计、排序器宕机时长不同时的生效差异，以及这条救济路径的成本与限制。

本文区分数据审查（censorship）与数据不可用：交易被拒绝、数据被扣留、选择性广播的不同形态，以及公链/DAS/排序器各自对审查的防护与残余空间。

本文对比 L1 公开内存池与 L2 排序器架构下的 MEV 差异：订单流是否公开、排序权在谁手里、用户暴露面有多大，以及不同 L2 排序模式的 MEV 暴露对照。

本文解释排序器集中化的问题与共享排序器的方案：它如何降低单点风险、改善跨 L2 流动性与资产安全，以及共享模式下的新权衡（耦合风险、运营激励）。