1. 采用Ver4.2，线程安全，但是效率低

• 不采用Ver4.3的每个线程独立Session继承Cookie，是因为考虑到在访问时有cookie更新的风险。
• 然而，考虑到教务处的能力，可能这个顾虑并没有必要。
• 但是，Ver4.2.5和Ver4.2.2在线程请求时已加锁，新增开销小，可以接受。
• 文件写入和字典读写，考虑到多线程同时读写一个文件/字典，故均已加锁。

2. 先输入的课程会先抢

• 尽管开发了优先模式(特供与非特供)，但是仍然需要注意到，并列输入的课程中，靠前的课程会先启动它的线程，那么正常情况下自然会先抢到靠前的课程。
• 用户可以利用这点，把自己最想抢的课程放在最前面。
• 当前面的课程的抢课线程出现Timeout，而后面的课程的抢课线程正常执行，那么就会抢到靠后的课程，不过这并非正常情况。

3. 关于特供与非特供的解释

• A方案：所有课程并列同时抢(所有课程随机被抢到，但是有更大的概率抢到并列输入中靠前的课程，最终只能报名2门)。
• B方案：先抢首选，如果抢>30有效次数没抢到，立刻停止抢首选，立刻开始抢备选。 备选一直抢，直至抢到。
• C方案(适用于一定要拿下某一门课的)：先抢首选，只有抢到了所有首选，才会停止抢首选，开始抢备选。如果一直没抢到首选，就不抢备选。

普通模式：A方案
特供的优先模式：B方案
非特供的优先模式：C方案

4. 时间关系

• 12:30开始抢任选课，12:27左右开放抢课，本次12:26:50-56开放任选课/公共选修课选课。
  (开放选课就是能获取到对应的jx0502zbid)
• 11:48关闭限选课，即无法再获取到限选课的jx0502zbid。
• 容易翻车的点：限选课jx0502zbid开放当晚，公共选修课选课就可以获取到相应的jx0502zbid，可以访问公共选修课课表。
• 但是！！！这个jx0502zbid是临时的，后面关闭限选课，正式开启任选课选课时，会分配新的jx0502zbid！！！新的jx0502zbid意味着分配新的kcid，而旧的kcid将不再适用，从而抢课失败。
• p.s. 使用旧的kcid的大概死亡流程记录：先正常提示公共选修课选课不开放，11:48-12:27仍然不开放(正常提示无法获取jx0502zbid)，12:27后全部Timeout或者其他出错，13:00重新变为公共选修课选课不开放。
• 因此，开发了4.7.0，实现了限定条件信息提前存储和瞬间调用，以及等待到特定时间才执行登录的功能。
• 因为正确的方式是，必须在11:48-12:27期间登录，最好是在12:15统一登录。所以到时候一个个录入不现实，必须提前录入，程序读取，统一登录。

5. 账号同时在线问题

• 一个账号不能同时登陆两个地方。所以我建议在12:40之后再行登录。当然可以先联系我查看是否成功。

6. 限定条件覆盖问题

• 配置同一个课程的多个限制条件时，不能使用相同的Course name。因为后面的条件会覆盖前面的条件。但是也要注意唯一性，示例：中国共产党 中国共产党历 中国共产党历史。“中”就不可以，会匹配到中医药等。

7. 版本4.7.0的子进程输出重定向问题

• 禁用 env={**os.environ, 'PYTHONUNBUFFERED': '1'} 后，父进程虽然要求行缓冲(buffersize=1)，但是子进程会默认一定要写满8kB块缓冲才会被读取。这会导致父进程读取子进程输出时间跨度过长，无法及时获取到最新信息。