与浏览器共享进程池，内存随标签数量叠加，主线程被其他页面占用时连带受影响。
如果你也在处理WhatsApp网页版，这篇可以顺手对一下。 如果你也在处理WhatsApp网页版，这篇可以顺手对一下。 相关的坑WhatsApp网页版 里列得比较细，可以对照看看。 相关的坑WhatsApp网页版 里列得比较细，可以对照看看。
基线较低,但波动幅度更大。
内存台阶不自行回落,只有重载才能拉回基线。
长时间运行后占用普遍到四百兆以上。
借用浏览器通知通道，标签被系统挂起时长连接休眠，通知改由系统层补发且顺序无保证。
浏览器关闭后通知能力完全消失。
补发延迟在数秒到数十秒之间波动。
没有本地版本概念，服务端构建切换后立即生效，无法停留在旧构建，只能强制重载提前或延后一次。
新构建引入的问题会更直接地暴露出来。
因此网页端更容易遇到临时性异常。
常驻一个独立进程，内存基线通常高于单个浏览器标签，但长时间运行后抬升幅度明显更小。
优势不在单次读数,而在波动幅度。
不与其他页面共享主线程,卡顿互不传染。
八小时轨迹近乎平直,台阶极少出现。
在系统层注册通知通道，不依赖任何窗口存活，关闭主窗口但保留托盘图标时通知仍然可用。
权限被撤销后静默失败,界面无提示。
排查方式是直接查看系统通知授权状态。
更新由客户端自查，可延迟也可跳过，滞后反而形成一层缓冲，多数新版本问题在缓冲期内被修复。
代价是版本落后时可能出现协议兼容提示。
版本落后不会阻断使用,只影响新功能可见性。
| 能力项 | 网页端 | 桌面端 | 判定口径 |
|---|---|---|---|
| 系统通知 | 浏览器代理 | 原生通道 | 关窗后是否仍可收到 |
| 离线通知 | 不可用 | 托盘常驻可用 | 进程是否仍在运行 |
| 开机自启 | 不支持 | 支持 | 系统启动项是否注册 |
| 席位占用 | 独立一席 | 独立一席 | 席位池余量 |
| 更新节奏 | 即时生效 | 可延迟 | 构建摘要是否同步 |
◆ 两者共享同一席位池与同一份消息流，各自维护游标，并不存在谁代理谁的关系。◆
消息经由服务端分发,两端各自补齐,互不代理。
一端在线另一端离线,不影响对方的消息完整性。
席位池容量固定,接入形态越多可扩展余地越小。
把桌面端当作网页端的替代品,是常见的认知偏差。
[核心疑难] 并行接入合法，冲突只出现在席位耗尽时。
[底层诊断] 席位各自独立，第三台之后进入排队，已接入者不受影响。
[核心疑难] 稳定性差异来自进程隔离与更新节奏，而非性能强弱。
[底层诊断] 不与其他页面共享主线程，更新也有缓冲期，两因素叠加。
[核心疑难] 网页端无本地版本概念，构建切换不可拒绝。
[底层诊断] 只能通过强制重载提前或延后一次，无法长期停在旧构建。
◆ 10月23日 桌面端基线更高但波动更小，八小时轨迹近乎平直
◆ 10月23日 网页端基线低，随标签叠加，主线程争用会连带影响
◆ 10月23日 两者席位独立计算，不存在镜像或代理关系
◆ 10月23日 系统通知由桌面端原生接管，不依赖浏览器存活
◆ 10月23日 网页端通知依赖标签可唤醒，关闭浏览器即失效
◆ 10月23日 桌面端更新可延迟亦可跳过，滞后形成缓冲
◆ 10月23日 网页端构建切换即时生效，新构建问题更易暴露
◆ 10月23日 两端差异多来自更新节奏错位，而非能力缺失
关于本站 · 第三方整理，官方入口以 web.whatsapp.com 为准