好，我自己也对此很好奇，所以我设计了一个测试.

Ok, I was curious about this myself as well, so I devised a test.

首先，我用以下两个文件测试了setlocale():

First I tested setlocale() with these two files:

<?php
# locale1.php
error_reporting( E_ALL | E_STRICT );

date_default_timezone_set( 'Europe/Amsterdam' );
setlocale( LC_ALL, 'dutch_nld' ); // awkward Windows locale string

sleep( 10 ); // let's sleep for a bit here

echo strftime( '%A, %B %d, %Y %X %Z', time() );

和

<?php
# locale2.php
error_reporting( E_ALL | E_STRICT );

date_default_timezone_set( 'America/Los_Angeles' );
setlocale( LC_ALL, 'english_usa' ); // awkward Windows locale string

echo strftime( '%A, %B %d, %Y %X %Z', time() );

然后，我在两个单独的选项卡中执行了它们.第一个locale1.php，在设置区域设置后会休眠10秒钟，这使我们有时间同时执行locale2.php.

Then I executed them in two seperate tabs. First locale1.php, that sleeps for 10 seconds after setting the locale, giving us time to execute locale2.php in the meanwhile.

令我惊讶的是，甚至不允许locale2.php正确更改语言环境. locale1.php中的sleep( 10 )似乎以不允许locale2.php同时更改语言环境的方式劫持了Apache/PHP进程.当然，它会 呼应日期，只是没有按照您的期望进行本地化.

To my surprise locale2.php isn't even allowed to change the locale correctly. It appears sleep( 10 ) in locale1.php hijacks the Apache/PHP process in such a way that it doesn't allow locale2.php to alter the locale in the meanwhile. It does however echo the date in the meanwhile of course, just not localized as you'd expect.

:抱歉，将其删除.似乎locale2.php 确实更改了语言环境，并且locale1.php然后在睡觉后打印英语日期而不是荷兰语.因此，确实似乎与setlocale()中的预期行为一致. /编辑

sorry, scrap that. It appears locale2.php does change the locale and locale1.php then prints the English date in stead of Dutch after sleeping. So that does appear to be in accordance with what is expected behavior from setlocale(). /Edit

然后，我用以下两个文件测试了IntlDateFormatter:

Then, I tested IntlDateFormatter with these two files:

<?php
# locale1.php
error_reporting( E_ALL | E_STRICT );

$dateFormatter = new IntlDateFormatter(
    'nl_NL',
     IntlDateFormatter::FULL,
     IntlDateFormatter::FULL,
     'Europe/Amsterdam'
);

sleep( 10 ); // let's sleep for a bit here

echo $dateFormatter->format( time() );

和

<?php
# locale2.php
error_reporting( E_ALL | E_STRICT );

$dateFormatter = new IntlDateFormatter(
    'en_US',
     IntlDateFormatter::FULL,
     IntlDateFormatter::FULL,
     'America/Los_Angeles'
);

echo $dateFormatter->format( time() );

，然后在两个单独的选项卡中再次执行它们，与使用第一组文件的方式相同.这确实给出了预期的结果:locale1.php处于睡眠状态时locale2.php根据美国规则很好地以美式英语打印日期，之后locale1.php根据荷兰语很好地以荷兰语打印日期规则.

and then executed them again in two separate tabs, the same way as with the first set of files. This does give the expected results: while locale1.php is sleeping locale2.php nicely prints a date in American-English according to American rules, after which locale1.php nicely prints a date in Dutch according to Dutch rules.

因此，最后，看来Intl对于该setlocale问题是安全的.

So, concluding, it appears Intl is safe from that setlocale problem.

但是请记住金yun敏的答案.由于缺乏使用Intl的经验，我无法对此发表评论.我最近才发现Intl.

But also mind Hyunmin Kim's answer of course. I couldn't comment on that, due to lack of experience with using Intl. I only recently discovered Intl.