autoloader按需加载class files的性能损耗及影响咨询

不同加载方案的性能对比 #

• 和全量引入所有类文件的方案比，autoloader 按需加载的性能有明显优势。全量引入不管当前请求是否用到某个类，所有文件都会走磁盘读取、语法解析、opcode 编译的全流程，未命中的类全是无效开销。项目里类的数量越多、单请求实际用到的类占比越低，全量加载的浪费就越夸张——普通 Web 请求通常只用到全项目 10%~30% 的类，这种场景下全量加载的耗时可能是 autoloader 的数倍甚至数十倍。
• 和手动精准引入所需类文件的方案比，合规实现的 autoloader 确实存在极微小的固定开销，主要来自两部分：一是 SPL 自动加载回调的触发成本，二是类名到文件路径的解析成本（比如按 PSR-4 规则做命名空间到目录的字符串转换、查询预生成的类映射表）。在生产环境开启 opcache 的前提下，这部分开销占单请求总耗时的比例通常不到 0.5%，完全到不了需要感知的程度，远低于手动维护全项目类引入列表的人力成本。

别信网上十几年前说 autoloader 性能差的老文章，那时候 opcache 还没普及，不少开发者写的 autoloader 会递归扫目录、反复做文件存在性判断，那种劣质实现才会有明显性能问题，和 autoloader 模式本身没关系。

对预编译、缓存机制的影响 #

• 对 opcache 编译、缓存没有任何负面影响。opcache 是按文件粒度缓存编译后 opcode 的，不管你是手动写 require/include 引入文件，还是通过 autoloader 触发引入，只要文件被加载过一次，opcache 就会缓存对应的编译结果，下次加载直接走缓存，行为完全一致。PHP 7.4 之后推出的 opcache 预加载（preload）特性也可以完美搭配 autoloader 使用，你只需要在预加载脚本里通过项目自身的 autoloader 加载需要常驻内存的类即可，不存在兼容问题。
• 可以通过类映射缓存进一步压减 autoloader 开销。如果用的是遵循 PSR-4 规则的目录映射式 autoloader，第一次加载类时会有路径拼接、文件定位的微小开销，生产环境可以提前生成全量「类名=>文件路径」的映射数组（比如 Composer 自带的 composer dump-autoload -o 命令就是做这个的），autoloader 直接查数组就能拿到文件路径，能把本来就极低的解析开销压到几乎为 0。
• 不会和上层的类缓存、注解缓存、代理类生成等机制冲突。类加载完成后的反射、注解解析、类改写等逻辑，和类是通过什么方式加载的没有关系，只要你的缓存逻辑以类名作为唯一标识，就不会因为用了 autoloader 出现缓存失效或者异常。

内容的提问来源于stack exchange，提问作者theking2