这是个很实际的问题，咱们得拆成两个层面来分析——先聊通用的原生函数别名场景，再单独说说转成PSR命名规范的情况。

一、给原生函数设别名的通用情况：不推荐作为长期实践 #

给PHP原生函数随便加别名，大概率不是什么好主意，主要有这几个原因：

• 可读性大打折扣：每个PHP开发者都熟悉原生函数的命名（比如array_keys、str_replace），突然看到一个陌生的别名，得去翻代码找定义才能明白对应哪个原生函数，团队协作时会额外增加认知负担。
• 维护成本上升：如果项目里别名满天飞，后续版本迭代中一旦有人修改别名映射，或者PHP更新导致原生函数行为变化，很容易出现排查困难的bug。
• 无必要的抽象：原生函数本身已经是语言的基础组件，额外加别名没有带来任何功能上的提升，反而多了一层无意义的映射。

当然也有例外：比如老项目遗留了大量自定义别名，为了兼容旧代码暂时保留，这属于过渡阶段的权宜之计，而非长期的良好实践。

二、转成PSR命名规范的别名：看似规范，实则得不偿失 #

你提到的use function array_keys as getArrayKeys;这种把下划线命名转成PSR驼峰式的做法，初衷可能是统一代码风格，但实际问题更多：

• 违背语言约定：PHP原生函数的命名风格就是下划线分隔，这是整个PHP生态的共识。强行转成驼峰，相当于在对抗语言本身的设计习惯，反而让熟悉PHP的开发者觉得别扭。
• 混淆函数来源：看到getArrayKeys，开发者第一反应会以为这是项目自定义的工具函数，而不是原生的array_keys，需要额外确认，反而降低了代码的直观性。
• IDE支持受限：原生函数有完善的代码提示、文档跳转和静态分析支持，别名往往需要额外配置IDE才能识别，反而拖慢开发效率。

如果真的想让代码风格统一，更优的做法是封装一层自定义工具函数，比如：

function getArrayKeys(array $array, mixed $searchValue = null, bool $strict = false): array
{
    return array_keys($array, $searchValue, $strict);
}

这样既符合PSR命名规范，又能清晰表明这是项目封装的函数，后续还能方便地添加日志、参数校验等扩展逻辑，比单纯的别名靠谱得多。

总结 #

总的来说，给PHP原生函数设置别名不属于良好实践——哪怕是为了贴合PSR命名规范。与其折腾别名，不如要么接受原生函数的命名风格，要么通过封装自定义函数来实现风格统一和功能扩展。

内容的提问来源于stack exchange，提问作者apedic