1.php执行后常驻内存里，需要kill掉该进程再重启，才能让修改后的代码生效。
之前有一次组里小伙伴修改了一个长期后台进程运行的php脚本，增加了一些业务逻辑判断。之后我进行部署之时一直忘记将其php进程kill掉，测试的时候一直找不到未生效的原因。后面想到了后台持续run的脚本是从内存里面读取的代码块，而不是加载最新的代码脚本。对于php我们常常脑补无需重启（如node）或者编译（java）直接生效，但是对于一直运行的脚本不然。
Tips 2 如果使用ps aux | grep xxx来判断脚本是否运行，请尽量精准地grep。
又是一次后台进程任务的添加，采用方式的是shell脚本监控php进程并维护其始终运行。这次我因为事情比较忙，让F君自己动手在测试服上写好shell去执行。后面发现一直没有成功run起来php任务。
我先尝试了直接php命令执行php脚本是没问题的，排查了脚本本身的问题。然后又仔细看了一下shell发现也没什么问题，最后通过对比之前的写法，发现是因为在判断是否有php脚本进行的时候用的grep 不够精准，如下图。
很凑巧的是，F君写的shell脚本的名字也是new_notice，和php脚本名撞名了。所有尽管shell里面是while true的死循环，但是每次检查都会发现有叫new_notice的进程（因为同名shell脚本一直保持运行），故而不会进行启动php进程的逻辑块，后台任务也永远无法执行。养成习惯精准grep或者将shell脚本名改为更抽象的名称都是不错的方法。但是本质是grep要精准到脚本全称，包括文件扩展后缀名。
Tips 3 报错要重视，框架要熟悉。
为了减少老框架的束缚，我鼓励组内小伙伴在一些业务牵连不大的新项目中尝试使用新的框架来做业务。今天刚好是新的统计服务部署到线上的时间，我刚部署完后，F君和我说mongo的auth failed。经过一顿baidu后，发现需要在tp5的mongo driver实现里面修改源码，把MongoDB\Driver\Manager的连接URI最后加上database参数。尝试添加后不再报auth failed的错误，却直接页面显示该网站永久性转移。去掉后又报auth failed，对比线上和测试服的代码和mongo扩展版本都没有什么问题，也曾怀疑过两个环境的mongo sever版本问题，发现差异也不大。
经过一顿猛如虎的操作，最后发现是因为项目根目录下没有runtime目录造成的。一边赶地铁回家，一边刷着知乎的我发誓以后一定要重视框架的细节，细节决定很多步，包括下一步。