composer自动加载不依赖已废弃的_autoload函数，而是通过spl_autoload_register注册加载器；需正确配置composer.json的autoload段（如psr-4）、执行composer dump-autoload，并确保vendor/autoload.php最先引入。
Composer 的自动加载不是靠 _autoload 函数配置的——这个函数早已被弃用，且 Composer 根本不读它。你如果在 composer.json 里配了 autoload 却发现类没加载，大概率是混用了旧式手动注册或漏跑了 composer dump-autoload。
为什么 _autoload 和 Composer 无关
PHP 5.1 引入的 _autoload 是全局函数钩子，5.3 起已被 spl_autoload_register() 取代，7.2 彻底废弃。Composer 从第一天起就只依赖 spl_autoload_register 注册自己的加载器，完全绕过 _autoload。你在代码里定义 _autoload，Composer 不会识别、不会调用、也不会报错——它只是安静地忽略。
- 运行
php -v确认 PHP 版本 ≥ 7.4（推荐），避免踩兼容性坑 - 删掉所有自定义的
function _autoload($class) { ... }定义，否则可能和 Composer 加载器冲突 - 检查是否误把
vendor/autoload.php当成可编辑文件——它由 Composer 自动生成，手改会被覆盖
composer.json 中 autoload 配置怎么写才生效
必须在项目根目录的 composer.json 里声明 autoload 段，并执行生成命令。常见写法有三类，选错类型会导致 Class not found：
-
psr-4（推荐）：适合现代命名空间结构，如
"App\": "src/"表示AppFooBar对应src/Foo/Bar.php -
classmap：适合传统无命名空间的类文件，如
"autoload": {"classmap": ["lib/", "legacy/"]}，需运行composer dump-autoload扫描生成映射表 -
files：直接 require 全局函数文件，如
"files": ["src/helpers.php"]，每次请求都会加载，慎用
示例：
{
"autoload": {
"psr-4": {
"MyApp\": "src/"
}
}
}改完后必须运行 composer dump-autoload（开发时加 -o 生成优化版）。
为什么 require 'vendor/autoload.php' 必须放在最前面
这是整个自动加载链的入口。如果它出现在其他 require 或 include 之后，而那些文件又提前触发了类加载（比如 new 了一个未声明的类），就会因 autoloader 尚未注册而报 Class not found。
- 确保它是脚本中第一个
require，不要包在条件里、函数里或 try/catch 里 - 不要用
include替代require——失败时不报错，问题更难排查 - CLI 脚本和 Web 入口都要单独引入，
vendor/autoload.php不会跨作用域自动生效
调试加载失败：快速定位是路径、命名空间还是缓存问题
遇到 Class 'XXX' not found，按顺序查这三点：
- 运行
composer show --path XXX（把 XXX 换成你的命名空间前缀），看是否识别到 autoload 配置 - 用
composer dump-autoload -v查看扫描日志，确认目标文件是否被纳入（尤其 classmap 模式） - 临时加一行
var_dump(get_included_files());，确认vendor/autoload.php确实被加载了 - 如果刚改过
composer.json但没跑dump-autoload，90% 的问题就出在这一步
PSR-4 映射对大小写敏感，Linux 下 src/Foo/Bar.php 无法加载 new fooar()；Windows 虽不敏感，但部署到生产环境必挂——这点容易被本地开发掩盖。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
