Bug：读取两个文件，然后输出这两个文件的内容。第一个文件输出始终为空，第二个文件可以正常输出。
解决：第一个文件损坏了（具体是什么原因未知），我将第一个文件的内容复制到一个文件中就可以正常使用了。
教训：永远要质疑输入的合法性
Bug：使用Gradio，按钮绑定了一个回调方法，这个方法内部调用了OpenAI做了对输入的两个文件进行处理。结果总是第一个文件处理完之后就停止了。
解决：实际上不是在第一个文件处理完之后停止，而是LLM处理第一个文件花费了大约1分钟，而Gradio默认一分钟回调方法没返回结果就超时失败。所以，设置Gradio应用启动为queue模式，取消超时等待。
教训：任何一个方法执行时间很长就得考虑是否存在超时失败
Bug：测试人员测试我写的的一套上传下载照片逻辑时，同时在测试环境测试了我的上传和下载接口，结果是下载下来的照片无法识别。
解决-1：这里有一个关键点，下载下来的照片无法识别这个问题，我一开始以为是加解密错误导致照片出现问题。但是加解密如果异常应该在程序中就报错。最后发现，下载下来的图片大小是0kb，但是Windows自带的照片预览会直接说无法识别该类型。
教训-1: 对于存储在磁盘上的文件一定首先检查文件大小（这让我想起来实习期的一个问题是因为文件本质是个软连接，如果第一时间查看大小就能看出问题）
解决-2: 代码中的上传下载逻辑我都有详细覆盖性很强的单元测试，本地都上传下载过，不应该出问题。遂回滚代码尝试，发现旧的代码也下载不了，经排查发现是测试环境的host配置错误了。
教训-2: 涉及到这种代码改造（不修改旧逻辑）的测试，在测试之前应该第一步先校验旧代码的可用性，我给它取个名字叫基准测试。
解决-3: 测试过程中，测试使用了另一个服务的接口间接调用了本服务的上传接口，结果走不通。在一开始，下意识认为是本服务的问题，因为另一个服务被使用的接口没有被改造。但排查后发现是另一个服务挂了（挂的原因是我在该服务上做了其他修改，导致服务没启动的了）
教训-3: 间接调用优先确保服务可用性
解决-4: 另一个服务挂掉的原因，是外部依赖更换了服务地址，所以代码中需要修改，而修改的点是另一位同事在改，今天上线并没有合并到master分支，导致我合并master分支时没有合到这部分代码。
教训-4: 如果代码有意料之外的问题，第一时间先看一下其他同事的开发分支有没有一些关键操作没有合并到master。同时也知道了合并master，以及branch命名，commit规范的重要性（要是都糊写一通，根本就没法快速排查）