錯誤6：忽略Unicode/UTF-8問題
php編程中，在處理非ascii字符時，會遇到一些問題，要很小心的去對待，要不然就會錯誤遍地。舉個簡單的例子，strlen($name)，如果$name包含非ascii字符，那結果就有些出乎意料。在此給出一些建議，儘量避免此類問題：
如果你對unicode和utf-8不是很瞭解，那麼你至少應該瞭解一些基礎。推薦閱讀這篇文章。
最好使用mb_*函數來處理字符串，避免使用老的字符串處理函數。這裡要確保PHP的“multibyte”擴展已開啟。
數據庫和表最好使用unicode編碼。
知道jason_code()函數會轉換非ascii字符，但serialize()函數不會。
php代碼源文件最好使用不含bom的utf-8格式。
在此推薦一篇文章，更詳細的介紹了此類問題：UTF-8 Primer for PHP and MySQL
錯誤7：假定$_POST總是包含POST數據
PHP中的$_POST並非總是包含表單POST提交過來的數據。假設我們通過jQuery.ajax() 方法向服務器發送了POST請求：
// js
$.ajax({
url:'http://my.site/some/path',
method:'post',
data:JSON.stringify({a:'a',b:'b'}),
contentType:'application/json'
});
注意代碼中的 contentType: ‘application/json’ ，我們是以json數據格式來發送的數據。在服務端，我們僅輸出$_POST數組：
// php
var_dump($_POST);
你會很驚奇的發現，結果是下面所示：
array(0){}
為什麼是這樣的結果呢？我們的json數據 {a: ‘a’, b: ‘b’} 哪去了呢？
答案就是PHP僅僅解析Content-Type為 application/x-www-form-urlencoded 或 multipart/form-data的Http請求。之所以這樣是因為歷史原因，PHP最初實現$_POST時，最流行的就是上面兩種類型。因此雖說現在有些類型（比如application/json）很流行，但PHP中還是沒有去實現自動處理。
因為$_POST是全局變量，所以更改$_POST會全局有效。因此對於Content-Type為 application/json的請求，我們需要手工去解析json數據，然後修改$_POST變量。
// php
$_POST=json_decode(file_get_contents('php://input'),true);
此時，我們再去輸出$_POST變量，則會得到我們期望的輸出：
array(2){["a"]=>string(1)"a"["b"]=>string(1)"b"}
錯誤8：認為PHP支持字符數據類型
看看下面的代碼，猜測下會輸出什麼：
for($c='a';$c<='z';$c++){
echo$c."\n";
}
如果你的回答是輸出’a’到’z’，那麼你會驚奇的發現你的回答是錯誤的。
不錯，上面的代碼的確會輸出’a’到’z’，但除此之外，還會輸出’aa’到’yz’。我們來分析下為什麼會是這樣的結果。
在PHP中不存在char數據類型，只有string類型。明白這點，那麼對’z’進行遞增操作，結果則為’aa’。對於字符串比較大小，學過C的應該都知道，’aa’是小於’z’的。這也就解釋了為何會有上面的輸出結果。
如果我們想輸出’a’到’z’，下面的實現是一種不錯的辦法：
for($i=ord('a');$i<=ord('z');$i++){
echochr($i)."\n";
}
或者這樣也是OK的：
$letters=range('a','z');
for($i=0;$i
echo$letters[$i]."\n";
}
錯誤9：忽略編碼標準
雖說忽略編碼標準不會導致錯誤或是bug，但遵循一定的編碼標準還是很重要的。
沒有統一的編碼標準會使你的項目出現很多問題。最明顯的就是你的項目代碼不具有一致性。更壞的地方在於，你的代碼將更加難以調試、擴展和維護。這也就意味著你的團隊效率會降低，包括做一些很多無意義的勞動。
對於PHP開發者來說，是比較幸運的。因為有PHP編碼標準推薦（PSR），由下面5個部分組成：
PSR-0：自動加載標準
PSR-1：基本編碼標準
PSR-2：編碼風格指南
PSR-3：日誌接口標準
PSR-4：自動加載
PSR最初由PHP社區的幾個大的團體所創建並遵循。Zend, Drupal, Symfony, Joomla及其它的平臺都為此標準做過貢獻並遵循這個標準。即使是PEAR，早些年也想讓自己成為一個標準，但現在也加入了PSR陣營。
在 某些情況下，使用什麼編碼標準是無關緊要的，只要你使用一種編碼風格並一直堅持使用即可。但是遵循PSR標準不失為一個好辦法，除非你有什麼特殊的原因要 自己弄一套。現在越來越多的項目都開始使用PSR，大部分的PHP開發者也在使用PSR，因此使用PSR會讓新加入你團隊的成員更快的熟悉項目，寫代碼時 也會更加舒適。
錯誤10：錯誤使用empty()函數
一些PHP開發人員喜歡用empty()函數去對變量或表達式做布爾判斷，但在某些情況下會讓人很困惑。
首先我們來看看PHP中的數組Array和數組對象ArrayObject。看上去好像沒什麼區別，都是一樣的。真的這樣嗎？
// PHP 5.0 or later:
$array=[];
var_dump(empty($array));// outputs bool(true)
$array=newArrayObject();
var_dump(empty($array));// outputs bool(false)
// why don't these both produce the same output?
讓事情變得更復雜些，看看下面的代碼：
// Prior to PHP 5.0:
$array=[];
var_dump(empty($array));// outputs bool(false)
$array=newArrayObject();
var_dump(empty($array));// outputs bool(false)
很不幸的是，上面這種方法很受歡迎。例如，在Zend Framework 2中，Zend\Db\TableGateway 在 TableGateway::select() 結果集上調用 current() 方法返回數據集時就是這麼幹的。開發人員很容易就會踩到這個坑。
為了避免這些問題，檢查一個數組是否為空最後的辦法是用 count() 函數：
// Note that this work in ALL versions of PHP (both pre and post 5.0):
$array=[];
var_dump(count($array));// outputs int(0)
$array=newArrayObject();
var_dump(count($array));// outputs int(0)
在這順便提一下，因為PHP中會將數值0認為是布爾值false，因此 count() 函數可以直接用在 if 條件語句的條件判斷中來判斷數組是否為空。另外，count() 函數對於數組來說複雜度為O(1)，因此用 count() 函數是一個明智的選擇。
再來看一個用 empty() 函數很危險的例子。當在魔術方法 __get() 中結合使用 empty() 函數時，也是很危險的。我們來定義兩個類，每個類都有一個 test 屬性。
首先我們定義 Regular 類，有一個 test 屬性：
classRegular
{
public$test='value';
}
然後我們定義 Magic 類，並用 __get() 魔術方法來訪問它的 test 屬性：
classMagic
{
private$values=['test'=>'value'];
publicfunction __get($key)
{
if(isset($this->values[$key])){
return$this->values[$key];
}
}
}
好了。我們現在來看看訪問各個類的 test 屬性會發生什麼：
$regular=newRegular();
var_dump($regular->test);// outputs string(4) "value"
$magic=newMagic();
var_dump($magic->test);// outputs string(4) "value"
到目前為止，都還是正常的，沒有讓我們感到迷糊。
但在 test 屬性上使用 empty() 函數會怎麼樣呢？
var_dump(empty($regular->test));// outputs bool(false)
var_dump(empty($magic->test));// outputs bool(true)
結果是不是很意外？
很不幸的是，如果一個類使用魔法 __get() 函數來訪問類屬性的值，沒有簡單的方法來檢查屬性值是否為空或是不存在。在類作用域外，你只能檢查是否返回 null 值，但這並不一定意味著沒有設置相應的鍵，因為鍵值可以被設置為 null 。
相比之下，如果我們訪問 Regular 類的一個不存在的屬性，則會得到一個類似下面的Notice消息：
Notice:Undefinedproperty:Regular::$nonExistantTestin/path/to/test.php on line10
CallStack:
0.00122347041.{main}()/path/to/test.php:0
因此，對於 empty() 函數，我們要小心的使用，要不然的話就會結果出乎意料，甚至潛在的誤導你。
更多PHP相關技術請搜索千鋒PHP，做真實的自己，用良心做教育。
互聯網+時代，時刻要保持學習，攜手千鋒PHP,Dream
It Possible。
鏈接：https://www.jianshu.com/p/0c95bb5d8a7e
來源：簡書
閱讀更多 思夢PHP 的文章
