系统设置的变化应能被应用实时感知并即时响应而非需要重启
别名: 实时响应系统设置 · traitCollectionDidChange · matchMedia
概念解释
用户很少在安装应用之前一次性设完辅助功能。他们在用的中途拧字号、打开减少动效、切高对比——常常是因为此刻的光线、疲劳、前庭不适。应用若只在启动时读一次系统值，之后要杀进程才能跟上，等于把「现在」冻成「打开当时」。运行时观察系统设置（runtime accessibility setting observation）要求：系统偏好一变，前台界面在当次会话里就改，不需要重启。
这不是「应不应当继承」；是继承发生在哪一拍。启动时读了、运行时不听，用户仍会觉得设置没生效。
机制
平台把变化做成事件：Web 的 matchMedia 监听、iOS 的 traitCollectionDidChange / accessibilitySettings 通知、Android 的 Configuration 与 UiMode。布局、动效时间轴、配色必须订阅这些事件并失效自己的缓存。许多应用把字号编进启动时算好的 theme 对象，或把动画时长写进单例，订阅发生了，单例没失效，界面仍是旧的。热路径上的列表单元格如果在创建时把 font 冻进了 cell，事件来了也不会重绑。
第二层是用户改设置的情境。他们往往人在应用里，切到系统设置再切回来，或用系统的辅助功能快捷键当场切换。前台应用仍显示旧字号，会被理解成 bug 或「这个应用不支持」。要求重启还有更硬的成本：阅读器用户的虚拟缓冲区、表单里未提交的内容、会话状态，重启会丢掉。实时响应省的不是优雅，是一次破坏性的进程生命周期。
怎么研究
应用保持前台或从设置页往返，不杀进程，逐项改系统字号、减少动效、对比。记录：回到应用后第几帧开始变、哪些表面变了（导航栏 / 列表 / 已打开的模态 / WebView）、是否必须杀进程。Web 用开发者工具即时切换媒体查询。测两种往返：系统设置 app 与控制中心快捷键，延迟可能不同。
自变量：变化是否在前台发生、缓存层级（theme 单例 / cell / WebView）、平台。 因变量：无需重启即对齐的表面比例、往返后仍冻结的区域、未保存表单是否被破坏。
边界
有的底层引擎（游戏循环、自定义文本栅格）换字号等于换资源包，实时可能做不到，需要明确提示「将在下次启动生效」并避免假装已经跟了。多窗口、画中画、CarPlay 上的第二场景可能收不到主窗口的 trait 事件，要分别订阅。用户在改系统的那几秒，应用被挂起，事件在 resume 时才到——「实时」在移动端常常是「回到前台的那一拍」，不是毫秒级推送，但不能因此改成必须冷启动。服务端下发的 CSS 若在构建时写死断点，运行时监听也救不了，那是构建链问题。
怎么落地
- 订阅平台的偏好变化事件，并在回调里失效 theme、字号 token、动画时长，触发可见表面重排。
- 列表与模态不要把 font 冻在创建时；cell 复用时重读当前系统值。
- Web 用
matchMedia(...).addEventListener('change')，不要只在DOMContentLoaded时读一次。 - 验证：打开应用，不要杀进程，去系统把字号拧一档、打开减少动效，立刻回来。主列表、已打开的对话框、导航标题仍是旧的，就是只在启动时读了一次。再填半张表再改设置，确认不会被重启策略毁掉。