classmap 配置必须写在 composer.json 的 autoload 或 autoload-dev 下的 classmap 数组中，路径末尾带 / 表示递归扫描目录（如 "lib/"），不带 / 表示单个文件（如 "includes/config.php"），错写为 "lib" 会被当作文本读取而报错；支持 glob（如 "legacy/DB_.php"），但不支持 * 通配符，路径须真实存在，Windows 下统一用 / 分隔符。
classmap 不是“生成”出来的独立文件，而是 composer dump-autoload 扫描后硬编码进 vendor/composer/autoload_classmap.php 的静态映射数组；它只在你明确配置了 classmap 路径或加了 -o 参数时才出现，且不会自动更新。
classmap 配置写在哪？路径怎么填才有效
必须在 composer.json 的 autoload（或 autoload-dev）下声明 classmap 数组，值为字符串路径列表：
- 路径末尾带
/表示递归扫描整个目录（如"lib/"） - 不带
/表示单个文件（如"includes/config.php"），错写成"lib"（无斜杠）会被当作文本读取，报Could not scan for classes - 支持 glob（如
"legacy/DB_*.php"），但不支持**递归通配符 - 路径必须真实存在，否则
dump-autoload会 warning 但继续执行 - Windows 下统一用
/分隔符，Composer 内部自动适配
dump-autoload -o 为什么没生成 classmap？
执行 composer dump-autoload -o 却没看到 autoload_classmap.php 变大或加载变快，常见原因有：
- 项目没配
classmap，又没用psr-4或psr-0——-o只对已声明的自动加载规则生效 - 只改了代码但没重跑命令：新增类、改类名、增删文件后，
classmap不会自动刷新 - 误以为
composer optimize-autoloader是合法命令（它根本不存在） - 用了
files加载方式但没配合-o，函数不会被索引，只有类/接口/trait 进 classmap
真正触发 classmap 生成的最小动作是：composer dump-autoload -a（强制重扫所有 classmap 路径），比 -o 更彻底。
classmap-authoritative 有什么实际影响
设 "config": { "classmap-authoritative": true } 后，Composer 自动加载器会跳过所有 fallback 查找（包括 PSR-4 文件系统遍历），遇到未登记类直接抛 Class not found。这意味着：
- 每次
new MyClass()或class_exists()只查一次数组，省掉 2~5 次file_exists()系统调用 - 本地开发慎用：IDE 断点、热重载、运行时
require的类都会失效 - 生产环境必须搭配
--no-dev使用，否则autoload-dev下的测试类也会被塞进主 classmap - 若漏扫关键路径（比如
tests/或app/Exceptions/），上线后立刻报错，且错误提示和开发时不一致
什么时候该用 classmap，什么时候不该
classmap 是兜底方案，不是通用解法：
- 必须用：老项目含无命名空间类、
.inc文件、一个文件多个类、类名与文件名不一致（如Utils.php里有class ArrayHelper） - 建议用：稳定上线项目，追求启动性能，且能接受构建时强约束（Docker 构建、CI/CD 打包阶段加
-o --classmap-authoritative --no-dev） - 别用：开发中频繁增删类、依赖 IDE 实时发现、使用 Symfony Server 或 Laravel Vite HMR——classmap 会绕过文件监听机制
- 特别注意：
autoload_classmap.php是纯 PHP 数组，APCu 缓存的是 autoloader 实例本身，不是这个文件；要生效得配apc.stat=0并手动调用$loader->setApcuPrefix()
最易被忽略的一点：classmap 只认词法声明，不执行代码。哪怕 if (false) { class A {} } 也会被登记——这既是优势（不漏类），也是隐患（可能引入死代码路径）。
