智能照明网关场景版本冻结与回退复核

围绕智能照明网关在场景下载前后的版本基线、回退包、试点窗口和异常恢复路径复核，避免一升级就把稳定场景覆盖掉。

很多智能照明问题，不是场景本身不会下发，而是现场在下载新场景前根本没有冻结旧版本。平台上改了一版，网关里又留着另一版，本地面板还在调旧分区，出了问题以后谁也拿不出一套能立刻回退的稳定基线。结果本来只是一次普通调整，最后变成整片区域的夜间投诉或交付延误。

这篇内容不重复讲 可寻址照明网关场景下载审核 的三端一致性回归，而是聚焦“下载前后版本怎么冻结、异常时怎么回退”。前者更偏验证结果，这篇更偏控制动作和风险边界。

什么情况下必须先做版本冻结

• 网关固件刚升级、平台刚更新，准备重新下发场景。
• 分区名称、模块映射或回路归属刚调整过，旧场景已经不再完全可信。
• 节前、移交前、夜景照明切换前，现场不允许长时间反复试错。
• 多个网关、多个楼层或多个分区准备批量更新，任何一个点出错都会扩大影响。

如果当前连模块地址、端口归属和回路映射都没锁清，先去处理模块映射问题，不要直接跳到版本冻结。

一次可回退的场景冻结，至少要锁住五样东西

1. 网关版本：固件版本、配置版本和本地参数版本。
2. 场景文件版本：本次准备下发的文件名、导出时间和变更人。
3. 分区命名基线：平台分区、本地面板分区和图纸分区的统一口径。
4. 旧版回退包：不是只保留一张截图，而是保留可重新导入的旧场景版本。
5. 试点与回退窗口：先在哪个网关、哪组回路试点，出错后多久内必须恢复。

少任何一项，后面都很容易出现“知道改过，但回不去了”的局面。

下载前先做哪几步

先冻结旧版，不要先覆盖

• 下发新场景前，先把当前稳定版本导出、编号并单独归档。
• 旧版文件、网关截图、本地面板版本和主要分区清单要放在同一条记录里，不要分散在聊天记录和电脑桌面。
• 如果现场已经有多个所谓“终版”，就先别急着更新，先把唯一可追溯版本锁定出来。

再做试点，不要整片同时推

• 优先选择一个边界清楚、影响可控的网关或分区做首轮下载。
• 首轮试点通过后，再按楼层、区域或网关批次扩展，不要一键全站推送。
• 试点期间要同时验证平台、本地面板和现场灯具，而不是只看平台返回成功。

先写清回退条件，再允许下载

• 哪些现象算可接受的小问题，哪些现象一出现就必须立刻回退，要提前定清。
• 如果出现分区错控、批量漏动作、面板状态错乱或回写丢失，原则上不应继续硬推下一批。
• 回退不是失败，而是受控调试的一部分。没有回退条件，现场通常会为了保面子继续往前顶。

下载后先复核什么

先看版本是否真的落到了目标网关

• 平台显示已下发，不代表网关已经按目标版本生效。
• 复核时要确认网关版本号、场景包编号和本轮记录中的目标版本一致。
• 若同一分区同时存在旧版和新版表现，优先怀疑版本未完全生效，而不是先怀疑灯具故障。

再看高频场景，不只测全开全关

• 真正容易暴露问题的，通常是半亮、夜景、保洁、会客或跨区联动场景。
• 这些场景比“全开/全关”更能看出分区命名、地址映射和场景参数是否真正一致。
• 发现问题后，先冻结现场状态和当前版本，不要一边继续试别的场景、一边回忆上一版效果。

最后看回退是否可执行

• 回退包是否能正常导入，而不是名义上“存过一份”。
• 回退后平台、本地面板和现场灯具是否能回到上一轮稳定状态。
• 回退动作执行后，记录里要能说清恢复到了哪一版、谁确认通过、哪些分区仍待观察。

它和场景下发审核、基线归档的边界怎么分

• 可寻址照明网关场景下载审核 更偏“新场景执行结果对不对”。
• 这篇更偏“下载前有没有冻结旧版、下载后能不能按记录回退”。
• 如果已经进入更广义的参数、趋势和版本包归档，可继续联查 调试基线与趋势归档方法。
• 如果问题已经进入移交前唯一版本锁定，则再联查 移交资料包版本冻结方法。

最容易出现的假闭环

• 只保留最新场景文件，不保留可导入的旧版回退包。
• 平台显示下载成功，就默认网关和本地面板已经同步。
• 只测全开全关，不测高频使用场景。
• 发现首个网关异常后还继续批量推送下一批。
• 回退过一次，但没有把当前稳定版本重新编号和归档。

资料怎么留，后面才真正可回退

• 本轮场景下载与结果验证，继续使用 智能照明网关场景下发记录。
• 地址、分区和设备基础映射问题，继续用 DALI 地址分配记录 和 图纸核对清单 先收口。
• 如果已经涉及多轮版本对比、参数包和趋势归档，补到调试基线包里，不要只留最终截图。

关联页面

• 场景执行与三端一致性，继续看 可寻址照明网关场景下载审核。
• 模块地址、端口编号和受控回路边界，继续看 照明控制模块地址标签与回路映射复核。
• 整体安装、送电和联调顺序，继续看 照明系统安装、送电与调试要点。