PHP でよくある間違いは次のとおりです: 1. foreach ループの後にぶら下がりポインタを残す; 2. isset() 関数の動作の誤解; 3. 戻り値と戻り参照の混同; 4. での実行ループ SQL クエリ、5. 非効率なメモリ使用量と錯覚、6. Unicode/UTF-8 の問題の無視など。
この記事の動作環境: Windows7 システム、PHP7.1 バージョン、DELL G3 コンピューター
よくある間違いとは何ですかphpで作ったの?
#PHP を学習するときによくある 10 の間違い
エラー 1: foreach ループの後にダングリング ポインターを残す
foreach ループで、反復される要素を変更する必要がある場合、または効率を向上させる必要がある場合は、参照を使用するのが良い方法です。$arr = array(1,2,3,4); foreach($arr as&$value){ $value = $value *2; } // $arr is now array(2, 4, 6, 8)ここで、多くの人が混乱するであろう質問があります。ループが終了した後、$value は破棄されません。$value は、実際には配列内の最後の要素への参照です。その後の $value の使用時にこれを知らずに使用すると、いくつかの不可解なエラーが発生します:)このコード:
$array =[1,2,3]; echo implode(',', $array),"\n"; foreach($array as&$value){} // by reference echo implode(',', $array),"\n"; foreach($array as $value){} // by value (i.e., copy) echo implode(',', $array),"\n";上記のコードを実行した結果は次のとおりです:
1,2,3 1,2,3 1,2,2正解でしたか?なぜこのような結果になったのでしょうか? 分析してみましょう。最初のループの後、$value は配列内の最後の要素への参照になります。 2 番目のループが始まります: 最初のステップ: $arr[0] を $value にコピーします (この時点では $value は $arr[2] への参照であることに注意してください)、配列は [1, 2 ,1]ステップ 2: $arr[1] を $value にコピーすると、配列は [1,2,2] になります。ステップ 3: $arr[2 ] を $value にコピーします。 $value の場合、配列は [1,2,2] になります。要約すると、最終結果は 1,2,2 になります。このエラーを回避する最善の方法は、 unset 関数を使用して、ループの直後に変数を破棄します:
$arr = array(1,2,3,4); foreach($arr as&$value){ $value = $value *2; } unset($value); // $value no longer references $arr[3]
エラー 2: isset() 関数の動作の誤った理解
isset() 関数の場合、変数が存在しない場合は False が返され、変数値が null の場合も false が返されます。この動作は人々を簡単に混乱させる可能性があります。 。 。次のコードを見てください:$data = fetchRecordFromStorage($storage, $identifier); if(!isset($data['keyShouldBeSet']){ // do something here if 'keyShouldBeSet' is not set }このコードを書いた人は、$data[‘keyShouldBeSet’] が設定されていない場合、対応するロジックが実行されることを意図していたのかもしれません。しかし、問題は、$data[‘keyShouldBeSet’] が設定されていても、設定値が null であっても、対応するロジックが引き続き実行されることです。これは、コードの本来の意図に沿っていません。 ここに別の例があります:
if($_POST['active']){ $postData = extractSomething($_POST); } // ... if(!isset($postData)){ echo 'post not active'; }上記のコードは、$_POST[‘active’] が true であることを前提としており、$postData を設定する必要があるため、isset($postData) は true を返します。逆に、上記のコードは、isset($postData) が false を返す唯一の方法は、$_POST[‘active’] も false を返す場合であると想定しています。 これは本当にそうなのでしょうか?もちろん違います! $_POST[‘active’] が true を返した場合でも、$postData が null に設定される可能性があり、その場合、isset($postData) は false を返します。これはコードの意図に反します。 上記のコードの目的が $_POST['active'] が true かどうかを検出することのみである場合は、次の実装の方が適切です。
if($_POST['active']){ $postData = extractSomething($_POST); } // ... if($_POST['active']){ echo 'post not active'; }変数が実際に設定されているかどうかを判断します ( unset と値を null に設定することを区別する場合は、array_key_exists() 関数の方が適切かもしれません。上記の最初の例を次のようにリファクタリングします。
$data = fetchRecordFromStorage($storage, $identifier); if(! array_key_exists('keyShouldBeSet', $data)){ // do this if 'keyShouldBeSet' isn't set }さらに、 get_define_vars() 関数と組み合わせると、変数が現在のスコープに設定されているかどうかをより確実に検出できます。
if(array_key_exists('varShouldBeSet', get_defined_vars())){ // variable $varShouldBeSet exists in current scope }
エラー 3: 戻り値と戻り参照が混同されている
次のコードを検討してください:classConfig { private $values =[]; publicfunction getValues(){ return $this->values; } } $config =newConfig(); $config->getValues()['test']='test'; echo $config->getValues()['test'];上記のコードを実行すると、次の内容が出力されます:
PHP Notice: Undefined index: test in/path/to/my/script.php on line 21問題?問題は、上記のコードが戻り値と戻り参照を混同していることです。 PHP では、戻り参照を明示的に指定しない限り、PHP は配列のコピーである配列の値を返します。したがって、上記のコードが返された配列に値を割り当てる場合、実際には元の配列ではなく、コピーされた配列に値が割り当てられます。
// getValues() returns a COPY of the $values array, so this adds a 'test' element // to a COPY of the $values array, but not to the $values array itself. $config->getValues()['test']='test'; // getValues() again returns ANOTHER COPY of the $values array, and THIS copy doesn't // contain a 'test' element (which is why we get the "undefined index" message). echo $config->getValues()['test'];次のような解決策が考えられます。元の配列の代わりにコピーした配列を出力します。
$vals = $config->getValues(); $vals['test']='test'; echo $vals['test'];元の配列を変更したいだけの場合、つまり配列を返す必要があります。参考、ではどう対処すればいいのでしょうか?方法は、指定された戻り参照を表示することです:
classConfig { private $values =[]; // return a REFERENCE to the actual $values array publicfunction&getValues(){ return $this->values; } } $config =newConfig(); $config->getValues()['test']='test'; echo $config->getValues()['test'];変更後、上記のコードは期待どおりにテストを出力します。 さらに混乱を招く別の例を見てみましょう:
classConfig { private $values; // using ArrayObject rather than array publicfunction __construct(){ $this->values =newArrayObject(); } publicfunction getValues(){ return $this->values; } } $config =newConfig(); $config->getValues()['test']='test'; echo $config->getValues()['test'];「未定義のインデックス」エラーが上記のように出力されると思ったら、それは間違いです。コードは通常「test」を出力します。その理由は、PHP はデフォルトで値ではなく参照によってオブジェクトを返すためです。 要約すると、関数を使用して値を返すときは、それが値の戻り値であるか参照の戻り値であるかを判断する必要があります。 PHP のオブジェクトの場合、デフォルトでは参照によって返され、配列と組み込みの基本型はデフォルトで値によって返されます。これは他の言語とは区別する必要があります (多くの言語は配列を参照によって渡します)。 Java や C# などの他の言語と同様に、クラス プロパティにアクセスまたは設定するにはゲッターまたはセッターを使用する方が良いソリューションです。もちろん、PHP はデフォルトではサポートしていないため、自分で実装する必要があります:
classConfig { private $values =[]; publicfunction setValue($key, $value){ $this->values[$key]= $value; } publicfunction getValue($key){ return $this->values[$key]; } } $config =newConfig(); $config->setValue('testKey','testValue'); echo $config->getValue('testKey'); // echos 'testValue'上記のコードにより、呼び出し元は配列にパブリック アクセスを付与せずに、配列内の任意の値にアクセスしたり、値を設定したりできます。どう感じますか :)
エラー 4: SQL クエリをループで実行しています
PHP プログラミングで次のようなコードを見つけることは珍しくありません:$models =[]; foreach($inputValues as $inputValue){ $models[]= $valueRepository->findByValue($inputValue); }
当然上面的代码是没有什么错误的。问题在于我们在迭代过程中$valueRepository->findByValue()可能每次都执行了sql查询:
$result = $connection->query("SELECT `x`,`y` FROM `values` WHERE `value`=". $inputValue);
如果迭代了10000次,那么你就分别执行了10000次sql查询。如果这样的脚本在多线程程序中被调用,那很可能你的系统就挂了。。。
在编写代码过程中,你应该要清楚什么时候应该执行sql查询,尽可能一次sql查询取出所有数据。
有一种业务场景,你很可能会犯上述错误。假设一个表单提交了一系列值(假设为IDs),然后为了取出所有ID对应的数据,代码将遍历IDs,分别对每个ID执行sql查询,代码如下所示:
$data =[]; foreach($ids as $id){ $result = $connection->query("SELECT `x`, `y` FROM `values` WHERE `id` = ". $id); $data[]= $result->fetch_row(); }
但同样的目的可以在一个sql中更加高效的完成,代码如下:
$data =[]; if(count($ids)){ $result = $connection->query("SELECT `x`, `y` FROM `values` WHERE `id` IN (". implode(',', $ids)); while($row = $result->fetch_row()){ $data[]= $row; } }
错误5:内存使用低效和错觉
一次sql查询获取多条记录比每次查询获取一条记录效率肯定要高,但如果你使用的是php中的MySQL扩展,那么一次获取多条记录就很可能会导致内存溢出。
我们可以写代码来实验下(测试环境: 512MB RAM、MySQL、php-cli):
// connect to mysql $connection =new mysqli('localhost','username','password','database'); // create table of 400 columns $query ='CREATE TABLE `test`(`id` INT NOT NULL PRIMARY KEY AUTO_INCREMENT'; for($col =0; $col <400; $col++){ $query .=", `col$col` CHAR(10) NOT NULL"; } $query .=');'; $connection->query($query); // write 2 million rows for($row =0; $row <2000000; $row++){ $query ="INSERT INTO `test` VALUES ($row"; for($col =0; $col <400; $col++){ $query .=', '. mt_rand(1000000000,9999999999); } $query .=')'; $connection->query($query); }
现在来看看资源消耗:
// connect to mysql $connection =new mysqli('localhost','username','password','database'); echo "Before: ". memory_get_peak_usage()."\n"; $res = $connection->query('SELECT `x`,`y` FROM `test` LIMIT 1'); echo "Limit 1: ". memory_get_peak_usage()."\n"; $res = $connection->query('SELECT `x`,`y` FROM `test` LIMIT 10000'); echo "Limit 10000: ". memory_get_peak_usage()."\n";
输出结果如下:
Before:224704 Limit1:224704 Limit10000:224704
根据内存使用量来看,貌似一切正常。为了更加确定,试着一次获取100000条记录,结果程序得到如下输出:
PHP Warning: mysqli::query():(HY000/2013): Lost connection to MySQL server during query in/root/test.php on line 11
这是怎么回事呢?
问 题出在php的mysql模块的工作方式,mysql模块实际上就是libmysqlclient的一个代理。在查询获取多条记录的同时,这些记录会直接 保存在内存中。由于这块内存不属于php的内存模块所管理,所以我们调用memory_get_peak_usage()函数所获得的值并非真实使用内存 值,于是便出现了上面的问题。
我们可以使用mysqlnd来代替mysql,mysqlnd编译为php自身扩展,其内存使用由php内存管理模块所控制。如果我们用mysqlnd来实现上面的代码,则会更加真实的反应内存使用情况:
Before:232048 Limit1:324952 Limit10000:32572912
更加糟糕的是,根据php的官方文档,mysql扩展存储查询数据使用的内存是mysqlnd的两倍,因此原来的代码使用的内存是上面显示的两倍左右。
为了避免此类问题,可以考虑分几次完成查询,减小单次查询数据量:
$totalNumberToFetch =10000; $portionSize =100; for($i =0; $i <= ceil($totalNumberToFetch / $portionSize); $i++){ $limitFrom = $portionSize * $i; $res = $connection->query( "SELECT `x`,`y` FROM `test` LIMIT $limitFrom, $portionSize"); }
联系上面提到的错误4可以看出,在实际的编码过程中,要做到一种平衡,才能既满足功能要求,又能保证性能。
错误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++){ echo chr($i)."\n"; }
或者这样也是OK的:
$letters = range('a','z'); for($i =0; $i < count($letters); $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:Undefined property:Regular::$nonExistantTest in/path/to/test.php on line 10 CallStack: 0.0012 234704 1.{main}()/path/to/test.php:0
因此,对于 empty() 函数,我们要小心的使用,要不然的话就会结果出乎意料,甚至潜在的误导你。
推荐学习:《PHP视频教程》
以上がPHPでよくある間違いは何ですかの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。