IEEE 802.3-2022以太网标准：25G到400G与修订件版本管理

简介：IEEE 802.3-2022 以太网标准正式版全文，面向网络协议开发者、芯片与 PHY 设计工程师、网络设备测试人员及高校通信专业师生，用于系统查阅以太网从 1Mb/s 到 400Gb/s 各速率的 MAC、MII、PHY 规范与 IEEE 802.3 系列规范。这一版标准全文达到 7025 页，比 2018 版新增 1400 余页，集中补充 25G 至 100G 相关条款并修订了 10G 部分内容，同时整合此前所有 802.3 修订；摘要还覆盖 CSMA/CD、Auto-Negotiation、EEE、FEC、PoE 等关键机制。资源包仅含 1 个 PDF 文件，约 93.79MB，为官方发布版式，目录层级与条款编号完整，便于按 clause 定位和交叉检索。已有 287 人学习下载。需要注意，2022 版之后发布的 802.3df-2024（400/800Gb/s）、802.3ck-2022、802.3db-2022、802.3cy-2023、802.3cz-2023 等修订未收录在内，涉及更高速率或新介质规范时需另行查阅。

1. 7025 页的一本标准：以太网把 25G 到 100G 写进了主干

2022 年 7 月 29 日，编号 IEEE Std 802.3-2022 的文档正式出版，批准日期是同年 5 月 13 日，替代 2018 版。在行业标准的语境里，IEEE802.3 这个名字几乎等同于以太网本身，所以每一次整版修订都被当作一次地基重浇。这一次的直观变化是厚度：全文档 7025 页，比上一版多出 1400 多页，新增内容集中在 25G 到 100G 这一段速率区间，同时对 10G 相关条款做了修订，此前若干独立修订件也被合并进主干。

对做交换芯片、光模块、网卡、测试仪的人来说，这份文档不是参考资料，而是对齐口径的底稿——两个厂商的器件能不能插上就用，最终都要回到它写的容限和状态机。值得先看清的一点是：它并不是"当前以太网标准的全部"，2022 年之后还有一批修订件陆续落地，这个边界比页数本身更影响实际选型。

2. 从 1 Mb/s 到 400 Gb/s：一份标准怎样装下四十年的速率谱系

2.1 同一套 MAC，覆盖五个数量级的速率跨度

这份文档覆盖的速率范围是 1 Mb/s 到 400 Gb/s，跨度五个数量级。它没有为每个速率重写一套协议栈，而是用一套公共的媒体访问控制（MAC）规格和管理信息库（MIB）把上层收住，速率差异下沉到物理层去解决。这个设计选择决定了以太网最重要的一个属性：换介质、换速率，协议栈和网管模型基本不用推倒重来。

共享介质那一支也还在。载波侦听多路访问/冲突检测（CSMA/CD）定义了半双工共享总线的运行方式，全双工链路则不需要冲突检测这套机制。文档里对多段共享接入网络的中继器只定义到 1000 Mb/s，这条边界很能说明问题——超过千兆之后，共享介质这条技术路线基本退出了主流 LAN，转而留在工业现场、车载和单对线这些特定场景里。局域网在所有速率上都被支持，这句话看着平淡，实际含义是：一份文档要同时回答"四十年前的同轴总线怎么跑"和"今天 400G 背板怎么跑"。

这张表只是把散落在各章里的速率档位收拢一下，真正的信息在横向对比里：越往高速率走，介质形态越集中到光纤和背板，铜缆的可用距离越短，能效和散热条款的权重越高。

2.2 25G 到 100G：这一版真正被加厚的那一段

新增内容压在这段区间，背后有明确的产业节奏。服务器接入从 10G 往 25G 换代的动因不是"数字更大"，而是通道经济性：25G 用单条 25G 通道就能实现，而 40G 早期方案要占四条 10G 通道，同样的面板带宽下，25G 的 SerDes 数量和布线密度都更划算。标准要做的，是把这种工程选择固化成可互操作的电气与光参数。

100G 这一段更复杂，因为它同时存在两条技术路线。一条是 4×25G 的并行方案，靠通道数量堆带宽；另一条是单通道 50G 配合 PAM4 调制，靠调制阶数提速率。两条路线在通道预算、时钟容限、前向纠错（FEC）需求上都不一样，标准必须把两套都写清楚，否则 A 厂的模块插到 B 厂的端口上就可能出现链路起不来、误码率压不下去这类问题。这里没有玄学可言，只有容限写得够不够细。

50G 和 200G 在这套体系里更像是中间锚点：50G 是 25G 的电气延伸，200G 则可以由 50G 或 100G 组合出来。标准把它们和 25G、100G、400G 放在同一份文档里，好处是跨速率的共同条款只写一遍，代价是篇幅——每增加一个速率档，相关的 PMD、PMA、PCS 子层描述都要跟着长出来。

10G 的修订也值得单独说一句。10G 是以太网里生命周期最长、部署基数最大的一档，它上面叠加了双绞线、多模光纤、单模光纤、电背板多种形态，还牵扯到能效以太网（EEE）和供电相关条款。修订这类成熟条款的难度往往高于新增一个高速率档位，因为任何一处措辞变化都可能影响已经在跑的存量设备的兼容性判断。

2.3 MAC、MII、PHY：一条链路被切成三层来写

文档的结构遵循一条清晰的分层账本。上层是统一的 MAC，中间是速率相关的媒体无关接口（MII）家族，下层是各种物理层器件（PHY），再往下按介质分成介质相关接口（MDI）。MII 这一层的作用是把"MAC 要什么"和"介质能给什么"解耦，它随速率分化出不同的位宽和时钟方案，但暴露给上层的语义是一致的。

这套分层解释了为什么一份标准能同时容纳接入网 PHY、城域网 PHY、以及特定双绞线上的供电能力。供电那一支分成两条：一条是以太网供电（PoE），走常见的双绞线对；另一条是数据线供电（PoDL），面向单对线场景。两者都定义了供电设备（PSE）和受电设备（PD）之间的协商过程，功率等级写在标准里，但能不能稳定交付是另一回事。

管理面同样统一。MIB 定义了网管能读到哪些对象，寄存器访问则通过管理接口完成。对写驱动和网管系统的人来说，这部分内容的稳定性比速率条款更重要——速率可以换代，网管模型一旦乱掉，整套运维工具都要跟着改。

提示：读这份文档时不要从第一页顺着翻。按"我要解决的链路问题"定位到对应速率段，再回头查公共条款，效率差别很大。

3. 页数多出 1400 页：这份标准的厚度到底由什么堆起来

3.1 增量拆成三块看，才不会误判

上一版在 5600 页量级，这一版到 7025 页，净增 1400 多页。把这些增量拆开看，大致来自三个方向。第一块是合并：整版修订的基本动作是把此前若干独立修订件并入主干，这些内容对长期跟踪标准的人是"旧内容换位置"，对只看整版文档的人则是"新内容"。第二块是新增：25G 到 100G 这一段速率带来的 PMD、PCS、自动协商、FEC 相关条款。第三块是横切：跨速率的一致性表述、测试方法、管理对象，这部分最不起眼，但往往是页数增长的大头。

这三块的性质完全不同。合并内容不改变技术判断，新增内容改变器件设计，横切内容改变测试和认证的做法。把它们混在一起谈"标准变厚了"，对实际工作没有指导意义。

3.2 芯片、模块、测试三类角色，查的是同一份文档的不同部分

做芯片的人关心的是电气参数和状态机：时钟容限、抖动预算、链路训练的收敛条件、自动协商的状态迁移。他们的血泪经验通常是某一版容限收紧了半个单位间隔，导致上一版能过的硅片要重新做 corner 验证。

做模块的人关心 PMD 和通道指标：消光比、灵敏度、通道回波损耗，以及不同速率下的 FEC 配置要求。模块这个环节的特点是跨厂商互操作压力最大，同一份标准文本被两家解读出细微差别，最后就表现为现场"这批能插、那批不能插"。

做测试的人关心的是测试套件和容限边界。一致性测试不是把标准读一遍就能设计出来的，它要把文本里的"应"和"宜"翻译成可执行的激励和判据。这也是为什么测试方案往往滞后于器件发布——标准发布是起点，测试套件成熟还要再等一段时间。

三类角色面对同一份 7025 页文档，实际用到的可能都不到十分之一，但没人能提前知道自己需要的是哪十分之一。这就是厚文档的现实成本。

3.3 厚度会传导成工程成本，但省不掉

标准变厚最直接的影响是学习和检索成本上升。一个新人要从这份文档里建立完整的链路认知，靠通读不现实，通常得有人带着走一遍"从速率到介质到测试"的路径。第二个影响是工具链：文档检索、版本比对、条款引用管理，这些琐事在厚文档下会被放大。

但这份厚度很难说成冗余。以太网的特点是向后兼容，越是要兼容几十年的存量形态，主干文档就越不可能精简。真正能做的不是抱怨厚，而是建立自己的索引——把常用的速率段、接口类型、测试判据摘出来，形成一份几十页的个人工作底稿。这份底稿的质量，往往比是否背下某个条款编号更能决定排查问题的速度。

4. 常见误读：把 802.3-2022 当成"最新全集"的五个坑

4.1 误读一：拿到 2022 版就等于掌握了当前全部以太网标准

误判点很普遍：整版修订＋7000 页的体量，很容易让人默认这就是"当前以太网标准的全集"。

为什么会产生这种印象？因为整版修订在宣传语境里通常被描述为"合并了此前所有修订"，这句话本身没错，但它描述的是截至批准日的时间点。标准是活文档，2022 年 5 月之后新批准的修订件不会自动回填到已经出版的 PDF 里。

正确的看法是把主文档和修订件当成两个层级：主文档提供稳定的公共底座，修订件提供增量。判断某个特性在不在，要看"主文档＋此后全部修订件＋勘误"这个组合，而不是单看一本书的出版年份。这个习惯一旦建立，后面很多选型争议会自动消失。

4.2 误读二：页数增加就等于新速率增加

1400 多页的增量看起来像是塞进了一大堆新东西，实际上其中有相当比例来自既有修订件的合并。合并本身有价值——它让分散在多个文件里的条款回到同一处，减少了交叉引用——但它不产生新的技术能力。

为什么容易误判？因为页数是唯一一个不用读内容就能感知的指标，天然被当成"信息量"的代理。而标准的价值密度极不均匀，有的章节几十页只描述一种封装的机械尺寸，有的章节两页就定义了一个影响全行业的协商机制。

怎么看更靠谱：拿两版的目录做对比，看哪些一级条目是新增的、哪些是原有条目被扩写。目录层面的差异，比总页数更能说明这一版的重心在哪。

4.3 误读三：既然写到 400G，那 800G 应该也在里面

这个推论很自然，但结论是错的。2022 版的上界是 400 Gb/s，800G 相关内容落在 2022 年之后发布的修订件里（802.3df-2024 涉及 400/800 Gb/s）。把版本文档的上界向后顺推一档，是选型阶段最容易踩的坑之一。

为什么容易出错？因为速率演进有连续性，行业讨论里 400G 和 800G 经常同框出现，听多了就会模糊掉"讨论中"和"已发布"的界线。

怎么看：把"标准里写了"和"产业在谈"严格分开。前者可以去查文本，后者只能作为路线预判。做产品规划时如果用后者替代前者，很容易在器件选型上提前锁定一个还没有正式容限定义的接口。

4.4 误读四：CSMA/CD 早就没用了，相关条款可以跳过

全双工链路不需要冲突检测，这是事实，但由此推出"共享介质那一支已经死了"就过头了。标准里对半双工共享介质的定义仍在，中继器条款也仍在（上限 1000 Mb/s），而单对线以太网上的物理层冲突避免（PLCA）机制，本质上是这一脉思路在现代场景里的延续——用确定性的轮询替代随机竞争，解决共享介质上的时延抖动问题。

工业现场和车载场景对确定性传输的需求，恰恰让这类"看起来过时"的机制重新有了用武之地。跳过这部分条款的人，往往在做低时延确定性网络时才回头补课。

4.5 误读五：PoE 的功率上限就是实际能交付的功率

标准里写的功率等级是接口层面的定义，不是整机层面的承诺。实际能交付多少功率，还要看线缆的直流电阻带来的压降、线束捆扎后的温升、PSE 侧的散热设计，以及 PD 侧协商时的余量。

为什么容易误判？因为功率数字最直观，采购和产品定义阶段最容易直接引用。等到整机做温升测试时才发现余量不够，返工成本就上去了。

怎么看：把标准功率等级当成上限约束，把线缆和散热当成下限约束，实际设计点取两者之间。多端口高密度设备尤其要留余量，因为最坏情况往往出现在满配满负载而不是单端口测试时。

5. 修订件的时间线：2022 之后那些"补丁"该怎么接

5.1 九份修订件，一张表看清边界

2022 版之后陆续发布的修订件不包含在主文档内，这一点在资源说明里已经明确列出。把它们排成一张表，能直观看出主文档的边界在哪。

表里最后一列全是"否"，这本身就是最重要的信息：主文档的边界固定在 2022 年，此后每一年都可能有新增量。表格中"未标注速率范围"的条目，说明里没有给出具体范围，实际内容需要查正式文本，不要凭编号猜。

5.2 三种典型场景，基线选择完全不同

第一种是新设计选型。这种情况建议以主文档为底座，同时把与目标速率相关的修订件全部拉齐。比如做 400G 相关器件，2022 版加上 802.3ck、802.3db、802.3df 三份都要在手上，因为容限和测试判据可能被后发的修订件改写。只拿主文档做设计基线，风险在于你遵守的是一份已经被局部更新的规则。

第二种是存量设备维护。这类工作通常不需要追最新修订件，而是要以设备宣称符合的那个版本为准。认证报告、一致性测试记录都锚定在特定版本上，贸然按新版本复测，可能得到一堆"不符合"但实际设备工作正常的结论。这里的关键是把版本号和设备台账绑定，而不是追求"永远用最新"。

第三种是教学和培训。教学场景适合以主文档为主线，因为它结构完整、公共条款齐全，修订件作为补充案例讲"标准如何演进"。反过来做——直接从修订件切入——会让学习者缺少公共底座，理解不了为什么要改。

5.3 版本台账：把"我手上这份够不够用"变成可查询的问题

文档一多，最容易出问题的不是读不懂，而是拿错版本。下面这段脚本把主文档和修订件的覆盖关系写成数据结构，给定一个目标速率就能查出需要哪些文档。

# 标准文档版本台账：主文档 + 修订件的组合视图 # 用途：给定目标速率，返回需要同时持有的文档集合，避免拿旧版做基线 from dataclasses import dataclass @dataclass class Doc: doc_id: str # 文档编号，例如 "802.3-2022" year: int # 发布年份 rates: list[str] # 覆盖速率（Gb/s）；空列表表示说明中未标注，需查正式文本 is_base: bool = False # 是否为主干整版 # 主干版本：速率上界 400 Gb/s，800G 不在其中 BASE = Doc( "802.3-2022", 2022, ["0.001", "0.01", "0.1", "1", "2.5", "5", "10", "25", "40", "50", "100", "200", "400"], is_base=True, ) # 2022 之后发布的修订件，均未并入主干 AMENDMENTS = [ Doc("802.3de-2022", 2022, []), Doc("802.3dd-2022", 2022, []), Doc("802.3cs-2022", 2022, []), Doc("802.3ck-2022", 2022, ["100", "200", "400"]), Doc("802.3db-2022", 2022, ["100", "200", "400"]), Doc("802.3cy-2023", 2023, []), Doc("802.3cz-2023", 2023, []), Doc("802.3cx-2023", 2023, []), Doc("802.3df-2024", 2024, ["400", "800"]), ] def docs_for(rate: str, with_amendments: bool = True) -> list[str]: """按目标速率列出需要查阅的文档；默认把未并入主干的修订件也计入""" hits = [BASE.doc_id] if rate in BASE.rates else [] if with_amendments: hits += [d.doc_id for d in AMENDMENTS if rate in d.rates] return hits print(docs_for("400")) # 400G 同时落在主文档与两份标注了该范围的修订件上 print(docs_for("800")) # 800G 只出现在 802.3df-2024，主文档查不到 print(docs_for("10")) # 10G 只在主干，说明这一档以合并修订为主

这段代码的价值不在复杂度，而在把口头判断固化成可执行查询。rates字段按资源说明里标注的范围填写，空列表表示说明没有给出速率范围，这类条目必须人工去查正式文本，脚本不做猜测。with_amendments参数用于切换视角：做存量维护时把它设为 False，只看主文档对应的版本基线；做新设计选型时保持 True，把增量全部纳入。

配套的目录约定同样重要，文件命名不带年份和速率线索，用不了多久就会分不清哪份是哪份。

# 标准文档库的目录约定：主干与修订件分开存放，文件名带年份与速率线索 STANDARDS_ROOT=~/docs/ethernet mkdir -p "$STANDARDS_ROOT"/{base,amendments,notes} # 主干版本一年份一份，不覆盖旧文件 cp 802.3-2022.pdf "$STANDARDS_ROOT/base/802.3-2022.pdf" # 修订件按发布年份归档，文件名前缀标出速率，方便 grep 定位 cp 802.3df-2024.pdf "$STANDARDS_ROOT/amendments/2024-802.3df-400G-800G.pdf" cp 802.3ck-2022.pdf "$STANDARDS_ROOT/amendments/2022-802.3ck-100G-200G-400G.pdf" # 取用前先打印台账，避免凭印象拿文件 find "$STANDARDS_ROOT" -name '*.pdf' -printf '%f\n' | sort

base和amendments两个目录的划分对应主文档与增量的层级关系，notes放自己摘的工作底稿。文件名前缀用年份而不是编号，是因为实际检索时"哪年的东西"比"编号是多少"更容易想不起来。最后那条find命令看着简陋，作用是在每次取用前强制过一遍清单，这个动作能挡掉大部分拿错版本的情况。

6. 趋势判断：标准的主线正在从"翻倍"转向"分层"

把这份文档和它之后的修订件放在一起看，能看到三条并行的线。第一条是速率线，400G 之后是 800G，再往后是更高速率的讨论，但节奏明显变了：整版修订的周期大约四到五年，而速率迭代的周期更短，结果是主文档越来越难"一次写全"，增量只能靠修订件持续打补丁。这意味着"以太网标准"正在从一个可枚举的文件集合，变成一个需要主动维护的版本视图。

第二条是供电与能效线。PoE、PoDL、能效以太网这些条款在整版文档里的权重持续上升，原因是设备侧的功率密度在涨，而布线侧的散热能力有物理上限。未来的选型争论，很可能不再是"这个速率能不能跑"，而是"这个功率密度在既有布线条件下能不能稳定交付"。

第三条是确定性线。共享介质那一支看似边缘，但物理层冲突避免这类机制解决的是时延抖动问题，这恰恰是工业与车载场景的核心诉求。标准保留这条技术脉络，不是历史包袱，而是给确定性场景留了接口。

对从业者的实际影响是：版本管理正在变成一项工程能力，而不是行政琐事。做器件的要清楚自己宣称符合哪一版，做系统的要清楚对端可能停在哪一版，做测试的要清楚判据来自哪一版。这三件事对不上，联调阶段就会出现那种"双方都说自己符合标准"的僵局。

我早年在一次跨厂商联调里翻过车：两边都拿着标注同一版本的文档，实际一份是主文档、一份是合并了后续修订的合集，容限差了半个档，查了三天才定位到。从那以后我每次启动新项目，都强制走一遍版本台账——先把目标速率对应的主文档和修订件列全，再开始看条款。这个习惯花不了十分钟，省下的是整轮联调的后悔药。希望帮到你。

本文还有配套的精品资源，点击获取