十个人里有九个在灵兽打书上踩过同一个坑：技能书放进去，点了确认，界面半天不动，手一抖又点了一次，回头一看技能格子里多了一条重复的技能，书却少了两本。这件事看着像运气问题，其实是一段等待时间里的网络安排问题。
打书这件事为什么容易出岔子
打书这一步在网络上做了什么
打书不是本地运算。技能书放进去之后，客户端把这一次的提交发给服务器，服务器随机决定这次学到什么、顶掉哪一条，再把结果写进灵兽数据。客户端能做的只有等那一次返回。整个过程中，代理IP需要维持一段完整的会话，让请求发得出去、结果收得回来。
| 环节 | 请求性质 | 对线路的要求 | 断了会怎样 |
|---|---|---|---|
| 放入技能书 | 写操作 | 提交即生效 | 书已消耗，界面未必马上刷新 |
| 随机结算 | 服务器侧计算 | 客户端只需保持在线 | 结果照常产生，客户端可能没收到 |
| 写回灵兽数据 | 写操作 | 需要一次回执确认 | 显示没变化，实际已经改了 |
| 刷新技能格子 | 读操作 | 响应快 | 格子显示停留在旧的技能列表 |
为什么重复提交最划不来
重复提交的代价在于，随机结算是按次收费的。第一次提交已经让服务器算过一轮，第二次点，等于又买了一轮随机。有趣的是客户端看到的可能只是界面没动，你以为第一次没成，实际两次都成了。材料少了，技能却没按你想要的方向涨，这种亏损很难追回来。
打书时网络慢一点会怎样？
慢不等于失败。等一会儿再刷新，多半能看到结果已经写进去了。真正确认失败的情况很少，多数是回执在路上。
模拟器多开打书要注意什么
用模拟器同时开几个号打书的人不少，这种时候几条实例共用IP，问题更集中。每个实例的提交都是独立请求，代理IP带宽不够时，几个实例的提交挤在一处，靠后的那个等待时间最长，也最容易让人误以为失败。给每个实例单独安排线路，或者打书时先关掉其他实例的占用，都能把这种情况挡在前面。
几个可以照做的习惯
第一个习惯是提交之后数三秒，这段时间里不点第二次，也不切界面。第二个习惯是打书前先确认线路稳定，别在材料已经放进去之后才想起调整IP。第三个习惯是打完一轮先看结果再放第二本书，把每一次都当作独立的结算，不让两轮牵扯在一起。
几个号能不能同时打书？
技术上可以，但会挤占同一条线路的带宽。稳妥做法是把几个号的打书动作错开，或者各自用不同的IP，避免提交请求叠在同一时刻。
把等待当成本来就有的一段，打书这件事的账就好算了。
与代理线路的关系：打书的每一步都依赖一段不被打断的会话，从提交到回执，中间任何一次线路更换都可能让结果和界面脱节。给打书留一条稳定的线路，材料才不会花得不明不白。