确认与取消的左右顺序随平台不同
别名: 确定取消左右 · Windows macOS 按钮顺序 · OK Cancel order
概念解释
确认和取消谁在左、谁在右，不是审美问题，是平台惯例（platform convention）。Windows 和许多 Web 后台把「确定」放左边、「取消」放右边；macOS 和 iOS 对话框把取消放左边、确认放右边；Android 在不同版本和材料设计阶段还改过。同一对词在不同系统里占的槽位相反。顺序随平台不同，指的是这套槽位映射本身，而不是「选一种全世界通用的」。
机制
阅读方向和动作方向被不同平台训练成相反的终点。Windows 沿用早期对话框：先给主动作，取消当退路放在后面，配合从左往右读。Mac 把确认放在阅读终点（右），取消当「还没读完就可以走」放在左，并与「前进在右」的导航隐喻对齐。手指和指针会把这套顺序编成位置记忆：在自己的系统里，那一侧就是确认。跨到相反惯例时，位置记忆比文案更快，于是点错。没有「更符合自然」的一边——两边都是被教出来的群体刻板印象。Web 应用若自己发明第三种顺序，等于对所有平台用户都不友好。
怎么研究
用同一对话框，只对换左右，在 Windows 惯用者和 macOS 惯用者两组里做限时确认。不要把文案涂掉，测的就是「位置是否压过文字」。
自变量：按钮顺序是否与被试日常 OS 一致、是否限时、确认是否破坏性。 因变量：错按率、眼动是否先看惯用侧、口头「我习惯点这边」。
只在单一 OS 的公司内部测，会得到「我们的顺序没问题」的假阴性。必须按日常 OS 分层，而不是按国籍。
边界
从上到下堆叠的移动端按钮没有左右槽，惯例改成「主动作在上或在下」——iOS 动作表把取消钉在底，材料设计常把主动作放在对话框右下。RTL 布局会镜像，但不是所有平台都镜像按钮槽，需要按目标系统查，而不是按「RTL 一律对调」。游戏主机用焦点而不是左右槽。命令行没有这张地图。
怎么落地
- 桌面应用跟随宿主 OS 的确认/取消槽，不要在 Windows 上用 macOS 顺序。
- Web 产品若主要跑在浏览器里，选一套并在全站固定，优先跟随用户当前 OS，而不是跟随设计师的电脑。
- 不要用「确定在左更符合阅读」这类普遍理由覆盖平台差异。
- 验证：找日常使用另一套系统的人完成一次限时保存。错按取消或错按确认，就是顺序没有跟他们的平台走。