一天一个 vibe coding 术语课，今天讲 toast。
Toast 就是操作以后临时出现在界面上，用一句短话告诉你结果或状态，通常会自己消失的轻提示。
看一个 toast，主要分五件事：它为什么出现、出现在哪里、正在反馈什么状态、准备怎么消失，以及需不需要用户再做一个操作。
最后再补一个前端里的常见做法：把这些 toast 统一封装起来。
一、保存以后冒出来的那句话，叫轻提示
你点下保存，页面没有跳走，也没有被锁住，只在顶部或底部冒出一小块提示，上面写着「保存成功」。
你不用点确认，还可以继续编辑。过一会儿，这块提示自己就不见了。
上一篇讲 modal 的时候，我们说不要什么都弹个弹窗。这里的 modal，就是会锁住后面页面的模态对话框。
可是不弹窗，不代表什么都不提示。保存成功了、上传失败了，用户还是得知道。
那么，有些错误提示、成功提示要用什么呢？
这种短暂、轻量、不会打断当前操作的反馈，中文常叫轻提示，英文就是 toast。
toast 不是每个平台唯一的标准名称，但它确实是设计和开发里广泛使用的专业词。AI 说「这里加一个 toast」，通常就是要加这种显示一下就离开的反馈。
模态对话框会把一件事摆到用户面前，等用户回应。toast 只负责把结果送到眼前，不会抢走你正在输入的位置，也不会锁住后面的页面。
二、一个 toast 里通常放什么
文件上传完成后，右上角出现一块小长条。最重要的是里面那句「文件已上传」，这叫提示文字，英文 message。
文字旁边有时会带一个对勾、叹号或者叉号，帮助用户更快看出这是成功、警告还是失败。这是状态图标，英文 status icon。
图标只能帮人扫得更快，不能代替文字。只放一个绿色对勾，不写发生了什么，既要人猜，也可能让看不清颜色的人直接错过结果。
有些 toast 还会带一个很短的操作，比如「撤销」「重试」或者「查看」。这种操作英文常叫 action。
操作不能塞一排。toast 本来就会很快离开，用户没有时间在里面读说明、比较选项，再慢慢作决定。
根据用途不同，右边还可能有一个关闭按钮。不过没有必须立即处理的事情时，最常见的做法还是让 toast 自动消失。
三、toast 该放在哪儿
你正在桌面端编辑文档，保存以后，右上角出现一句「保存成功」。它能被看见，又没有盖住正在写的内容。
设计和开发里，常见的位置写法不止一套。
常见的六个边缘位置是：左上 top-left、顶部居中 top-center、右上 top-right，以及左下 bottom-left、底部居中 bottom-center、右下 bottom-right。
部分移动端轻提示还会直接放在顶部 top、中间 middle 或底部 bottom。
所以页面正中央并不是绝对不能放 toast。有些移动端轻提示就会短暂出现在中间。不过它最容易盖住内容，更适合「已保存」「已复制」这种内容简单、没有操作的反馈。
内容更长、带有操作，或者可能连续出现好几条时，放在页面边缘会更稳妥。
位置没有一个适合所有产品的标准答案。桌面端常见右上或右下；顶部居中更显眼，也更容易挡住顶栏下面的内容。移动端的底部提示要避开底部导航、手机系统手势占用的区域和弹出的键盘。
左上和左下也不是不能用，要看产品的导航、消息入口和阅读方向。做多语言界面时，还会用起始侧 start 和结束侧 end 代替写死的左和右。遇到从右往左阅读的语言，位置也能跟着镜像。
比选哪个角更重要的是两条：同一个产品固定一个默认位置，这个位置不能挡住主要内容和用户正在操作的控件。
放在顶部时，新 toast 从顶部加入，旧的往下移；放在底部时，方向反过来。
四、它反馈的状态，和事情有多严重是两回事
保存完成、资料更新成功这类结果，常用成功提示，英文 success toast。
请求没有发出去、文件上传失败，也可能出现错误提示，英文 error toast。这里的前提是用户看完仍然可以继续操作，或者能用一个「重试」马上补救。
事情还没失败，但有个情况值得留意，比如网络不稳定、部分设置还没生效，可以用警告提示，英文 warning toast。
只是在告诉用户一条普通状态，比如「设置会在下次启动时生效」，叫信息提示，英文 info toast。
还有些任务不是立刻完成。上传正在进行、文件正在处理时，可以出现进度提示，英文 progress toast。它通常不会按固定几秒消失，而是等任务完成以后，自己更新成成功或失败。
这些状态可以改变图标和颜色，但 toast 仍然是 toast。成功、错误、警告说的是消息含义；它是否临时出现、会不会打断操作，说的才是组件本身的行为。
五、toast 不一定都按同一个时间消失
复制成功以后，只要让人看清「已复制」就够了。这类 toast 通常倒计时几秒后自动离开，开发里常叫 auto-dismiss。
时间不能短到文字还没看完就消失，也不该长到一直挡着页面。内容越长、里面还有操作，留给用户的时间就要越充足。
上传进度不能靠猜一个时间。任务没完成，提示就继续留着；任务结束，再跟着状态一起变化。
需要用户自己关掉的，是手动关闭。它适合必须多看一会儿、但又不值得锁住整个页面的信息。
如果关掉以后再也找不到这条信息，它就不该只放在 toast 里。
toast 出现时不该抢走用户正在输入的位置，但只用键盘或者屏幕朗读的人也得知道它来了。提示要能被读出来，状态也不能只靠颜色区分。
六、带短操作的提示，你还会听到 snackbar
你删掉一封邮件，页面底部出现一条「邮件已删除」，旁边跟着一个「撤销」。你可以继续看列表，也可以趁它还在时把删除撤回来。
这种临时出现、但带一个短操作的提示，常直接叫 snackbar。中文资料里也会把它译成信息条。
有些设计体系会把两者分得很清楚：toast 只负责告诉结果，snackbar 可以带一个操作。有些前端项目则把它们都叫 toast。
各个项目不一定按同一套方式区分 toast 和 snackbar。更稳定的判断是：它们都不锁住页面；如果提示里需要一个「撤销」「重试」这样的短操作，你更可能看到 snackbar 这个词。
无论叫什么，都不适合塞两个、三个选择。用户一旦必须停下来比较选项，这件事就已经超出轻提示了。
七、什么事情适合交给 toast
用户把链接复制到剪贴板以后，原来的任务还可以继续。这类只差一句结果反馈的动作，很适合用 toast。
保存成功、文件已加入下载队列，也不需要专门停下来确认。
后台任务的状态发生变化，但用户仍然可以继续做别的事情，也可以用 toast。它把消息送到眼前，又不会抢走当前任务。
反过来，如果这件事必须让用户回应，toast 就太轻了。账号即将被删除、付款失败后必须重新选择、内容没有保存又准备离开，都不能只显示几秒就算交代完。
判断要不要用 toast，先问最重要的一句：这条消息就算自己消失，用户还能不能正常继续？
如果不能继续，就别只用 toast。
八、第一次用到 toast，就适合做成项目级统一封装
toast 是项目里很常用的一类反馈组件。一个项目第一次真正用到它时，就适合把它统一封装起来，作为重要的项目级全局能力来管理。
保存成功、链接已复制、上传失败，都会用到这套能力。
要是每个页面都自己写一套，有的从顶部出来，有的从底部出来；有的两秒就消失，有的十秒还挡在那儿。
成功和失败的颜色、图标、动画，甚至同时来了好几条以后怎么排列，也可能各做各的。
这里说的封装，就是把反复出现的样子和行为先写成一份，后面需要的时候都来复用它。
这样一来，页面通常只需要提供提示文字、消息状态，以及要不要带一个短操作。显示多久一般走统一的默认值，特殊情况再单独指定。
提示出现在哪里、怎么进场和离场、几条消息怎么排队，都由同一层处理。
最多同时出现几条、什么时候暂停倒计时、屏幕朗读该怎么播报，也要使用同一套规则。
这样统一的不只是圆角、阴影和颜色。toast 的时长、位置、关闭方式和无障碍行为，也不会每个页面各来一套。
这里说的是一种常见的项目组织方式，不是所有项目都必须给它起同一个名字。名字可以不同，重要的是全项目共用一套提示规则。
九、最常见的一条用错
用户提交一大张表单，顶部闪过一句「保存失败」，还没看清就没了。页面里既没有留下错误位置，也没有告诉他刚才填的内容还在不在。
这就是最常见的用错：把必须记住、必须处理的信息，只放进会消失的 toast。
toast 负责送达结果，不负责逼用户作决定。后果越重，越不能只靠一条会消失的提示。
