最近微構(gòu)網(wǎng)絡(luò)接手了一個(gè)從其他團(tuán)隊(duì)轉(zhuǎn)移過(guò)來(lái)的一個(gè)項(xiàng)目，因?yàn)榭蛻糁暗姆?wù)團(tuán)隊(duì)解散了。在交接過(guò)程中客戶描述了一些問(wèn)題，其中一個(gè)基礎(chǔ)問(wèn)題就是說(shuō)這個(gè)系統(tǒng)只能在windows系統(tǒng)里面運(yùn)行，而在centos等linux系統(tǒng)中運(yùn)行不了，直接出現(xiàn)報(bào)錯(cuò)頁(yè)面。

因?yàn)樵诖酥拔覀円呀?jīng)了解到該項(xiàng)目后端采用php+MySQL開(kāi)發(fā)，而且功能也沒(méi)有特別特殊的東西，理論上不存在這種兼容性問(wèn)題。打開(kāi)調(diào)試模式發(fā)現(xiàn)這樣的頁(yè)面：

這個(gè)報(bào)錯(cuò)太正常不過(guò)了，就是提示模板文件不存在嘛，像這個(gè)項(xiàng)目就是典型的模板引擎實(shí)現(xiàn)邏輯上的前后端分離，但是并不是真正意義上的前后端分離。這種報(bào)錯(cuò)在開(kāi)發(fā)過(guò)程中太常見(jiàn)了。然而為什么在windows系統(tǒng)上就沒(méi)問(wèn)題，而放到linux系統(tǒng)中就有問(wèn)題呢？

稍微了解windows和linux系統(tǒng)的人都知道windows對(duì)大小寫(xiě)不敏感，而linux系統(tǒng)對(duì)大小寫(xiě)敏感。原因就在這個(gè)地方，因?yàn)樯鲜鰧?shí)際報(bào)錯(cuò)的模板文件名為testSql.html，文件名為駝峰命名法，其中是大寫(xiě)的S。然而在調(diào)用的時(shí)候根據(jù)模板解析規(guī)則解析成了testsql，成為完全小寫(xiě)的的了。

如何解決？

最笨的方式就是在對(duì)應(yīng)的控制器中把模板調(diào)用改成統(tǒng)一的名稱，這樣肯定是不會(huì)再出錯(cuò)了。如果一個(gè)項(xiàng)目頁(yè)面數(shù)量很少，這種最笨的方式也是非常有效的一種方式，但是如果頁(yè)面數(shù)量多，那必然就希望用更快的方式來(lái)處理這個(gè)坑了。其實(shí)只要理解thinkphp的模板加載機(jī)制就能批量的解決上述問(wèn)題，下面不解析具體分析過(guò)程，只給一個(gè)分析出來(lái)的結(jié)果。

可以知道進(jìn)行模板加載的核心代碼位于thinkphp\library\think\view\driver\Think.php中，而上述報(bào)錯(cuò)的頁(yè)面提示的就是這個(gè)thinkphp自帶類中的fetch方法。

而真正進(jìn)行處理的則是該方法所引用的parseTemplate方法，官方給的注釋是“自動(dòng)定位模板文件”，我們可以修改該方法進(jìn)行批量處理（一般情況下，不建議修改開(kāi)發(fā)框架的核心源代碼；因?yàn)闀?huì)給后續(xù)框架升級(jí)帶來(lái)麻煩，而且某些框架的許可協(xié)議可能不允許這么干，這里僅供思路參考）。

下面我們截取其中一小段為例來(lái)講解下，以在控制器中直接使用$this->fetch()方法加載模板為例，也就是fetch方法不傳參數(shù)，而讓框架的模板加載機(jī)制自動(dòng)引用模板。對(duì)應(yīng)的核心代碼就是：

$template = str_replace(‘.’, DS, $controller) . $depr . (1 == $this->config['auto_rule'] ? Loader::parseName($request->action(true)) : $request->action());

而跟最后模板文件名相關(guān)的其實(shí)就是：

1 == $this->config['auto_rule'] ? Loader::parseName($request->action(true)) : $request->action()

其中$this->config['auto_rule'] 是模板配置的一個(gè)參數(shù)，它有兩個(gè)值（?1 解析為小寫(xiě)+下劃線 2 全部轉(zhuǎn)換小寫(xiě)，默認(rèn)是1），而$request->action()這個(gè)就是控制器的方法名，默認(rèn)是會(huì)直接全部轉(zhuǎn)化為小寫(xiě)，如果傳參true會(huì)保留原始狀態(tài)。而?Loader::parseName則是把駝峰命名的大寫(xiě)字母轉(zhuǎn)成小寫(xiě)且在它前面加下劃線。

所以依據(jù)上述思路，對(duì)有問(wèn)題的部分，進(jìn)行有標(biāo)記的進(jìn)行處理即可。比如已有的控制器對(duì)應(yīng)的模板文件名都是駝峰文件名，那么我們可以根據(jù)符合條件控制器，修改代碼：Loader::parseName($request->action(true)) 改成$request->action(true)即可，也就是不自動(dòng)變成下劃線形式。具體需要修改什么得按照之前留下的坑而來(lái)的。

建議

我們寫(xiě)代碼的時(shí)候一定要考慮跨平臺(tái)的兼容性和后續(xù)擴(kuò)展迭代的便利性，不要圖一時(shí)快活，隨心所欲。到頭來(lái)留下巨多的坑等待自己或者后續(xù)接手的其他開(kāi)發(fā)人員，其實(shí)在整個(gè)行業(yè)內(nèi)不少的加班都是因?yàn)檫@樣的不嚴(yán)謹(jǐn)造成的，很多甚至出現(xiàn)死循環(huán)，直到拖死整個(gè)項(xiàng)目。

所以建議大家有開(kāi)發(fā)需求的時(shí)候，請(qǐng)謹(jǐn)慎選擇開(kāi)發(fā)團(tuán)隊(duì)，因?yàn)椴⒉皇琴M(fèi)用越低、速度越快的就越好，前期低的成本很可能在后續(xù)過(guò)程中付出幾倍甚至數(shù)十倍的代價(jià)。很多時(shí)候我們團(tuán)隊(duì)是不愿意接手第三方團(tuán)隊(duì)開(kāi)發(fā)的后的產(chǎn)品，因?yàn)檫@樣的產(chǎn)品對(duì)我們和客戶來(lái)講都是性價(jià)比很低的?？蛻粲X(jué)得我的東西都做好了只是存在很多使用上的問(wèn)題，修改起來(lái)應(yīng)該很簡(jiǎn)單；而實(shí)際上往往接手這樣的項(xiàng)目來(lái)修改比重新開(kāi)發(fā)一個(gè)同樣復(fù)雜度的產(chǎn)品花費(fèi)的時(shí)間和人力成本會(huì)更多。