autoload.php 需手动 dump-autoload 更新：仅在修改 psr-4 路径、新增类或使用 classmap 时触发，改类内容无需 dump；常用参数包括 -o（优化）、--classmap-authoritative（权威 classmap）和 --no-dev。
autoload.php 文件没更新？先确认是否真需要手动 dump
Composer 的 autoload.php 不是每次改了类文件就自动重生成的——它只在安装、更新包，或显式执行 dump-autoload 时刷新。如果你改了 psr-4 映射的目录结构、新增了类但 new MyClass() 报 Class not found，大概率是 autoload 没同步。
- 运行
composer install或composer update会自动触发 dump，无需额外操作 - 仅修改类文件内容（不增删类、不改命名空间/路径）通常不需要 dump，autoloader 缓存的是路径映射，不是类体
- 如果用的是
classmap方式且新增了未声明的 .php 文件，必须dump-autoload才能收录
dump-autoload 常用参数组合及适用场景
默认 composer dump-autoload 只生成标准 PSR-4/PSR-0 映射；加参数才能启用优化或适配特殊需求：
-
composer dump-autoload --optimize（简写-o）：生成 classmap 加速加载，适合生产环境，但会忽略files类型的全局函数文件 -
composer dump-autoload --classmap-authoritative（常和-o连用）：告诉 autoloader “classmap 就是全部”，不再 fallback 到文件系统扫描，性能更高，但要求所有类必须被 classmap 覆盖，否则直接报错 -
composer dump-autoload --no-dev：跳过autoload-dev部分，适合部署时减小 autoload 体积
示例：生产环境常用 composer dump-autoload -o --classmap-authoritative，但本地开发调试时别加 --classmap-authoritative，否则新增测试类可能瞬间 500。
为什么 dump 后还是 Class not found？检查这三处
常见错误不是命令没跑，而是配置或路径本身有问题：
-
composer.json里autoload的psr-4声明路径末尾漏了\（如"App\": "src/App"应为"App\": "src/App/"），会导致命名空间解析失败 - 类文件实际路径与命名空间不匹配，比如命名空间是
AppControllers，但文件放在src/controllers/HomeController.php（小写 controllers），Linux 环境下直接失效 - 用了
files自动加载函数文件，但该文件里定义了类——files只载入函数，不注册类，这类“伪类”不会出现在 autoload map 中
autoload 生成位置和加载时机的冷知识
vendor/autoload.php 是入口文件，但它本身不包含映射逻辑；真正干活的是 vendor/composer/autoload_*.php 这些生成文件。它们由 dump-autoload 写入，内容取决于当前 composer.json 配置和已安装包。
- 每次
dump-autoload都会覆盖旧的autoload_*.php，所以不要手动编辑这些文件 - 如果项目有多个 Composer 环境（如主项目 + 子模块各自 composer.json），注意当前工作目录是否在正确根目录下，否则 dump 的是错项目的 autoload
-
autoload-dev的映射只在require-dev包存在时生效，CI 环境若用--no-dev安装，则 dev 下的测试类路径根本不会进 autoload
最易忽略的一点：IDE（如 PHPStorm）的代码提示依赖自己解析 composer.json，不是读取生成的 autoload 文件，所以即使 dump 失败，IDE 可能仍显示类可跳转——但运行时照样报错。
