可以参考官方文档那个集成 celery 的例子， 简单的说调用都要包在 with app.app_context()里， 不过你这个把 flask 和 apscheduler 包一起的需求我感觉有问题......

重新加载不至于， 有 opcache 的， 中古时代 apc 、eaccelerator 、xcache 这些都是正经项目的标配

但是认为 php 是热修改的绝对是邪道, 那是虚拟主机时代妥协的办法， 更新期间出错就出错吧， 也是针对不严肃的项目的， 就算 php4 时代， 大公司自己部署 php 的哪个不是用 svn 版本挂软链接重启后端的方式去做的， 搞在线改文件那种弄法出到问题要被点天灯的

甚至 Zend 搞的 phpcloud, 修改代码 push 上去， 直接上去刷新， 会提示你正在重启项目的， 应该没人比 Zend 更了解 PHP 吧........

"我知道有 debug 模式的监听 但不至于在生产环境开 debug 模式"

php 的热修改保证不了整个项目原子性的， 正经严肃一点的项目也是需要通过切换后端的方式修改的

这种和以前做站群是差不多的

你以为是互相抄来抄去， 其实可能是一两个机构用几十个主播拿来撞大运.......

你说的那是老方案了

之前这类平台给个人签约的是按个人所得税代缴， 比如主播还有广告联盟做网赚， 包括京东联盟这些返利的

去年铁拳下来， 都得劳务收入计税， 都得补缴， 那平台当然不用替用户交了啊， 用户自己去报呗

然后你因为连接一个特定 IP 发送了大量加密流量，一枝独秀，成了全公司最靓的仔

你这个会把数据放 /usr/local/redis-3.2.0/data 下面的不像什么正经的包管理啊

/usr/local 一般官方的包管理不会去碰的， 数据是放 /var/lib/XXXX 下面的

你理解反了，72 小时内是有隐私保护的， 只能通过中转号联系到你， 但是正因为中转号这个隐私保护在 72 小时内一直有效， 所以有权限查真实号码的才能查到你啊.........

首先 path 需要过滤， 不然可能会构造出包含漏洞

foreach 那段不需要提早过滤, sql 用参数绑定，like 之后的做二次过滤，xss 在输出的时候过滤

extract 那个我看见就害怕了........早年 gpc 漏洞之王啊， 敢手动制造 gpc 的都是猛人啊......

怕就不干啊

出到事， 就算最终能撇开关系， 经侦刑侦也会找你去住几天协助调查的啊........

因为上下两个 foreach 都把 key 给改到了最后一个键啊

你这是针对具体业务做的外包， 出到事怎么可能没事.....

A4 纸那种面积的光伏板， 白天正对大太阳， 理想功率也就两三瓦， 你还得有升降压的开销， 得铺多大面积啊.....而且电池的开销也不低

直接买个几百块的那种双铅酸电池的 UPS 吧， 便宜不说， 还安全......