更新通道与提交
ZundaLink 的更新内容可能按机台、账号和更新通道分别下发。页面上看到的版本号和可用内容以当前机台实际返回为准。
常见通道含义
管理员可能会为机台选择以下类型的通道：
| 通道 | 常见含义 |
|---|---|
all | 接收服务允许的全部更新 |
main | 接收公共更新和本机台相关更新 |
only-me | 只接收本机台提交或指定给本机台的更新 |
| 仅公共更新 | 只接收管理员确认的公共资源 |
实际可用名称、发布时间和适用范围以管理员公告为准。不要自行修改机台的隐藏配置来切换通道。
更新应用流程
- 确认机台当前处于 ZundaLink 网络路径，并记录当前版本。
- 在待机页或管理员指定页面查看下载进度。
- 大型更新可能拆分为多个包；必须等待全部包完成。
- 下载完成后按公告重启或等待自动应用。
- 进入常用页面测试资源、登录、记录和相片。
如果更新包尚未全部完成，可能暂时缺少图片、音频或曲目，这是等待状态，不要立即回滚。
群组经验：大包、分支和版本号
聊天中的现场反馈反复出现三类误判：
- 看到某个更新包“已下发”就认为所有拆分包都完成；
- 看到别人能看到内容就认为自己的机台也必须能看到；
- 看到屏幕版本号没变就认为更新失败。
实际排查时，请同时查看分支、订单选择、黑名单、每个安装项、磁盘空间和最后上报时间。大型包可能需要很长时间下载和校验；到发布时间后仍应等待安装项完成，再在机台空闲时按公告进行冷重启或热重载。
若两台机台结果不同，先逐项比较配置和进度，不要同时修改两台机台。若更新后仍缺少资源，保留订单名、安装项名、时间和错误画面，先不要删除下载缓存。
群组经验：不要用总进度替代安装项状态
多安装项订单可能按项目依次下载、校验、释放和应用。现场看到一个安装项变绿、总进度达到 100% 或页面出现“下载完成”，都不能替代逐项检查。应打开订单详情，确认每个安装项的状态、发布时间、校验结果和最近更新时间，再确认运行分支、挂载和目标内容。
如果状态仍在变化，先等待；如果所有安装项的时间、状态和最后上报长时间不变，才按故障流程报告。不要因第二个安装项暂时没有新文字就重启、重建同名订单或删除缓存。
群组经验：公告要求关闭热重载时要按公告执行
现场曾出现更新包已经下载，但热重载保持开启后出现挂载/重启循环的反馈。这里要区分“允许热重载”的能力开关、“执行一次热重载”的动作和某一批更新的应用要求。当前发布说明要求关闭时，应：
- 记录原开关值、当前分支、订单进度和最后上报；
- 确认机台空闲后关闭要求关闭的开关；
- 等待全部安装项完成，再按页面提示执行一次冷重启或热重载；
- 重启后回读订单、挂载、运行分支和内容；
- 只有当前公告允许时才恢复旧开关值。
不要把历史批次的开关策略当成永久规则，也不要在循环重启时同时修改订单和网络。
群组经验：网页能打开不代表机台上传链路正常
现场反馈中出现过网页正常、机台却上传很慢或只有一台机台传不上。网页浏览器、机台健康和上传服务是三层不同链路。对比两台机台时，应记录同一时间的网络检查、最后上报、运行分支、磁盘、上传缓存索引和订单状态。
网络代理、网关、限速和分支一次只改变一个条件；已有数据先下载上传缓存留档，不要靠重复游玩测试速度。上传恢复后还要回读记录、成绩和缓存，不能只以网页打开或一条绿色提示作为结论。
凌晨维护窗口
历史群公告曾提到可能在凌晨维护窗口更新控制组件。该时间只属于当时公告，不代表固定承诺；维护期间出现页面或控制行为变化时，先暂停新订单和恢复操作，待窗口结束后刷新健康数据。
提交更新建议
- 提交曲目或资源建议时提供清晰的名称、编号、来源和复现方式；
- 自制内容必须确认本地运行正常，并使用常见压缩格式打包；
- 不要提交包含账号、个人信息或未授权资源的包；
- 不要在公开群组传播管理员尚未发布的包；
- 提交后等待人工审核，不要通过重复发送催促下发。
更新失败
请记录：机台编号、当前版本、更新包编号、每个安装项的状态、下载进度、错误画面和发生时间。随后阅读恢复与回滚，不要同时插入多个版本的 U 盘。