php函数名在全局与命名空间中会冲突，仅发生在未加命名空间前缀调用时；解析规则为先查当前命名空间再回退到全局，同名函数共存将导致fatal error。
PHP 函数名在全局作用域和命名空间里会冲突吗
会，但只在“未加命名空间前缀调用”时发生。PHP 的函数名解析规则是：先查当前命名空间，再 fallback 到全局（root）命名空间。这意味着：同名函数不能同时存在于全局和某个命名空间中，否则 declare(strict_types=1) 下可能不报错，但运行时会直接 fatal error。
常见错误现象：Fatal error: Cannot declare function foo(), because the name is already in use —— 尤其在 require/require_once 多个文件、且有的定义在全局、有的在 namespace A; 下时高频出现。
- 定义在全局的
foo()和定义在namespace A { function foo() {} }中的foo()是两个不同函数，但一旦你试图在namespace A里写foo();（没加），PHP 就只找A oo；而如果你在全局里又定义了一次foo()，加载顺序一错就冲突 -
function_exists('foo')查的是全局函数，不会返回A oo；要查命名空间函数得用function_exists('A\foo') - Composer 自动加载通常把函数定义放在全局（比如
functions.php），若你自己的命名空间里也定义了同名函数，require 顺序稍有变动就崩
如何安全地在命名空间里复用函数名
核心原则：**别让 PHP 去猜你想调哪个函数**。显式使用全限定名是最稳妥的做法。
- 在命名空间内调用全局函数，必须写成
oo()（开头反斜杠表示根命名空间） - 在命名空间内调用本空间函数，直接写
foo()即可，无需self::foo()（那是静态方法） - 跨命名空间调用，必须写全名，例如
A oo()或Bar() - 不要依赖
use function来 alias 全局函数进当前命名空间（PHP 7.0+ 支持，但容易混淆调用来源，且 IDE 支持弱）
示例：
立即学习“PHP免费学习笔记（深入）”；
namespace App;
function json_encode($data) { return 'fake'; } // ❌ 千万别这么干！会覆盖全局 json_encode正确做法是避免重名，或明确区分：
namespace App;
function safe_json_encode($data) { /* ... */ } // ✅ 换名require 和自动加载对函数作用域的影响
PHP 函数不是类，不支持“按需加载”，所有 function 定义在解析阶段就注册进符号表。这意味着：require 一个含函数定义的文件，等价于把那段代码 inline 进当前作用域。
- 如果 A.php 定义了
function helper()（无 namespace），B.php 在namespace Lib;下也定义了function helper()，那么谁先被 require，谁就“赢”，后 require 的直接 fatal - Composer 的
autoload.files会按固定顺序一次性 require 所有函数文件——这个顺序不可控，尤其当多个包都往全局扔函数时，极易撞车 - 没有类似
class_alias的函数别名机制，也没有“函数自动延迟加载”；想隔离，只能靠命名约定或封装成类的静态方法
为什么不用类静态方法代替全局函数
这不是风格偏好问题，而是作用域隔离刚需。函数名全局唯一，类方法天然受类名约束，命名空间也自然生效。
-
AppHelper::json()和VendorJson::encode()完全不冲突，哪怕都叫json - IDE 能准确跳转、类型推导更稳；
phpstan/psalm对静态方法的分析远强于裸函数 - 测试时可 mock 静态方法（用
php-mock等库），而全局函数几乎无法单元测试替换 - PHP 8.2 开始已警告
Dynamic function call类型问题，裸函数在严格模式下越来越难维护
真要用函数，至少确保它只在一个地方定义、不跨命名空间复用、不和标准库函数同名——这点比想象中难守。
