遍布网络[1] [2] [3]，它表示自PHP 5.0.0“通过引用分配新值的返回值”会产生E_DEPRECATED或{ {1}}取决于您的php版本（E_STRICT在5.3之前不存在，所以在此之前它是E_DEPRECATED。
因此我理解这段代码应该发出警告：
E_STRICT但是，我在两个完全不同的服务器上试过这个（一个运行PHP 5.3，另一个运行PHP 5.2）并且实际上都没有给出任何消息！这是怎么回事？我的理解是不正确的还是在这两台服务器上发生了什么奇怪的事情？
（我也认为很遗憾这是不推荐的，因为error_reporting(E_ALL | E_STRICT);
class A
{
}
$a =& new A();
与$a = null; $b =& $a; $b = new A();的做法不同，但如果我误解了弃用的内容，那只是问题的一部分。 ..）
答案 0 :(得分：2)
在回应OP时，这条评论指出了他正确的方向：
如果问题出现在其他地方，我一点都不会感到惊讶：尝试设置E_ALL |直接在你的php.ini中的E_STRICT，如果你在命令行上运行这段代码，也不要忘记更改php-cli.ini。
还要仔细检查错误是否未被隐藏做ini_set('display_errors',1);1。如果你在Windows机器上运行它，那么过去就有some bugs。
由于OP还指出警告是在任何代码执行之前生成的，所以我有一种预感，即在编译时提出预期的警告，而不是运行时，所以我再看一下{{3 }}。在那里，我发现了这个大红盒子纸条，这证实了我的怀疑：
大多数E_STRICT错误在编译时进行评估，因此在error_reporting增强的文件中不会报告此类错误以包含E_STRICT错误（反之亦然）。
从版本5开始，PHP实际上是一种“编译的”语言（类似于Java，代码被编译为Zend Bytecode）。当Zend引擎编译具有编译时发出的错误的代码时，脚本error_reporting调用对天气没有影响或者没有报告这些错误：error_reporting调用仅适用于运行时错误/警告。
也许这样：error_reporting(E_ALL | E_STRICT | E_COMPILE_ERROR);值得一看
底线：
尽可能在php.ini文件中设置错误报告。