一，fullPathForFilename
項目先開發了ios/mac版本，這兩天想把win32工程也配好，但遇到了部分資源無法正確找到的問題。
進一步觀察發現，對於那些找不到的資源路徑，fullPathForFilename將傳入的短路徑直接原樣返回，而不是返回全路徑。
查看fullPathForFilename的實現代碼，有這樣一段：
// FIXME: Should it return nullptr ? or an empty string ?
// The file wasn't found, return the file name passed in.
return filename;
即當前的處理是如果路徑找不到，就將參數原樣返回。
因此初步確定是因為路徑沒找到造成的，那么為什么找不到呢？
在fullPathForFilename的實現內打斷點，查看_searchPathArray的值，發現其中的路徑是對的：
但其中fullpath = this->getPathForFilename(newFilename, resolutionIt, searchIt)一句返回的fullpath卻是空。
於是跟到getPathForFilename中斷點，發現在其中path = getFullPathForDirectoryAndFilename(path, file)一句之前構造的路徑都是與預期相符的，而此句返回的path卻是空字符串。
於是再跟到getFullPathForDirectoryAndFilename中，發現其中有下面代碼：
// if the file doesn't exist, return an empty string
if (!isFileExistInternal(ret)) {
ret = "";
}
於是明白了，原來是ios/mac上的isFileExistInternal與win32上的isFileExistInternal行為不一致，在ios/mac上，isFileExistInternal無論傳入文件路徑還是文件夾路徑，只要路徑存在，都會返回true；而在win32平台上，isFileExistInternal只有傳入的是文件路徑且文件存在時才會返回true，而如果傳入文件夾路徑，則總會返回false。我在項目中使用了fullPathForFilename去獲得文件夾的全路徑，於是在ios/mac下能正常工作，但在win32上不能正常工作。
一個簡單的方法是直接將getFullPathForDirectoryAndFilename中那段代碼改成：
// if the file doesn't exist, return an empty string
if (!isFileExistInternal(ret)
&&!isDirectoryExistInternal(ret)//added [yang chao]
) {
ret = "";
}
這樣win32上fullPathForFilename的行為就與ios/mac上相同了。
二，isFileExist
isFileExist中使用了isFileExistInternal函數，所以isFileExist的行為在win32上也與ios/mac上不一致。在ios/mac上，判斷文件或文件夾是否存在都可以用isFileExist函數，而在win32平台上isFileExist只能判斷文件是否存在，如果想判斷文件夾是否存在，要用isDirectoryExist函數。