跨端动画发布前检查构建和回退

+## 回退要和发布包一起验证

关闭动画并不等于只隐藏元素，还要确认焦点、点击和布局保持可用。发布构建中的资源路径、开关默认值和平台能力都可能不同，因此检查必须在真实安装包里走完一次。
+

把判断放回具体操作里

讨论跨端动画发布前检查构建和回退时，先别急着给方案贴好坏标签。我会先把操作拆成几个看得见的步骤：用户或调用方从哪里进入，哪一段负责准备数据，哪个环节真正触发处理，结果又在哪里被使用。这样做不是为了画一张完整流程图，而是为了避免把不同层的问题混在一起。一个现象发生在界面上，原因可能在资源准备；一个错误出现在最后一步，也可能是前面传入的状态已经不对。先把范围收小，后面的检查才有意义。

每次修改只保留一个明确目的。比如本轮只确认一个参数是否生效，就不要顺手改掉布局、日志和依赖版本。改动多时，即使结果变好了，也很难知道是哪一项起作用。能够复现的操作路径比一段笼统的结论更可靠：入口是什么，使用了什么公开样例，预期看到什么，异常时又该看到什么。记录这些内容不需要长篇描述，但不能只写“已验证”。

先处理会影响可用性的情况

排查顺序应当贴近使用者感受到的风险。内容无法读取、按钮没有反应、任务不能退出，这些比局部效果不理想更该先处理。遇到异常时，先保住可访问的内容和可恢复的状态；不能确认原因，就让系统停在一个能解释的状态，而不是反复尝试同一种操作。错误提示也应说明下一步可做什么，别把内部细节直接丢给使用者。

日志和截图只保留排查需要的最小信息。版本、阶段、错误类别、持续时间通常足够；页面正文、账号标识、输入内容不应为了方便而收集。若需要对比两次结果，就固定样例和操作顺序。条件一变，观察到的差异可能来自设备、缓存或环境，而不是代码本身。

改动后再看边界是否被碰到

修复不能只看原问题是否消失，还要回到相邻场景确认没有引入另一种断裂。输入为空、资源缺失、开关关闭、操作被中断，都值得用短路径走一遍。这里不必追求一次覆盖所有组合，先选与改动最接近的几种状态，再把尚未验证的部分写清楚。无法下结论时直接保留不确定性，比补上一句听起来完整的判断更诚实。

最后把结论落在可以执行的地方：保留什么检查、删除什么临时处理、下次出现相同症状先看哪个信号。这样这篇记录才不会变成一次性的说明。它不承诺所有环境都会得到相同结果，只给后来处理同类问题的人留下一条可重新走通的路径。

动画在调试环境正常，不代表发布构建也一样。部署前确认构建模式、资源打包、特性开关和异常回退；尤其是依赖平台能力的渲染效果，要在实际发布包里验证。

final motionEnabled = MediaQuery.of(context).disableAnimations == false;
return motionEnabled ? const AnimatedLogo() : const StaticLogo();

配置变更应有默认值和回退值，避免远端配置缺失导致页面无法进入。发布日志只记录版本、错误类别和聚合性能信息，不记录用户页面内容。