最近微构网络接手了一个从其他团队转移过来的一个项目，因为客户之前的服务团队解散了。在交接过程中客户描述了一些问题，其中一个基础问题就是说这个系统只能在windows系统里面运行，而在centos等linux系统中运行不了，直接出现报错页面。
因为在此之前我们已经了解到该项目后端采用php+MySQL开发，而且功能也没有特别特殊的东西，理论上不存在这种兼容性问题。打开调试模式发现这样的页面：
这个报错太正常不过了，就是提示模板文件不存在嘛，像这个项目就是典型的模板引擎实现逻辑上的前后端分离，但是并不是真正意义上的前后端分离。这种报错在开发过程中太常见了。然而为什么在windows系统上就没问题，而放到linux系统中就有问题呢？
稍微了解windows和linux系统的人都知道windows对大小写不敏感，而linux系统对大小写敏感。原因就在这个地方，因为上述实际报错的模板文件名为testSql.html，文件名为驼峰命名法，其中是大写的S。然而在调用的时候根据模板解析规则解析成了testsql，成为完全小写的的了。
如何解决？
最笨的方式就是在对应的控制器中把模板调用改成统一的名称，这样肯定是不会再出错了。如果一个项目页面数量很少，这种最笨的方式也是非常有效的一种方式，但是如果页面数量多，那必然就希望用更快的方式来处理这个坑了。其实只要理解thinkphp的模板加载机制就能批量的解决上述问题，下面不解析具体分析过程，只给一个分析出来的结果。
可以知道进行模板加载的核心代码位于thinkphp\library\think\view\driver\Think.php中，而上述报错的页面提示的就是这个thinkphp自带类中的fetch方法。
而真正进行处理的则是该方法所引用的parseTemplate方法，官方给的注释是“自动定位模板文件”，我们可以修改该方法进行批量处理(一般情况下，不建议修改开发框架的核心源代码；因为会给后续框架升级带来麻烦，而且某些框架的许可协议可能不允许这么干，这里仅供思路参考)。
下面我们截取其中一小段为例来讲解下，以在控制器中直接使用$this->fetch()方法加载模板为例，也就是fetch方法不传参数，而让框架的模板加载机制自动引用模板。对应的核心代码就是：
$template = str_replace(‘.’, DS, $controller) . $depr . (1 == $this->config['auto_rule'] ? Loader::parseName($request->action(true)) : $request->action());
而跟最后模板文件名相关的其实就是：
1 == $this->config['auto_rule'] ? Loader::parseName($request->action(true)) : $request->action()
其中$this->config['auto_rule'] 是模板配置的一个参数，它有两个值( 1 解析为小写+下划线 2 全部转换小写，默认是1)，而$request->action()这个就是控制器的方法名，默认是会直接全部转化为小写，如果传参true会保留原始状态。而 Loader::parseName则是把驼峰命名的大写字母转成小写且在它前面加下划线。
所以依据上述思路，对有问题的部分，进行有标记的进行处理即可。比如已有的控制器对应的模板文件名都是驼峰文件名，那么我们可以根据符合条件控制器，修改代码：Loader::parseName($request->action(true)) 改成$request->action(true)即可，也就是不自动变成下划线形式。具体需要修改什么得按照之前留下的坑而来的。
建议
我们写代码的时候一定要考虑跨平台的兼容性和后续扩展迭代的便利性，不要图一时快活，随心所欲。到头来留下巨多的坑等待自己或者后续接手的其他开发人员，其实在整个行业内不少的加班都是因为这样的不严谨造成的，很多甚至出现死循环，直到拖死整个项目。
所以建议大家有开发需求的时候，请谨慎选择开发团队，因为并不是费用越低、速度越快的就越好，前期低的成本很可能在后续过程中付出几倍甚至数十倍的代价。很多时候我们团队是不愿意接手第三方团队开发的后的产品，因为这样的产品对我们和客户来讲都是性价比很低的。客户觉得我的东西都做好了只是存在很多使用上的问题，修改起来应该很简单；而实际上往往接手这样的项目来修改比重新开发一个同样复杂度的产品花费的时间和人力成本会更多。
