100W 快充到底只跑出 55W，一根 Type-C 线差在哪？

100W 的充电器，3 米的线，插上笔记本，页面算出设备端只有 55.5W。

不是充电器虚标。

是线先到上限了。

24AWG 线芯只能扛 3A，20V × 3A = 60W，再扣掉线上的 1.52V 压降，设备端剩 55.5W。

我把这套换算做成了一个单文件网页，改 5 个参数就能复算。

一、为什么值得看：100W 是充电器的上限，不是线的上限

买充电器时看 100W，买线时只看“支持快充”，这是两件事。

USB PD 的 100W 是 20V × 5A。

5A 这一档要求线里有 E-marker 芯片，没芯片的线默认只给 3A。

3A × 20V = 60W，所以一根没 E-marker 的线，插 100W 充电器也上不去。

线芯粗细再砍一刀。

28AWG 我按 2A 算，24AWG 按 3A，20AWG 按 5A。

长度决定压降，压降决定设备端还能拿到多少电压。

同样是 100W 充电器，5 组线的结果差了一倍多：

组合（固定 100W 充电器）	设备端功率	压降	线损	被谁卡住
0.5m / 24AWG / 标准 E-marker	59.2W	0.25V	0.8W	线芯 3A
1m / 24AWG / 标准 E-marker	58.5W	0.51V	1.5W	线芯 3A
3m / 24AWG / 标准 E-marker	55.5W	1.52V	4.5W	线芯 + 压降
2m / 28AWG / 无 E-marker	36.6W	1.70V	3.4W	E-marker + 线芯 + 压降
1m / 20AWG / EPR E-marker	98.3W	0.33V	1.7W	没有被卡

这 5 组我在页面上逐个点过，数字和表里一致。

2 米 28AWG 无 E-marker 那组最典型。

充电器只输出 40W，线上丢 3.4W，设备端 36.6W。

不是线“偷电”，是规则根本没让它要更多。

二、这个页面能做什么

页面左边是 5 个参数：充电器档位、线芯、线长、E-marker、设备。

右边第一行就是设备端功率，下面跟实际电压、电流、压降、线损。

再往下是三条限制提示，告诉你被协商、线芯还是压降卡住。

中间是 Type-C 24 针剖面，CC 和 E-marker 会按当前选择高亮或变灰。

右边是 7 步 PD 协商时间线，每一步写清当前配置下发生了什么。

底部是 5 组对比表和 12 条自检。

整个页面一个 HTML 文件，不引 CDN，不联网。

三、四个上限，取最小值

实际电流不是充电器说多少就是多少。

它取三个值里最小的那个：充电器电流、E-marker 上限、线芯额定。

const negCurrent = Math.min(ch.a, em.a, awg.a);
const negVoltage = Math.min(ch.v, em.v);
const voltageDrop = negCurrent * 2 * awg.r * L;
const devPower = (negVoltage - voltageDrop) * negCurrent;

乘 2 是因为电流要走过去再走回来。

线阻用的是常见铜线参考值：28AWG 0.2129Ω/m，24AWG 0.0842Ω/m，20AWG 0.0333Ω/m。

100W、3 米、24AWG、标准 E-marker 这组，代进去是这样：

3A × 2 × 0.0842Ω/m × 3m = 1.5156V 压降。

20V − 1.5156V = 18.4844V。

18.4844V × 3A = 55.45W。

线上损耗是 3A² × 0.5052Ω = 4.55W。

充电器实际输出 60W，设备端 55.45W，线端效率 92.4%。

如果拿 100W 铭牌当分母，效率会显示 55.5%，那是把“没跑满”算成了“线损”。

这两个数不是一回事。

140W EPR 那组更能看出线芯的作用。

1 米 20AWG 能跑满 5A，设备端 138.3W。

同样 140W，换成 1 米 24AWG，电流被线芯压到 3A，设备端只剩 82.5W。

再换成 3 米 28AWG，压降 2.55V，设备端 34.9W。

四、验证与踩坑

我先在本地开了个静态服务，把 5 个场景逐个点了一遍。

python -m http.server 8080

页面自检 12/12 通过。

但这 12 条是页面自己写的，不能自己证明自己。

我另写了一份 Python 计算，按同一套规则重算 15 组参数，再和页面 compute() 的输出逐项对比。

15/15 一致。

对比项包括电流、电压、压降、设备端功率、线损、实际输出功率和效率，误差都小于 1e-6。

这一步抓出了两个真问题。

第一个是效率。

页面最初用设备端功率除以充电器铭牌 100W，得到 55.5%。

看起来像“线损吃掉了一半”，其实充电器只输出了 60W。

分母改成实际输出功率后，效率是 92.4%。

第二个是自检本身。

第 7 条写“65W + 1m + 24AWG 设备端大于 60W”，按规则算出来是 58.5W，这条从一开始就不可能通过。

第 12 条写“线损 = 铭牌功率 − 设备端功率”，把没跑满的 40W 也算成了线损。

我把它改成“实际输出 − 设备端功率”，两条断言才真正对上物理量。

这两个问题都不在 UI 上，页面看起来一直是正常的。

要是不写独立复算，自检面板会一直挂着两个 FAIL，或者更糟，被我改成永远 PASS。

失败路径也试了。

线长填 0、填 -1、填 4、留空，结果区都显示“—”，输入框下面给出同一句中文提示。

五、结果与边界

这个页面能回答“这套组合大概能到多少瓦”。

它不能回答“你手里这根线是不是真的有 E-marker”。

线阻用的是典型铜线参考值，没有算接头、焊点、线材纯度和温度。

28AWG 2A、24AWG 3A、20AWG 5A 是我的工程估算，不是厂商认证值。

55.5W 是模型算出来的，不是我拿功率计测出来的。

真要测，得用 USB PD 分析仪抓 CC 线上的协商报文，再同时记录 VBUS 和电流。

页面只做规则推演，不做合规认证。

六、使用码道体会

码道有三种使用方式：WebUI、TUI 和桌面 IDE。

这次用的是 WebUI，浏览器里把需求说清楚，它直接生成了一个 index.html。

我把参数、公式、5 组对比、7 步时间线、12 条自检都写进需求里。

生成出来的结构基本对，最省事的是自检面板也被做进了页面。

但 AI 写的自检会跟着 AI 自己的错误走。

效率分母和两条断言就是例子：页面能跑，数字也“看起来合理”，但物理量对不上。

所以我现在的做法是，需求里要求页面自检，交付后自己再写一份独立实现复算。

页面的自检负责回归，独立复算负责抓第一版的错。

两个都要有。

七、准备环境：打开码道 Web

浏览器打开码道 Web 版： https://devcloud.cn-north-4.huaweicloud.com/chat?source=dmzntgwlb&sourcead=dmzntgwlb1&invitecode=INV-IXhxk5bwWx_qKSP1FcgSuiOEf6ruDXtjvLFiCH9nMs5dZGLapaSSylwt-cKRj5LoT3MlxikWxy8VhqplfvtQjefQOq31Tbp3R3wYP3K535Cn4XTaUzqqExKPYTWvvw4LijV14IS1torXdTGp7oyXb6SR5VxgYTg50jM ，登录后就能在对话窗口输入需求，不需要装软件。

八、总结

100W 充电器只跑出 55.5W，问题通常不在充电器。

先看线有没有 E-marker，再看线芯够不够粗，最后看线有多长。

三件事任何一件不满足，功率都会往下掉。

页面和源码在 Demo Park：https://atomgit.com/deli007/demo_park/tree/main/codearts-usbc-fastcharge-cable-lab

改天换一根线，把 5 个参数再点一遍，就能知道差在哪。