FastAPI 与执行方式：HTTP、同步和异步入门｜课前预习
这一页只有问题，没有答案。先去真实业务里看一眼，再带着技术上想不通的地方来上课。写下自己的初步判断和依据，不必提前学会全部新知识；不确定的地方留到课堂用代码验证。
第一部分｜业务观察：页面等待、结果查询与重复操作
先去这几个地方看看
具体怎么看（照着做）
- 在淘宝或京东 App 浏览商品，观察切换规格或打开详情时的加载、成功或空结果提示。实际没遇到失败就记“未观察到失败”，不人为制造真实交易失败。
- 阅读京东取消说明，找到提交申请与查看处理进度的不同位置。把“发起操作”“处理中”“最终结果”按文档实际描述区分。
- 对比商品页和帮助中心对同一业务对象的称呼，列出跨页面需要保持一致的信息；再写出网络等待时希望页面给出的反馈。
只看你自己账号能看到的页面，看到提交订单那一步就停。不用真的买、真的付款，也别去动商家的真订单。截图只留相关字段，把账号、电话、地址、订单号这些个人信息盖掉。
要记下这几点
一条实际读取旅程＋官方申请／结果查询流程，分清观察与界面设计建议。
记录时写清六项：平台或资料标题、链接或 App 页面路径、观察日期、实际看到的内容、自己的判断、还要验证什么。可以附一张去掉个人信息的截图，不附也行。进不去的时候就去读上面那份官方说明，注明“这条是看官方文档得到的”；还是没有依据的，就写“没观察到／待验证”，下次再补，别编。
页面上那些“加载中”“处理中”的提示，说的是业务走到哪一步、结果去哪儿查——把这条线索记下来。至于怎么让页面不等着卡住，是今天课堂技术部分要解决的事。
业务上先想这几个问题
下面几个问题，是帮你把刚才看到的业务现象，转成业务上明确的要求。你自己的判断和推测请单独标注，别当成平台真发生过的事。
- 两个客户端为什么应该使用同一份订单接口约定？
- 页面超时后直接重试一次下单，会给业务带来什么风险？
这一段只负责把业务说清楚。 上面这些都是业务上真实存在的要求；至于怎么用技术把它们做出来，是下面第二部分「技术预习」和今天课堂要解决的事。
第二部分｜技术相关：带着问题寻找解决办法
回看一下上次课你自己的项目和运行记录，先找出跟今天的业务场景有关的输入、处理和输出。下面这些词只是帮你认出课上要解决的问题，不用课前背下来。
技术上先想这几个问题
- 查订单和创建订单的 HTTP 方法、路径及输入位置应该如何区分？
- 连续两次 await 是并发吗？
- 把同步数据库调用放进 async def 就能提速吗？
- 超时返回是否说明任务已经成功或完全没有副作用？
写下你的预测、你的理由，还有一个到现在还没想明白的地方。装好环境的同学可以直接用现有代码验证；环境还没弄好的，先进行环境安装。
上课时要带上这些
- 一份真实、能追到来源的业务观察记录，把“看到的事实”“我的推断”“还没验证的”分开写。
- 一份技术问题的初步判断；动手跑过的，把输入和原始结果一起附上。
- 上完课后对着解答改一改你的判断，写清是哪一步验证让你改了想法。
你写下的业务和技术问题，会在课上对应的知识点里解答，并配合演示核对；按课堂同名机制小节回看，不重复抄写一份标准答案。
带着本人代码补三条预测
本节只给问题，不提供标准答案。
- 两项独立查询先后 await，是否已经同时发出？
- 商品查询失败时配送仍等待，谁负责取消并等待清理？
- 调用者超时能否证明远端订单从未写入？