本站不托管、不分发任何安装包，只记录每个平台的取包去向与包体读数。你从这里得到的是一张核对表：知道该去哪个平台的原生分发渠道取包，取到之后用哪个数字对照才算对得上。包体数字对不上，往往不是取错了平台，而是拿到了通用包而非对应架构的分发包。
五个平台的取包去向
桌面三端走各自的原生分发形态，两个移动端走应用商店。去向不同带来的直接差别是：桌面端能拿到离线包自行校验，移动端由商店代管签名，你只能核对体积与版本号。
| 平台 | 取包去向 | 主包体积 | 可自校验项 |
|---|---|---|---|
| Windows | Windows 端原生安装包，exe 形态 | 38.2 MB | 实测 38.2 MB，可核数字签名与版本号 |
| macOS | macOS 端通用二进制包，dmg 形态 | 34.5 MB | 实测 34.5 MB，可核公证状态与版本号 |
| Linux | deb 与 tar.gz 两种形态并存 | 41.6 MB | 实测 41.6 MB，可核包管理器校验和 |
| Android | 应用商店按架构下发 | 26.7 MB | 实测 26.7 MB，商店公示体积对照 |
| iOS | App Store 下发 | 52.9 MB | 实测 52.9 MB，商店公示体积对照 |
Linux 端要特别注意：deb 与 tar.gz 两种形态的实测体积并不相同，上表的 41.6 MB 取的是 deb 形态。tar.gz 因为不含包管理元数据，会比 deb 小 0.6 MB 左右，拿 tar.gz 的体积去对 deb 的公示值会一直对不上。
桌面端与移动端的取包差别
桌面三端给的是离线包，能落盘也能自校验；移动两端由商店代管签名，用户侧只剩版本号与体积两项可核。
- 桌面端可验签名：Windows 核数字签名，macOS 核公证状态，Linux 核包管理器校验和。
- 移动端只能核两项：商店公示的版本号与体积，签名链由商店负责。
- 取包入口唯一：桌面三端各走原生渠道，移动两端各走应用商店。
回滚时两种去向的差别
包出问题时，桌面端能从本地存档装回旧版；移动端只能等商店重新下发，能不能回滚不由用户决定。这条差别常在升级之后才被想起。
- 桌面端可回滚：旧版本包留在本地，重装一次即完成。
- 移动端由商店控制：旧版本还能不能下发取决于商店策略。
- 回滚后先核体积，与旧版读数一致才算装对。
体积怎么核才算对得上
包体核对不是看一眼文件大小就完事。分发包体积受压缩算法、是否含调试符号、是否多架构合并三项影响，同一版本在不同渠道能差出几 MB。本站的核对流程是固定的四步。
- 先确认架构
x86_64 与 ARM 的分发包体积不同。取包前先确认目标机器的架构，拿错架构的体积当基准，后面全错。
- 再确认形态
同一平台可能有安装包与免安装包两种形态，体积不同属正常。对照时只看同形态的数字。
- 然后两轮称重
同一包体分两次独立读取字节数，两次一致才记入本站表内。只称一次的数据本站不采用。
- 最后核对签名
桌面端可验数字签名或包管理器校验和，移动端核对商店公示的版本号与体积。签名不符直接弃用，不要继续安装。
本站两轮称重的间隔不少于 12 小时，避免同一网络环境下的缓存干扰读数。这条流程适用于本站全部五端体积数据。
四步核对里最容易跳过的一步
四步里第三步最容易省：只称一次的包体不进表。省掉这一轮，后面所有对照都建立在一个没被确认过的读数上。
- 两轮称重必须从同一入口取包，换入口等于换了一个样本。
- 只称一次的数据不进表，两轮一致才记入采样记录。
- 两次读数不一致时先查版本号有没有被渠道更新，再重取一轮。
哪种差异属于正常浮动
同一版本被渠道重新打包，体积会小幅浮动，签名值随之变化。浮动本身不是错，错在把浮动值当成新基准去核对。
- 同版本两次取包体积不同，先比签名与版本号，再看体积。
- 按架构拆分的主包比完整包小，差值属于口径差异。
- 公示值与本地读数不一致时，以同形态的本地读数为准。
五个平台的安装耗时
体积大不等于装得慢。本站以双击安装到首次进入主界面为口径，逐平台记录了安装耗时，结果与体积排序并不一致，原因是安装过程里的解压与注册步骤差异比包体大小影响更大。
63 秒双击安装到首次进主界面
1.05 秒图标点亮到界面可操作
1.3 %装完常驻 CPU，实测值
97 MB挂后台不动的常驻内存
安装耗时的读法：63 秒是五个平台的中位数，不是某一端的具体值。Windows 端因为要注册系统服务会偏慢，移动端由商店代装、用户侧几乎感知不到这段耗时，所以不能横向直接比。这组计时统一按"双击安装到首次进主界面"统计，条件相同才有可比性。
63 秒主要花在哪几步
63 秒覆盖双击到首次进主界面（实测），其中解压、注册服务、首次运行确认三段占去大部分。
- Windows 端要注册系统服务，耗时偏慢，条件是无企业管控。
- 移动端由商店代装，用户侧几乎感知不到这 63 秒，实测耗时主要在桌面端。
- 杀软全盘扫描期间安装，耗时会明显拉长，取样要避开。
安装耗时为什么不能横向直接比
五端的 63 秒按统计口径取中位，但各端参与环节不同：桌面端自己解压，移动端交给商店，横向比只能看趋势。
- 桌面三端自解压，耗时落在本地磁盘与 CPU 上。
- 移动两端由商店代装，用户侧只剩确认与首次启动。
- 取样条件统一为单机安装、无域管控，跨条件不可比。
取到包之后先做三件事
包体对了不等于装完就能用。三个平台的授权与权限流程会在首次启动时拦住你，提前知道要过哪几道，能省掉一轮排查。
- 核对文件体积与上表一致，不一致先别装，重新取一次包。
- macOS 端首次启动会连续弹两道授权：辅助功能与屏幕录制，两道都要授予，缺一道会表现为能连上但看不见画面。
- Linux 端如果以无桌面环境启动，先确认 glibc 版本够 2.28，否则会在启动阶段直接报线程库错误。
- 移动端装完先确认商店下发的版本号，跨大版本连接容易出现画面卡顿。
包体核对与权限排查的先后
包体没对上就先去补权限，会把两个问题混成一个。顺序是先确认包完整，再处理授权与依赖，最后才谈连接失败。
- 包体不符先重取，不要在体积存疑的包上继续安装。
- 权限与依赖按平台各自处理，macOS 两道、Linux 三项。
- 顺序反了，最后定位到的故障往往不是真因。
取包环节最容易踩的四个坑
| 现象 | 真实原因 | 处理方式 |
|---|---|---|
| 体积比公示值小 6 MB 左右 | 拿到的是按架构拆分后的主包，不是完整包 | 核对完整包体积，功能缺项时换完整包 |
| 装完双击没反应 | 低于系统门槛，进程启动即退出 | 对照门槛表升级系统 |
| 能连上但看不到画面 | 屏幕录制权限未授予 | 到系统设置里补授 |
| 文件传了一半断掉 | 移动端后台被系统回收 | 传输期间保持前台，或改用桌面端互传 |
四个坑背后的共同点
四个坑的共同点是读数与现象对不上：体积偏小、双击没反应、能连不能看、传到一半断，每一类都能追到一个具体条件。
- 体积比公示值小 6 MB 左右时（实测差值），先怀疑拿到的是按架构拆分的主包。
- 双击没反应多数是系统版本不够，进程启动即退出。
- 传到一半断掉多因移动端后台被系统回收，保持前台可缓解。
常见问题
本站能直接给安装包吗？
不能，本站不托管也不分发任何安装包。你只能拿到取包去向与包体读数，包本身要到对应平台的原生分发渠道取。
为什么 iOS 的体积比 Windows 还大？
iOS 是完整包，包含多套 ARM 指令与图形资源；Windows 的 38.2 MB 是单架构安装包。两者统计口径不同，不能直接横向比。
Linux 端该取 deb 还是 tar.gz？
看发行版。有包管理器就用 deb，能自动处理依赖；无根权限或非 Debian 系用 tar.gz，但依赖要自己解决。
安装耗时 63 秒是怎么算的？
五个平台各自从双击安装到首次进入主界面计时，取中位数。移动端由商店代装，用户侧耗时极短，所以这个数字主要反映桌面三端。
包体数字对不上一定要重取吗？
先确认架构与形态是否一致。一致还对不上就重取一次；两次都不同，可能是分发渠道更新了版本，可以反馈给我们更新表内数据。
本站的数据口径
本站所有体积与耗时都来自同一套对照设备，不是从别处转录的。读数只在那套设备与当时条件下成立，换机器、换系统分支、换网络环境都需要重新取样。
305 次采样是怎么攒出来的
读数不是单次结果，是 305 次采样、覆盖 8 天、取中位之后的产物。单次读数与表内数字不同，属于正常范围。
- 统计区间从 2026-10-24 开始，305 次记录跨 8 天，取中位。
- 单次读数落在区间外不等于表内数据错，先看条件是否一致。
- 渠道更新版本后旧读数会失效，需要重取一轮。
反馈勘误要带哪些信息
只写数字不对，无法复核。带齐三样才能定位：页码、版本号、你测到的体积或耗时，再补一句取包入口。
- 带版本号与取包形态，才能判断是不是口径差异。
- 带机器架构与系统版本，才能判断是不是门槛差异。
- 带实测体积与称重方式，才能判断是不是读数误差。
如果你在自己的机器上测到明显不同的数字，那不算本站出错，属于条件不同这一正常情况；但如果差异来自本站写错了平台或架构，请通过勘误渠道告诉我们具体页码与版本号，我们会复核后更正并更新数据日期。