应用内重复设置辅助选项会造成两套设置互相冲突的困惑
别名: 双重设置 · 应用内无障碍开关 · 设置冲突
概念解释
系统已经有「更大的文字」，应用设置里再放一个「阅读字号」；系统已经有减少动效，应用再放一个「关闭动画」。两套开关同时存在，用户就不知道听谁的，也很难预测关掉其中一个会发生什么。互相冲突的辅助设置（competing accessibility settings）指的不是「应用完全不管系统」，而是两套控制面都声称管同一件事，合成规则又不透明。
冲突的典型形态：系统开大、应用内关小，应用赢；或两套都开，字号叠乘撑破布局；或应用内开关默认关，把已经打开的系统偏好盖掉。
机制
两套设置是两个独立状态机，没有单一的合成函数。应用启动时若先读本地存储再读系统，本地的「关」会盖住系统的「开」。用户在系统里刚调完，走进应用看见还是小字，会回去再拧系统——拧不动了，因为生效的是另一份。反向也成立：应用内开了大字，系统仍是默认，用户在别的应用里又变回小字，无法形成稳定的身体策略。
第二层是排错成本。辅助功能用户本来就把一部分注意力花在「让界面可读」上。两套开关迫使他们做笛卡尔积实验：系统开/关 × 应用开/关，四格里哪一格才是他们要的。没有可见的「当前生效：系统字号 135% + 应用偏移 0」时，实验没有终点。支持成本也会变成「请把应用内那个也打开」，等于承认系统那一套被自己作废了。
怎么研究
给被试两套真实开关（系统 Dynamic Type + 应用内字号；系统 Reduce Motion + 应用内「减少动画」），任务是「让正文达到可读、让动画停」。记录路径：先动哪一套、是否来回改、最终四格中落在哪一格、能否口头解释合成规则。再加一档：界面上明确写出「跟随系统，当前 135%」。
自变量：是否有第二套开关、默认值是否覆盖系统、是否显示合成结果。 因变量：达到目标状态的步数、错误归因（怪系统还是怪应用）、设置回滚次数。
边界
内容型偏好不是冲突：字号跟随系统，但「衬线 / 无衬线」「夜间仅内容区变暗」可以留在应用内，因为系统没有对应项。无障碍快捷开关（一键把对比、动效、字号拉到该应用的安全组合）如果明确是「在系统值上再加一层临时档」，并且退出即还回系统，就不算平行状态机。浏览器自己的缩放与系统字号叠加是平台行为，应用不该再塞第三套。车机、手表上系统项很少，应用内开关可能是唯一控制面，谈「冲突」要先确认系统真的提供了同类项。
怎么落地
- 系统已有的项不要再做同名开关；要做「比系统更大」就做成可见的偏移，并写明「当前 = 系统 × 偏移」。
- 默认值必须是「跟随系统」，禁止出厂为「中 / 关」去盖掉用户已经打开的系统项。
- 设置页把生效中的系统值读出来给人看，而不是只放应用自己的三段式。
- 验证：系统字号开到最大，安装应用（或清本地存储）后打开。若正文变回中等，就是默认值在覆盖。再把应用内开关拧到最小，看能否压过系统——能压过且无说明，就是两套在打架。问没参与开发的人「现在听谁的」，答不上来即冲突成立。