Python 业务规则：条件、循环、容器与异常｜课前预习
这一页只有问题，没有答案。先去真实业务里看一眼，再带着技术上想不通的地方来上课。写下自己的初步判断和依据，不必提前学会全部新知识；不确定的地方留到课堂用代码验证。
第一部分｜业务观察：订单状态限制与批量处理结果
先去这几个地方看看
具体怎么看（照着做）
- 打开京东的“订单取消说明”，找出取消的入口、适用状态以及申请后去哪里查询结果。记录文章标题和链接，不创建订单来试验取消。
- 阅读有赞批量打单教程的“订单限制”和“批量操作进度”，观察官方截图中怎样选择一组订单，怎样展示不符合条件、失败或中断。
- 做两列记录：页面／文档明确说明了什么，哪些细节还没说明。将单笔状态限制与整批处理策略分别记录，不把发货规则直接套成课程取消规则。
只看你自己账号能看到的页面，看到提交订单那一步就停。不用真的买、真的付款，也别去动商家的真订单。截图只留相关字段，把账号、电话、地址、订单号这些个人信息盖掉。
要记下这几点
一条有来源的状态限制＋一张批次结果字段表，标出失败能否定位到具体记录。
记录时写清六项：平台或资料标题、链接或 App 页面路径、观察日期、实际看到的内容、自己的判断、还要验证什么。可以附一张去掉个人信息的截图，不附也行。进不去的时候就去读上面那份官方说明，注明“这条是看官方文档得到的”；还是没有依据的，就写“没观察到／待验证”，下次再补，别编。
真实平台的取消往往还牵着审核、退款一长串流程，那是平台自己的完整业务；你要提炼的只是“什么状态下能取消、什么状态下不能”这条规则本身。批量处理遇到不合条件的单子，是跳过还是停下，也得先由业务规则说了算。
业务上先想这几个问题
下面几个问题，是帮你把刚才看到的业务现象，转成业务上明确的要求。你自己的判断和推测请单独标注，别当成平台真发生过的事。
- 一批订单中有一条填错，怎样让运营知道哪些成功、哪些需要补录？
- 为什么订单能否取消，不能只看客户提交了 cancel 这个动作？
这一段只负责把业务说清楚。 上面这些都是业务上真实存在的要求；至于怎么用技术把它们做出来，是下面第二部分「技术预习」和今天课堂要解决的事。
第二部分｜技术相关：带着问题寻找解决办法
回看一下上次课你自己的项目和运行记录，先找出跟今天的业务场景有关的输入、处理和输出。下面这些词只是帮你认出课上要解决的问题，不用课前背下来。
技术上先想这几个问题
- 把商品、数量、状态组成一条记录，再把三条记录放在一起，你会选字典还是列表？
- 一条坏记录应该让整批停止吗？
- 两个变量指向同一个列表会发生什么？
- 为什么 bool 要与数量整数区分？
写下你的预测、你的理由，还有一个到现在还没想明白的地方。装好环境的同学可以直接用现有代码验证；环境还没弄好的，先在纸上预测一下，不用为了预习专门去装不熟悉的依赖。
上课时要带上这些
- 一份真实、能追到来源的业务观察记录，把“看到的事实”“我的推断”“还没验证的”分开写。
- 一份技术问题的初步判断；动手跑过的，把输入和原始结果一起附上。
- 上完课后对着解答改一改你的判断，写清是哪一步验证让你改了想法。
你写下的业务和技术问题，会在课上对应的知识点里解答，并配合演示核对；复习时回到课堂中对应的小节核对。
带着本次项目变化预测
把昨天输入0得到金额的现象留下来；预测数量转换失败、主动拒绝、正常成功分别应如何计入处理数。 只写预测与理由，课堂运行后再修正。