PHP项目从单文件脚本进入面向对象和Composer生态以后，namespace与use几乎无处不在。很多“Class not found”错误，表面上看像是类不存在，实际上却可能来自命名空间解析错误、自动加载没有配置、类名拼写不一致，或者开发人员误把use理解成了文件加载机制。
理解这两个关键字，最重要的一点是先把它们彻底分开：namespace定义当前代码中的类、接口、trait、enum以及函数和常量属于哪个命名空间；use则为其他命名空间中的名称建立一个本地别名。use本身不会读取PHP文件，也不会require或include任何代码。
例如：
namespace App\Models;
class User
{
}
这里定义的并不是一个简单叫做User的全局类，而是：
App\Models\User
完整类名可以通过：
$user = new \App\Models\User();
直接使用。
如果当前文件位于：
namespace App\Controllers;
又需要使用App\Models\User，可以写：
namespace App\Controllers;
use App\Models\User;
class UserController
{
public function index()
{
$user = new User();
}
}
这里的use App\Models\User;可以理解为在当前命名空间建立一个本地名称映射：以后当前文件中的User指向App\Models\User。
因此：
new User();
实际上等价于：
new \App\Models\User();
但这个等价关系只存在于当前文件的名称解析环境中，并不会修改User这个类本身的名字。
如果不使用use，也可以直接写完整限定名称：
namespace App\Controllers;
class UserController
{
public function index()
{
$user = new \App\Models\User();
}
}
这种写法同样正确，只是代码比较长。use的价值主要就是避免在业务代码中反复书写完整类名。
这里最容易出现的误解是：有人认为use App\Models\User是在告诉PHP“去App/Models目录寻找User.php”。这并不是use的职责。
PHP首先处理的是类名。至于App\Models\User最终对应哪个文件，通常由Composer的PSR-4自动加载机制解决。例如composer.json中可能存在：
{
"autoload": {
"psr-4": {
"App\\": "src/"
}
}
}
然后执行：
composer dump-autoload
在这种配置下，App\Models\User通常按照PSR-4规则对应到：
src/Models/User.php
当代码执行：
new \App\Models\User();
而这个类尚未加载时，Composer注册的autoload函数才会尝试找到并加载对应文件。
所以整个过程实际上包含两个不同的问题。
第一层是“这个名称到底指向哪个类”，这是namespace和use解决的。
第二层是“这个类的PHP代码什么时候从文件中加载进来”，这是autoload机制解决的。
把这两层混在一起，是大量Class not found问题的根源。
命名空间本身也不是文件目录。很多项目故意让namespace结构与目录结构保持一致，是因为PSR-4让这种映射非常方便，但PHP并没有规定：
App\Models\User
必须物理存在于：
App/Models/User.php
真正建立文件与类之间对应关系的是autoload配置。
再看一个容易出错的例子：
namespace App\Controllers;
class UserController
{
public function index()
{
$user = new User();
}
}
这里没有use App\Models\User;，那么当前代码中的User会按照当前命名空间规则解析。它首先对应：
App\Controllers\User
而不是自动猜测成：
App\Models\User
如果系统里只有App\Models\User，最终就可能得到：
Class "App\Controllers\User" not found
此时解决方案可以是显式使用完整类名：
$user = new \App\Models\User();
也可以使用：
use App\Models\User;
$user = new User();
两者的核心区别只是名称书写方式不同。
命名空间层级再深也不会改变这个规则。例如：
namespace App\Controllers\Admin\Payment;
use App\Models\Order;
use App\Services\PaymentGateway;
class ProcessPayment
{
public function handle()
{
$order = new Order();
$gateway = new PaymentGateway();
}
}
这里当前namespace是：
App\Controllers\Admin\Payment
但use App\Models\Order并不是“相对于当前namespace寻找Order”。它明确指定了完整的类名App\Models\Order。
这也是为什么下面这种写法通常不是你想要的：
use Models\Order;
它并不会因为当前namespace是App\Controllers\Admin\Payment就自动变成：
App\Controllers\Admin\Payment\Models\Order
名称导入有自己的解析规则。为了避免复杂项目中的歧义，实际开发中通常直接使用项目定义的完整命名空间。
还有一个非常重要的概念：全局命名空间。
假设PHP内置类或者某个第三方类位于全局命名空间，例如：
namespace App\Services;
class Test
{
public function run()
{
$date = new \DateTime();
}
}
前面的反斜杠表示从全局命名空间开始解析。因为当前namespace是App\Services，如果直接写：
new DateTime();
PHP会按照名称解析规则寻找当前命名空间下的类，而：
new \DateTime();
明确表示使用全局的DateTime。
当然，也可以写：
use DateTime;
$date = new DateTime();
这同样是在当前文件中建立一个对全局DateTime的名称导入。
use还可以解决同名类冲突。例如：
use App\Models\User as ModelUser;
use App\Entities\User as EntityUser;
然后：
$modelUser = new ModelUser();
$entityUser = new EntityUser();
这里as创建的是别名。它并没有修改原始类名，App\Models\User仍然叫App\Models\User，只是当前文件可以通过ModelUser这个短名称引用它。
大型项目里经常会出现这种情况：两个不同模块都存在User、Request、Config或者Client类。如果全部使用完整类名，代码会非常冗长；如果全部使用短名称，又可能产生冲突。use ... as ...就是解决这种名称冲突的标准机制。
还需要注意，use并不是只能用于类。PHP也支持导入函数和常量，例如：
use function App\Utils\formatPrice;
use const App\Config\DEFAULT_TIMEOUT;
然后可以直接使用：
formatPrice($price);
以及：
$timeout = DEFAULT_TIMEOUT;
这进一步说明use的核心作用是名称导入，而不是文件加载。
另一个容易造成误解的问题是namespace和use在文件中的位置。
典型文件通常写成：
