产品介绍：点击提交，不一定已经订好
为周末旅行找到合适房源后，人们通常想尽快确定住处。但不同房源的确认方式不同：有些可以直接预订，有些需要房东先处理请求。
Airbnb 的住宿预订将这两种情况区分为 Instant Book（闪订）和 Request to book（申请预订）。前者不需要另等房东批准，后者仍有等待结果的阶段。官方预订指南
本文关注选择房源之后，怎样判断“已经提交”和“已经确认”。对旅行者来说，这不仅影响页面上的一句提示，也影响是否可以继续安排接下来的行程。
核心使用流程：从房源选择走到明确结果
假设你已设置好 Airbnb 账号，准备在网页版预订两晚住宿。
1. 查看房源和条件，再确认预订方式
选择日期和人数，进入 Reserve。检查价格、房屋规则和取消条件。若下一步是 Confirm and pay，走的是闪订流程；若显示 Request to book，则需要填写相关信息并向房东发送请求。账号也可能需要完成身份验证。操作入口
2. 发出请求后，把等待看成一个独立阶段
申请预订后，点击 Messages（消息），找到与房东的预订消息，在会话中查看状态。出现 Confirmed（已确认）才表示预订确认，同时会有确认邮件。状态查看入口
等待房东回应时，留意状态和邮件更新。房东有 24 小时接受或拒绝，未回应则请求过期。不要因为已经按下提交就把它当作确认；也不宜同时为同一日期发送多个请求，以免多个房东都接受。回应期限与状态通知
3. 按当前状态选择下一步
在房东接受前，打开 Trips（行程）并选择这条预订。在显示 Pending（待处理）的预订中点击 Withdraw request（撤回请求），再点击 Cancel request 确认。接受之后，就应按已确认预订的取消规则处理。撤回操作
若请求被拒绝或过期，可以另选住处。先核对现有请求的结果，再决定下一步，避免把两份未确定的安排当作一份已确定的行程。
付款发生时间存在地区差异，不能用“还在等待”推断“没有任何扣款”。金额和取消结果以实际订单显示及适用政策为准。完成这条路径的标志，是看到明确的确认结果，而不只是发送成功。
设计亮点与借鉴：让状态表达承诺到了哪一步
一个按钮说清下一步交给谁
“确认并付款”和“申请预订”使用户在提交前就能预判是否还需要别人处理。这种区分减少了把传输成功误认为交易完成的机会。代价是用户需要理解两种方式；统一成一个含糊的“完成”，会把差异推迟到后面。
给等待一个可理解的边界
等待状态既要说明事情尚未确定，也要告诉用户期限和可做的动作。比如在请求未被接受前，撤回和继续等待仍有意义；确认后则属于另一套规则。可迁移的原则是让状态同时回答“现在是什么情况”和“我还能做什么”。
自动确认需要前置条件配合
房东设置指南将自动接受与手动回应并列，并提醒房东维护日历。自动化将判断前移到可订日期和规则，手动回应则把部分判断留给一次请求。借鉴时，不能只减少确认步骤，也要看支撑自动确认的信息是否及时。