Python之Print引发的血案

众所周知， 在写项目中最好不要用print作为日志调试手段， 但是基本上接触这行都是从打印Hello World开始的， 所以用print写Demo算是家常便饭， 所以秉着不作不死的精神， 在写新项目Demo的时候， 就做了这么一个死， 然后就出现了一个修了半天都找到问题在哪的BUG。

首先， 我发誓是编译器先动手的！ 

事情是这样的， 我只是写了一个简单的demo， 功能么， 就是在主进程里利用一个二级子进程去启动一个Flask的后台， 然后当主进程退出后， Flask的进程必须要在， 这样去实现通过一个管理后台去对其他后台进行管理， 大概就是这么简单， 一开始也确实玩得挺Happy.

然后就发现了Flask的DEBUG模式很贴心的帮我把主进程的东西也Copy了一遍， 在各种姿势调整下， 终于找到了DEBUG模式的问题所在（好吧， 我确实很菜）, 顺手关了DEBUG模式， 本来以为这样就万事大吉了， 我真厉害。

然鹅， 当发现请求的东西不是我想要的时候， 就忍不住想要看看， 到底是我给的东西不对呢， 还是它给我的东西错了， 就想看看我它接收到的东西长啥样， 懒得装包， 懒得导入， 顺手就写了个print， 发现参数是对的， 然后就没理这块了， 之后尴尬的事情就发生了， 当检测主进程退出后服务是否正常时， 只要你请求那个视图函数， 就出现Server Error， 而请求其他视图函数又一点事都没有...

这是什么灵异事件？ 当在主程序中加入死循环， 输出日志一看， 好家伙， 一点问题都没有， 所有打印正常，这是什么问题？ 是我对它的上下文或者flask服务构建机制理解深度不够么？ 

就在我想要去翻flask源码之前， 打开debug模式瞄了一眼， OSError? 那不是文件读写出错常有的错误么？ 跟我有啥关系？ 

是不是我调用request的时候， 里面一些东西因为主进程退出之类的干扰会有问题？ 当我去掉那一句参数打印， 果然没问题了！

难道这种模式没办法获取到请求参数， 那这样的后台还有啥用？ 这个管理服务的模式不就基本废了？ 

百思不得其解之间， 就瞄到了那个print， 突然脑子里一闪而过打印日志的原理， 瞬间明白了， 主进程退出了， 定义的输出流对应的文件都没了， 这时候再print， 不出异常就有鬼了。

果然， 当不用print的时候， 各种花式调用都没问题...

结果， 就因为手残， 写了个print， 浪费了一大堆的时间， 也算是长了个教训， 不听老人言， 吃亏在眼前啊...