企业官网建设流程全解析

1. 先说结论：PoE 不是“插上就有电”，而是两套机制在猜需求

你在项目里配过 PoE 摄像头，大概率遇到过这种事：网线插上去，交换机端口灯是亮的，但摄像头死活不开机；或者开机闪一下就反复重启。很多人第一反应是“摄像头坏了”“交换机端口坏了”，但真正的问题往往出在 PoE 的功率协商上——PoE 供电设备（PSE，通常是交换机）和受电设备（PD，摄像头、AP、电话机）之间，并没有一个“我饿了，给我 14.2W”的直接对话通道。

PoE 想知道对方要多少电，靠的是两套并行机制：一套是物理层的 class 分级，从 802.3af 时代就存在，相当于手动挡，PD 告诉你一个功率“档位”，PSE 按档位给；另一套是 LLDP 功率握手，从 802.3at 开始引入，类似实时竞价，PD 可以在运行过程中向 PSE 报出更精确的功率请求，PSE 再告诉它“我最多给你多少”。两个机制的关系不是替代，而是先分级、后精调。

这篇文章把这两套机制从头到尾拆开讲清楚，包括 PD 端 25kΩ 特征电阻是怎么被探测的、分类电流对应的 class 表、LLDP 里 Power via MDI TLV 的实际交互过程，再结合我在摄像头、AP 项目中踩过的功率预算坑，给你一套可以直接拿去排障的实操思路。

1.1 为什么 PSE 不能直接送 48V

这是最多人忽略的基础。如果 PSE 一看到网线插上就送 48V，那普通电脑、打印机这类非 PoE 设备直接就被打坏了。所以 IEEE 规定了一个“先探测，再上电”的安全流程：PSE 会先施加一个很低的电压，检测对端是否存在一个 25kΩ 的特征电阻——这个电阻是 PD 内部刻意设计出来的“我是受电设备”信号。只有探到合法电阻，PSE 才会继续走分类流程，最终才敢送上 48V。

说白了，PoE 的功率协商不是一个“问功耗”的过程，而是一个“验明正身”的过程：第一问你是谁，第二问你要几档电，第三问能不能再精确点，最后才真正供电。接下来我按这个顺序展开。

2. class 分级：物理层的“手动挡”，先把功率档位定下来

class 分级的思路特别像汽车变速箱的手动挡。PD 在设计时就知道自己大概的功耗范围，比如红外摄像头常态 10W、夜间加红外灯 14W，那它就通过物理层的分类电流告诉 PSE：“我要按 class 3 对待”。PSE 收到这个信号后，会把这个端口的功率预算记为 15.4W，并在后续运转时按这个级别限制输出。

这里有一个容易混淆的地方：class 分级里的“功率”有两个值，一个是 PSE 侧的输出功率上限，一个是 PD 侧可用的最大功率。两者中间差的部分是线缆损耗。因为 PoE 标准按 100 米五类线来评估，线缆本身会吃掉一部分功率，所以 PD 真正能用的永远比 PSE 标称输出低一截。

2.1 三个标准对应的 class 功率表

从 802.3af 到 802.3at，再到 802.3bt，class 的数量和含义一直在扩展。我把最常见的映射关系整理成一张表，这张表我项目里反复对照，建议保存。

看这张表你会发现一个有意思的细节：class 0 在 af 里其实代表“未知或由 PD 自定义”，但很多 PSE 会直接按最大档位 15.4W 给它预算。所以早期设备上“class 0”很常见，并不代表这个设备耗电小，反而它可能拿到最高的默认功率预算。

到了 at 和 bt 阶段，class 4 的含义被重新定义了。802.3af 里 class 4 是保留项，到了 802.3at 里 class 4 就是 Type 2 的标记。再往后到 802.3bt，单单报一个 class 4 还不够，因为 bt 要求 PD 通过“两事件分类”来确认自己是否支持 Type 3/Type 4，否则 PSE 会默认按 at 的 25.5W 来限制你。这是很多 bt 摄像头插到老交换机上拿不到高功率的直接原因。

2.2 PSE 怎么把 class “读”出来：两段式探测

PSE 读 class 不是靠软件协议，而是靠物理层的电流特征。整个过程分两步：

第一步是检测。PSE 在网线对上施加一个 2.7V 到 10.1V 之间的电压，测量电流，再换个电压再测一次，通过两个采样点计算斜率，得到对端电阻。正常的 PD 签名电阻是 25kΩ，容差在正负 5% 以内。如果算出来是 25kΩ，PSE 确认“这是合法 PD”；如果不是，大概率是普通网卡或空线，PSE 不会继续下一步。

第二步是分类。PSE 把电压抬升到 15.5V 到 20.5V 之间，PD 内部会根据自己设计的 class 接入不同的电流负载，PSE 测量这个电流区间。大致上：0 到 5mA 对应 class 0，9 到 12mA 对应 class 1，17 到 20mA 对应 class 2，26 到 30mA 对应 class 3，36 到 44mA 对应 class 4。电流区间之间有明显的间隙，就是为了防止误判。

这套机制的巧妙之处在于，检测和分类阶段的功率都非常小，不会损坏非 PoE 设备。即使你误插了一台不支持 PoE 的电脑，PSE 探测不到 25kΩ 特征电阻，也就不会进入供电阶段。所以在排障时，如果你的交换机端口显示“Detecting”状态一直不变，先怀疑 PD 端签名电阻异常或者网线质量太差，而不是怀疑电源板坏了。

3. LLDP 功率握手：从“档位”到“实时报价”

class 分级有一个先天缺陷——它只能表达几个固定档位，精度太粗。class 3 和 class 4 之间差了 15W，如果一台设备实际峰值功耗是 18W，报 class 3 可能不够，报 class 4 又浪费端口预算。更麻烦的是，很多设备的功耗不是恒定的：红外灯开启前后可能差 3 到 5W，云台电机启动瞬间可能冲到正常功耗的三倍。这种动态变化靠固定 class 根本没法处理。

LLDP 功率握手就是为这个场景设计的。它不是一个单独的协议，而是把功率协商信息塞进 LLDP 报文里，由 IEEE 802.3at 定义了一种叫 Power via MDI 的 TLV。如果你用 Wireshark 抓包，能看到 Type 为 127 的组织特定 TLV，OUI 是 00-12-0F，subtype 是 1。这才是 PoE 功率协商真正的“对话内容”。

3.1 为什么 class 都报上去了还要 LLDP

我见过不少项目里，工程师以为 PoE 功率是靠 class 一锤定音的，其实不是。class 完成的是“预算立项”，LLDP 做的是“动态结算”。

具体来说：PSE 在分类阶段知道 PD 是 class 4，就会在端口上预留 30W。但这个预算不一定真的全部给出去。PSE 还要看交换机整机电源余量、端口优先级、系统策略，最终在 LLDP 报文里告诉 PD：“我给你分配 20W。”PD 收到这个分配值之后，会主动调节自己的功耗，比如降低红外灯亮度、限制云台转速、关闭某些射频链。

反过来，PD 也可以通过 LLDP 向 PSE 请求更高的功率。比如 AP 在夜间开启第二路射频，PD 可以在 LLDP 里把请求值从 15W 改到 25W，PSE 收到后看预算还有余量，就会更新分配值。这种动态协商能力是 class 完全做不到的。

LLDP 的交互周期通常是 1 到 2 秒发一次报文，所以功率变化不需要重启设备，几个报文周期就能同步完成。这也是为什么很多高端 PoE 交换机在管理页面上能看到“当前协商功率”这样实时变化的数据，背后就是 LLDP 在不停更新。

3.2 一次完整的功率握手流程

我把一次标准的 LLDP 功率握手拆成四步，方便对照抓包去看。

第一步，PD 上电进入运行状态后，开始在 LLDP 报文中携带 Power via MDI TLV。PD 会在这条 TLV 里上报自己的功率类型（PD）、优先级、当前请求的功率值，这个值以 0.1W 为单位。举个例子，如果 PD 请求 15W，报文里的数值就是 150。

第二步，PSE 收到 PD 的 LLDP 报文后，会对比本端口的预算分配和整机剩余功率。如果余量充足，PSE 会回复一条携带分配功率值的 LLDP 报文，明确告知 PD“我分给你多少”。假如 PSE 因为整机预算不足，给了一个比 PD 请求值更低的分配值，PD 就必须调整自己，否则 PSE 可能会触发过流保护。

第三步，PD 收到 PSE 分配值之后，会把这个值当作自己的“功耗天花板”，开始动态调整负载。这个过程不是一次性的，PD 可以随时发起新请求，PSE 也可以主动更新分配值。

第四步，如果链路断开或者 PD 掉电，PSE 会在很短时间内停止供电，端口状态回到检测阶段。下次重新上电，要再走一遍探测、分类、LLDP 协商的完整流程。

在实际抓包里，你只要看 LLDP 报文里的 Power via MDI TLV 字段，就能直接看到“请求 25.5W、分配 30W”这种具体数字，比去交换机管理页面翻日志直观得多。

3.3 802.3bt 对 LLDP 的强化，以及两事件分类

到了 802.3bt 阶段，功率协商变得更复杂，因为功率上限已经到 90W，不能再依赖老一套的简单分类。

802.3bt 引入了一个叫“两事件分类”的机制。老标准的分类只有一次电压脉冲，PD 报一个 class 就完了。bt 里 PSE 会连续给两个电压事件，第一次让 PD 报基础 class，第二次确认“你是否支持更高功率”。只有完整经历两个事件的 PD，才会被 PSE 认定为 Type 3 或 Type 4 设备，才有资格拿到 40W 以上功率。

LLDP 在 bt 里也升级了，Power via MDI TLV 增加了更多字段，比如电源类型、优先级、可用功率、分类信息、请求值和分配值。其中让我印象最深的是“可用功率”这个概念：PSE 可以在广播自己的整机功率预算，PD 收到后能自动判断自己该不该请求更多功率。这就从一个“点对点协商”变成了“集中调度”，在大型 PoE 供电项目中非常有用。

如果你用的是 bt 交换机，但 PD 端是老设备，整个过程会退化为经典模式；反过来，bt 设备插到 af 交换机上，最多只能拿到 12.95W 或 25.5W，别指望它能通过某种协议魔法突破物理层的功率上限。协议之间的兼容性是向下兼容的，不是向上飞跃的。

4. 一帧完整握手复盘：从插上网线到摄像头亮灯

讲了协议部件，我把整个链路的时序串起来复盘一遍。这个时序非常重要，排障时你先知道设备走到哪一步，才能判断问题出在哪个环节。

第一步是物理连接。网线插上后，PSE 开始做检测。它输出两个不同的低压采样点，测量对端电阻。如果你的网线质量差、线对电阻太大，或者线缆超过 100 米，PSE 看到的等效电阻可能偏离 25kΩ 太多，直接判定“没有 PD”，端口状态卡在检测阶段。这是我在现场遇到最多的“假死”问题之一。

第二步是分类。PSE 确认 PD 合法后，开始施加分类电压，读取当前档位。PD 的 class 值由它内部的分类电路决定，这个电路通常是根据设备设计功耗选定的。如果 PD 的设计功耗是 14W，它的分类电路可能被设计成 class 3；如果 PSE 认为 class 3 的 15.4W 不够设备吃，它可以拒绝上电或者后续触发过流保护。

第三步是上电。PSE 输出 48V 电压，同时限制启动浪涌电流。很多摄像头在启动瞬间会有一个电容充电过程，表现为大电流脉冲，PSE 的浪涌限制就是为了防止这个时候误判短路。上电完成后，PD 的 DC-DC 电路开始工作，系统启动。

第四步是 LLDP 协商。PD 启动后，开始发 LLDP 报文请求精确功率。这里有个细节：很多 PD 在系统还没完全启动时用的是“低功耗模式”，比如摄像头先不开红外灯、AP 先不启动高功率射频，等拿到 PSE 的分配值后再逐步加载功能。这么做就是为了避免“还没协商完就超功率导致掉电”。

第五步是动态运行。设备正常工作期间，LLDP 报文持续交互。如果 PSE 整机功率被其他端口挤占，它可能下调某个端口的分配值；PD 收到后可能被迫降功耗。如果你看到摄像头夜间红外灯自动变暗、AP 莫名其妙降速，可以先查 LLDP 分配值是不是被压了。

完整时序里，最容易被忽略的是第二和第四步之间。有些 PSE 在分类阶段给的功率和后续 LLDP 分配值不一致，比如分类给 30W 预算，但 LLDP 只分配 20W。PD 如果按 30W 去设计行为，就很容易发生过流。所以我在项目里，一定要求交换机侧把 LLDP 的分配策略配置为“按最大分类功率分配”，而不是“按整机预算动态压缩”，除非特别清楚 PD 端能自适应。

5. 实战排查与选型：摄像头场景下的功率计算和“闪断”案例

下面这部分，是这套协议知识在项目里最值钱的地方——怎么避免摄像头反复重启、怎么算功率预算、怎么在现场快速定位是 class 问题还是 LLDP 问题。

5.1 功率预算别按“铭牌功耗”算，要按峰值算

我在做一栋楼的全 IP 化改造时，统计过所有 PoE 摄像头的实际功耗。铭牌上写 12W 的固定摄像头，夜间红外全开能到 14W；云台摄像头更夸张，启动瞬间电流能到额定值的 2.5 倍左右。如果你按铭牌功耗做预算，整机算出来还剩 10W 余量，实际一到夜间全端口一起拉高，交换机电源直接过载，出现大面积端口掉电。

我给一个保守但不会出问题的估算公式。每个端口的 PoE 预算 = 设备峰值功耗 × 1.2 的保险系数 + 线缆功耗预留。线缆预留按线缆长度估算，百米五类线大约损耗 2.45W 到 4.5W。以固定红外摄像头为例，铭牌 12W、峰值 14W，乘 1.2 后是 16.8W，这意味着你至少需要给它配一个 class 4 级别的端口，而不是 class 3。因为 class 3 的 PSE 输出上限只有 15.4W，卡得刚刚好，夜间红外一开就会顶到保护阈值。

为什么要留 20% 余量？因为 PoE 交换机的功率保护是按端口电流阈值触发的，分类电流和实际电流之间存在差异，再加上线缆电阻受温度影响，铜的电阻温度系数约为 0.4%/℃，线缆夏天和冬天的损耗能差出不少。卡着 1W 余量的设计，到了夏天必炸。

5.2 三个典型故障现场：class 不对、LLDP 分配过低、网线拖后腿

第一个高频故障，是设备实耗超过了 PSE 按 class 给出的功率上限。现象是摄像头启动正常，但红外灯一开就断线重启，查看交换机日志能看到“power over current”或“PD disconnected due to over current”这类记录。这种问题优先检查端口分类，如果你的交换机支持手动锁定 class，把这个端口强制锁定到更高档位，问题立解；如果不支持，只能换更高等级的 PSE 或者外部供电。别想着靠 LLDP 解决，因为耗电增长是在 LLDP 协商周期之外发生的物理突变。

第二个高频故障，是 LLDP 分配值被 PSE 压得太低。现象是 AP 接入后只能跑到一半速率，或者摄像头的云台转动时频繁掉电，但正常静态画面没问题。这种情况去交换机管理界面看端口 PoE 实时功率，一般会看到分配值只有 PD 请求值的 60% 左右。解决方案是调整交换机 PoE 策略，把端口优先级调高，或者直接关闭动态功率压缩，让端口按最大分类功率分配。

第三个高频故障，是网线问题导致 PSE 根本探测不到合法 PD。现象是端口一直处于“Detecting”状态，或者“Searching”状态。这个我在现场用万用表量过很多次，劣质铜包铝网线 80 米外电阻可以超标两倍，PSE 读到的等效电阻完全偏离 25kΩ。这时候换 PoE 交换机、改摄像头配置都没用，老老实实换线。判断方法很简单：把 PD 拿到交换机旁边，用一米成品跳线插上，如果立即正常供电，90% 是线缆问题。

5.3 现场常用验证手段

排障时我最常用的不是网线测试仪，而是 Wireshark 抓 LLDP 报文。在交换机镜像端口或者在 PD 端接一个抓包工具，抓到的 Power via MDI TLV 里能看到双方实际协商的功率值。Linux 下可以直接用 tcpdump 抓：

sudo tcpdump -i eth0 -XX -s 0 'ether[12:2] == 0x88cc'

LLDP 的以太网类型是 0x88cc，抓到后重点看 Type 127 的 TLV，里面会有 PD 请求值和 PSE 分配值。这个方法比看交换机日志准确得多，因为日志只是记录保护动作，抓包能看到协商过程。

另外，在交换机管理界面里，几乎所有主流厂商都有查看端口 PoE 状态的命令。典型的有：

show power inline <interface>

这条命令在不同厂商系统里略有差异，但基本都会显示该端口的分类状态、实际消耗功率、当前分配功率、供电状态。先看状态是不是“Delivering Power”，再看实际功率是不是逼近分配值峰值，一步一步排查。

6. 关于选型，我个人的不严谨但好用的经验

最后分享一个我反复使用的选型思路。如果你给一个摄像头配 PoE 交换机，首选支持 802.3bt 的型号，哪怕当前只有几台设备需要高功率。原因很现实：bt 交换机向下兼容 af/at 设备，同时端口预算宽裕，调试时不用拿计算器逐台算 class。而 af 交换机端口预算 15.4W 封顶，遇到需要高功率的摄像机就只能外接电源，这会直接破坏施工的整洁度。

如果预算有限必须用 at 交换机，端口功率预算尽量不连续部署超过总预算的 80%。很多中低端 PoE 交换机的整机功率预算和端口分类功率是完全独立的两套逻辑，每个端口按分类预留了 30W，整机却只有 120W，一旦同时接入 4 台以上 class 4 设备，整机电源就过载了。这个“端口预算 vs 整机预算”的差额，是 PoE 排障里最容易骗到人的细节。

PoE 的功率协商从 class 分级到 LLDP 握手，本质是两套不同颗粒度的机制相互配合。物理层分类负责确定设备类型和初始安全供电范围，LLDP 负责运行期的动态精准调节。理解了这两个层次，你在查 PoE 故障时就会形成一条清晰的判断链：设备不启动先看检测、检测通过后看分类、分类正确后看运行时功率、运行时异常再看 LLDP 分配值。大部分问题都能在这一条链路上定位出来。