您触发 Alert.alert() 在 React Native 中，测试 iPhone 和 Android，感觉完成了。然后有人打开 Web 构建，什么也没有出现。或 Android 忽略了您在 iOS 上使用的提示流程。或应用程序的两部分同时弹出警告，用户陷入了一个混乱的对话堆栈。
React Native Alert 的形状是这样的 API。它适合快速、原生确认流程。它也很窄、平台依赖且容易在生产环境中滥用。好消息是，快乐路径很简单，粗糙的边缘一旦您知道它们在哪里，就会变得可预测。
目录
使用 Alert.alert 展示简单消息
对于基本的通知 UI 来说 React Native 警告 仍然是最快的工具。您导入 Alert，调用 Alert.alert()，平台渲染一个原生对话框。无需额外的依赖，
，无需自定义模态状态，
import React from 'react';
import { View, Button, Alert } from 'react-native';
export default function ProfileScreen() {
const showSavedMessage = () => {
Alert.alert('Profile updated', 'Your changes were saved successfully.');
};
return (
<View style={{ padding: 24 }}>
<Button title="Save profile" onPress={showSavedMessage} />
</View>
);
}
最简单的版本只需要一个标题和一个消息:
一张手机屏幕上的简单警告消息的近景图。
A Alert.alert(title, message) 因为它保持原生。操作系统处理视觉呈现、按钮角色和标准交互模式。对于许多团队来说，这就是正确的权衡。
几个实用的规则有助于保持它有用：
- 使用直接标题. "上传失败"比"通知"更清晰。
- 保持消息短. 警告是为了立即上下文，而不是长篇大论。
- 保留警告为阻塞信息. 如果用户可以继续不中断，弹出提示通常是一个更好的选择。
保持警告小而果断。如果用户需要阅读一段话，弹出对话框可能不是正确的UI。
团队滥用它的地方
最常见的错误是使用警告作为通用消息系统。如果每个成功动作都显示一个阻塞对话框，应用程序很快就会感到沉重。原生警告在停止用户的原因时最强大。
另一个错误是将警告过于紧密地与组件内部耦合。一个小按钮处理器在一开始是可以接受的，但一旦流程跨越多个屏幕和异步动作，散布在各处的警告调用就难以推理了。这就是为什么团队往往在早期标准化周围的用户体验模式，同样他们标准化的原因 React Native 应用程序中的启动屏幕行为.
简单警告的好用例
| 场景 | 为什么 Alert 工作 |
|---|---|
| 在关键设置更改后保存确认 | 用户需要明确的确认 |
| 会话超时警告 | 消息紧急且行动指向 |
| 未支持的功能通知 | 应用程序需要停止并解释 |
如果您需要用户选择路径，下一步是 buttons 数组。 这就是 Alert.alert() 变成了一种简单的提示框外的东西。
确认用户输入的对话框
大多数实际的警告使用不是为了提供信息。它是关于做出决定。删除草稿，丢弃更改，注销，重试失败的请求。就是在那里数组起作用。 buttons 常见的确认对话框如下：
一位人在木质桌子上的控制台上按下了红色和绿色按钮。
import React from 'react';
import { View, Button, Alert } from 'react-native';
export default function DangerZone() {
const confirmDelete = () => {
Alert.alert(
'Delete item',
'This action cannot be undone.',
[
{
text: 'Cancel',
style: 'cancel',
},
{
text: 'Delete',
style: 'destructive',
onPress: () => {
console.log('Deleting item...');
},
},
]
);
};
return (
<View style={{ padding: 24 }}>
<Button title="Delete item" onPress={confirmDelete} />
</View>
);
}
是用户看到的标签。
text当按钮被点击时执行的函数。onPress传达意义，尤其是在iOS中。style选择减少错误的按钮标签
__CAPGO_KEEP_0__让你可以写‘OK’然后继续。通常这还不够。标签应该描述结果，尤其是对于有害的动作。
The API allows you to quickly write “OK” and proceed. However, this is often insufficient. The label should clearly describe the result, especially for actions that have destructive consequences.
比较这两个集合：
- 弱标签: 确定/取消
- 更好的标签: 删除项目/保留项目
第二个版本消除了不确定性。这在破坏性流程中很重要，尤其是在出现错误或异步操作后弹出的警告时更为重要。按钮文本应该回答，“如果我点击这个按钮会发生什么？”
如果您的流程从用户处收集文本，一个干净的伴侣模式是将警告与明确的表单输入配对，例如一个专门的 React Native TextInput 实现 而不是试图过度扩展对话框。
什么按钮样式实际上意味着
The style 字段是语义的，而不是装饰性的。用它来传达意图。
| 样式 | 何时使用 | 注意 |
|---|---|---|
default |
正常操作 | 适合中立选择 |
cancel |
退出或后退 | 对于安全确认非常重要 |
destructive |
不可逆操作 | 在 iOS 中可视化突出 |
Gluestack 的技术benchmarking 表示，平台约定在这里很重要。 iOS 将 取消 按钮放在左边 确认 在右侧，Android则反转了这一点。违反这些约定会导致用户混淆度指标大幅上升， 25% 在全球市场中， 45% 生产应用程序中缺乏必需的取消或退出路径的关键路径警报的比例很高，这会增加不可逆转的操作和支持请求的数量。同样的分析还指出，自定义警报实现通常会在阅读顺序方面失败于辅助技术。请参阅 Gluestack Alert 指南.
实践规则： 每个有害警报都应包含明确的退出方式。
有关按钮配置和交互流程的更详细视觉教程，请参阅此短片。
一个更安全的确认模式
当操作敏感时，回调函数应保持简单：
Alert.alert(
'Sign out',
'You will need to log in again to continue.',
[
{ text: 'Stay signed in', style: 'cancel' },
{
text: 'Sign out',
style: 'destructive',
onPress: async () => {
try {
await signOut();
} catch (error) {
Alert.alert('Sign out failed', 'Please try again.');
}
},
},
]
);这种模式乏味，但这正是它的好处。警报应该保持可预测。
处理各个平台的特性和输入提示
A生产环境中的常见错误看起来像这样。同样的 Alert.alert() 调用在iOS上正常，Android上正常，但一旦团队发布了Web版本，就会失败。API看起来在code中是统一的，但平台却不一样。
iOS和Android并不完全匹配
按钮顺序是团队最容易踩的陷阱。React Native将警告委托给操作系统，因此用户看到的是本机约定，而不是React Native抽象。这通常是正确的权衡，但这意味着按钮标签必须在平台之间保持不明确。
提示支持是更大的不匹配。iOS支持 Alert.prompt 轻量级文本输入。Android不支持。如果流程依赖于在警告中输入密码、重命名项目或捕获短笔记，那么该流程在iOS上才是可行的，除非您构建一个单独的路径。
尽早使用平台检查，而不是假装API一致。
import { Alert, Platform } from 'react-native';
export function requestPassword() {
if (Platform.OS === 'ios') {
Alert.prompt(
'Enter password',
'Please confirm your password.',
[
{ text: 'Cancel', style: 'cancel' },
{
text: 'Continue',
onPress: (value) => {
console.log('Password entered:', value);
},
},
],
'secure-text'
);
return;
}
Alert.alert(
'Confirmation required',
'Please continue to the next screen to confirm this action.',
[{ text: 'OK' }]
);
}Android的回退选项不太方便，但仍是更安全的选择。在生产环境中，重定向到专门的屏幕或受控模态更容易测试、更容易本地化、更容易使其可访问，而不是构建在不支持行为上的假提示。
Web支持需要自己的计划
React Native的官方AlertAPI文档列出了对iOS和Android的支持情况，在React Native Alert参考文档中 iOS和Android的按钮顺序不一致如果您的应用程序还在 React Native Web 或 Expo Web 上运行，未包装的警告会导致 web 构建中的交互路径完全失败（关于警告支持的 React Native Web 问题讨论).
这并不是一个边缘案例。团队经常在移动 QA 通過后才发现它，因为浏览器覆盖通常晚于此。
除非您添加一个包装器，否则将原生 Alert 视为移动设备独有。
该包装器也会帮助您的团队在比较混合运行时跨平台的权衡时，特别是在 React Native 与 __CAPGO_KEEP_0__ 架构比较中 React Native 与 Capacitor 架构比较.
对于许多应用程序，第一个可行的解决方案是对平台分离进行一个小的抽象：
该模式解决了紧急支持缺口，但它有局限性。
import { Alert, Platform } from 'react-native';
type ConfirmOptions = {
title: string;
message?: string;
onConfirm?: () => void;
onCancel?: () => void;
};
export function confirmDialog({
title,
message,
onConfirm,
onCancel,
}: ConfirmOptions) {
if (Platform.OS === 'web') {
const result = window.confirm(message ? `${title}\n\n${message}` : title);
if (result) onConfirm?.();
else onCancel?.();
return;
}
Alert.alert(title, message, [
{ text: 'Cancel', style: 'cancel', onPress: onCancel },
{ text: 'OK', onPress: onConfirm },
]);
}它几乎没有控制样式、焦点行为或分析钩子的能力。它是简单确认的合理安全网，但不是需要可访问性审查、警告队列或在移动和 web 上保持一致行为的流程的最终答案。 window.confirm 何时使用自定义模态而不是警告
原生警告对话框强大，因为它们是有限的。同样的局限性就是为什么它们很快就会停止成为正确工具的原因。
关于警告支持的 React Native Web 问题讨论
如果您需要 品牌、布局控制、图标、表单字段、自定义间距、动画时序或跨平台视觉一致性,就不要再与 API 抗争了。使用自定义模态。
Native alert 的限制您无法 code
您无法让它 Alert.alert() 看起来像您的设计系统。那样是有意为之的。React Native 将渲染交给操作系统，因此您继承了原生外观和原生约束。
这在您想要快速确认时是好的。但是，当产品要求任何以下内容时，这就不好了:
- 带有 logo、辅助文本和自定义层级的品牌确认对话框 模态内的多字段表单
- 多字段表单 在模态框内
- 更丰富的销毁流程 带有复选框确认
- 评级提示或评论请求 带有星星、插图和自定义按钮
一旦那些要求出现，原生警告就变成了死胡同。
简单的决策过滤器
使用 React Native 警告 当对话框是：
| 使用原生 Alert | 使用自定义模态 |
|---|---|
| 短消息 | 高级或结构化内容 |
| 一到三个基本操作 | 表单字段或嵌入组件 |
| 原生平台外观是可接受的 | 视觉一致性在各个平台上很重要 |
| 您希望实现最快的方式 | 您需要布局和动画控制 |
自定义模态对您的移动和 web 构建需要相同行为时也很有帮助。您可以集中化一个对话组件而不是永久为每个平台特殊处理。
当您开始希望 Alert 有“更多一个属性”时，您可能需要一个模态。
自定义模态库的好候选者
内置 Modal 组件可以工作，但许多团队选择一个像 react-native-modal 因为它添加了实用的可见性、背景行为和动画控制。
尤其适用于类似行动表单、底部抽屉或组合确认面板的流程。如果您的设计更接近菜单而不是严格的本机警报，相关的UI模式，如 Ionic行动表单 通常比尝试将警报弯曲成形更好地提供了一个心理模型。
这里有一个警告。不要仅仅因为它看起来更好就用自定义模态替换每个警报。native警报仍然在速度、熟悉度和低实现风险方面占据了优势。使用模态是因为交互需要它，而不是设计团队讨厌系统chrome。
可靠的React Native警报生产模式
一个删除请求失败，重试处理器触发，会话过期检查在同一时间运行。没有明确的警报策略，用户可能会被重叠的对话框、丢失焦点或web上无效的操作打击。通常这些bug来自架构，而不是__CAPGO_KEEP_0__调用本身。 Alert.alert 这些问题通常来自架构问题，而不是API本身的调用。
直接
Direct Alert.alert(...) A delete request fails, the retry handler fires, and the session-expired check runs at the same time. Without a clear alert strategy, users can get hit with overlapping dialogs, lost focus, or a no-op on web because API is not implemented there. Those bugs usually come from architecture, not from the API call itself.
A 全球式的警告服务解决了这个问题。使用 Redux、 Zustand 或 React Context。存储选择的重要性不如契约。警告请求进入一个队列，同一时间只有一个对话框可见，web 可以通过相同的界面切换到一个基于模态的 fallback。
开发者讨论警告抽象模式时指出，结构不良的应用程序经常会出现堆叠的对话框，困住用户或隐藏用户需要采取的行动，有时会影响大约 30-40% 实践中讨论的实现方法alert抽象化和对话堆栈的实现讨论 was noted earlier in the article, so do not repeat that link here). The practical fix is simple. Wrap the API once, queue requests globally, and make the renderer responsible for exactly one visible alert.
在这里是一个紧凑的 Zustand 风格的形状：
type AlertRequest = {
title: string;
message?: string;
buttons?: { text: string; onPress?: () => void; style?: 'default' | 'cancel' | 'destructive' }[];
};
type AlertStore = {
queue: AlertRequest[];
push: (alert: AlertRequest) => void;
shift: () => void;
};The UI layer subscribes to the first queue item and renders exactly one dialog. When the user dismisses it, the service removes that item and reveals the next.
实现可访问性是其实现的一部分
Native alerts give you decent defaults on iOS and Android. The moment you introduce a custom fallback for web, richer content, or Android prompt replacement, you own the behavior that the system dialog handled for free.
Gluestack關於React Native提示選項的比較指出，自定義模態實現通常會打破預期的閱讀順序 title → 提示信息 → 按钮,出现错误报告。 60% 在该区域的可访问性处理benchmark中（Gluestack的React Native Alert与Modal可访问性比较）。该具体问题很重要，因为屏幕阅读器用户依赖于可预测的结构来理解对话，然后采取行动。
对于自定义警告UI，请保持以下检查清单短且强制执行:
- 将焦点移动到对话框 当它打开时。
- 返回触发器 在dismissal后。
- 保持阅读顺序完整:标题、消息，然后动作。
- 提供明确的取消路径,尤其是在有害流程中。
- 精确标记动作. "删除"比"OK"更好，当后果很重要时。
在正常的QA过程中，警告流中的可访问性bug很容易被忽略。键盘用户和屏幕阅读器用户最先发现它们。
测试触发器，而不是平台对话框
code请求的警告与预期的警告是否一致，单元测试应该验证这一点。它们不应依赖于本机对话框运行时。
一个常见的Jest模式如下:
import { Alert } from 'react-native';
jest.spyOn(Alert, 'alert').mockImplementation(() => {});
it('asks for confirmation before deleting', () => {
triggerDeleteFlow();
expect(Alert.alert).toHaveBeenCalledWith(
'Delete item',
'This action cannot be undone.',
expect.any(Array)
);
});这使得测试保持关注点在商业逻辑上，并防止由于对话框行为在测试环境外引起的挂起。它还促使团队采用一个包装器API，一旦web和Android提示限制迫使自定义fallback时，这将很有用。
客户端监控也会有所帮助。已经在React Native应用中跟踪交互故障的团队 通常在警告触发__CAPGO_KEEP_0__路径被包装在明确的错误处理中并且带有足够的上下文以便重现流程时会捕获更多的警告相关问题。 通常在 alert 触发的code路径被明确的错误处理和记录时，会捕获更多的 alert 相关问题。
对于已过了原型阶段的应用，使用以下小组规则:
在一个助手中
- 包装
Alert.alert在一个助手中 所以 Web fallback逻辑都集中在一个地方。 - 全局队列对话请求 所以只有一个警告在同一时间可见。
- 对 Android 提示支持视为缺失 并计划使用模态fallback而不是延迟分支。
- 要求取消操作 对于不可逆或有破坏性的操作。
- 在测试中模拟警告 并断言标签、回调和顺序。
- 仅在需要时使用自定义模态例如 Web 平台、提示输入或更丰富的内容。
这使得原生警告在它们有效时保持快速，而避免了当平台差异出现时将代码库绘制成死角。
