千万不要在module里扩展较多逻辑，很容易引起项目异常。

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，公司项目新上，但尚无独立的测试环境。