PHP IntlDatePatternGenerator 同一骨架为什么在不同地区返回不同顺序

同一个骨架在不同地区返回不同顺序，是 IntlDatePatternGenerator 的正常行为：骨架描述需要哪些日期字段，地区规则决定怎样排列、使用什么分隔符。它不是要求原样输出的格式字符串。

官方地址：https://www.php.net/manual/en/class.intldatepatterngenerator.php

骨架声明字段，地区决定布局

假设订单页面要为不同地区显示年月日。如果把 yMd 当成“必须年、月、日排列”，切换地区后就会误以为日期被改了。实际变化的是展示模式，日期对象没有因此改变。

PHP 的 getBestPattern 返回可供 IntlDateFormatter 使用的 ICU 模式，失败时返回 false。骨架与模式应作为两种不同的数据处理，不要把生成的模式再拿去当骨架。

把模式交给显示层

下面用同一日期、同一骨架生成两个地区的模式，再格式化。需要 PHP 8.1 及以上并安装 intl。示例未在本机执行，具体模式由运行环境中的 ICU 地区数据决定。

getBestPattern($skeleton);
    if ($pattern === false) {
        throw new RuntimeException('日期模式生成失败');
    }
    // 模式使用ICU语法，不能直接传给DateTime::format。
    $formatter = new IntlDateFormatter(
        $locale, IntlDateFormatter::NONE, IntlDateFormatter::NONE,
        'UTC', IntlDateFormatter::GREGORIAN, $pattern
    );
    $text = $formatter->format($date);
    if ($text === false) {
        throw new RuntimeException('日期格式化失败');
    }
    echo $locale, ' | ', $pattern, ' | ', $text, PHP_EOL;
}

观察时把 locale、模式与显示文本放在一起。美国英语常见月在日前，德语常见日在月前；不要把某台机器上的完整字符串写成所有 ICU 版本的固定承诺。生成器与格式化器使用相同 locale，可避免规则来源不一致。

缓存与存储各自负责什么

只用骨架当缓存键，会让一个地区的模式被另一个地区复用。缓存至少应区分实际 locale 与骨架；若还支持日历等配置，也应纳入设计。更新 ICU 数据后，宜失效旧缓存并重新生成。这里是工程建议，不是接口自动完成的动作。

遇到差异先查输入与环境

先记录实际 locale、骨架、生成模式和 ICU 版本，再判断是正常本地化差异还是配置混用。如果日期数字本身跨了一天，应另查时区；如果只是顺序或标点变化，则先查模式与地区数据。不要通过交换字符串片段修正本地化结果。

想固定年月日顺序怎么办？

固定接口或文件格式应明确约定格式，不把本地化骨架作为固定输出契约。用户界面与数据交换可以采用不同策略。

y 和 Y 可以随便互换吗？

不应互换：ICU 中小写 y 与周所属年份的大写 Y 含义不同。普通日历日期示例使用 y，避免年末周历差异。

为何不能用 PHP 的 Y-m-d 作为 ICU 模式？

PHP 日期格式与 ICU 模式不是同一套字母规则。应分别阅读对应接口的格式说明，不能只凭字符相似套用。

参考：PHP 模式生成接口；ICU 日期格式与骨架说明。