NOP项目
为保持紧跟NOP更新，项目组坚持不改NOP源码。
以触发器，插件化开发为拓展模式
NOP自定义好的接口或完全独立的新拓展功能很容易插件化。
但部分功能要在NOP原项目上扩展修改在不改源码的要求下非常不易。
能改原码也就10分钟的事，但因为死守不改源码的规定，逻辑要更绕，更费精力，工作量更大，并且有很多风险。
为了扩展将部分逻辑写在Module里，Module严重影响性能。
功能开发前，个人的建议，是直接改某处，写日志，后期有更新再按日志改就可以，这种修改的量不会太大。
项目组不接受，因此提出可以改全局module来扩展。
之后爽歪歪，各种绕，起初只写一小部分逻辑，后期不断的添加。
今日报错。
因采用IIS全局模式。
module内有选择或cookie或session的操作一部
JS，CSS静态页面，api，也经过module，但此两类访问，无cookie session。
初版忘记加静态页验证，导致访问静态页时，因null异常，静太文件无法加载，导致页面样式和效果全丢失。
api更是诡异，api也曾因session报错，其本身无session属性，但古怪之处在于，如果以一个普通的账号登陆。再经module调用api，那么session是有值的。
当然，此session与api无关，除了由同一台终端访问。
api的session原本为空，不可调用
但若在同一终端以账号登陆，则session有值，且=此用户的session
现是全局正则检测是否为静态文件（损性能，且可能会有遗漏不说）
并验证是否有session。
JS和静态页面经Module的问题，后期可以配置nginx静态缓存来避免访问web服务（也就在走module前直接从nginx拿到）
插件开发，只需对自已的插件负责，即使错，也只是在小范围。
搞Module开发，一个未考虑到的小错就会出现大量错误，以致网站崩溃，费力且严重不讨好。
PS，公司项目新上，但尚无独立的测试环境。