PHP OPcache是否支持基于脚本校验和缓存的配置？

好问题！这确实是多站点/多实例部署场景下OPcache资源浪费的常见痛点，我来一步步解答你的疑问：

1. OPcache是否具备基于校验和/MD5/CRC值缓存的功能？ #

OPcache会计算脚本内容的校验和（默认是CRC32），但这个值的作用是验证文件是否被修改，而非作为缓存的唯一标识。

默认情况下，OPcache的缓存键由文件路径+inode+修改时间共同组成——也就是说，哪怕两个脚本内容完全一致，只要它们的文件路径不同（inode也不同），OPcache就会把它们当成两个独立文件，分别编译、缓存，占用两份资源。

校验和仅在OPcache验证文件有效性时发挥作用：如果文件修改时间没变但校验和变了，OPcache会重新编译该脚本；如果校验和不变，就直接复用缓存的opcode。

2. 能否让OPcache识别内容相同的脚本，减少多WordPress实例的资源占用？ #

默认情况下不行，但有几个实用的解决方案可以解决这个问题：

方法一：共享核心文件+符号链接 #

这是最常用的优化方案：

• 将WordPress的核心文件（wp-includes、wp-admin目录）放到一个共享目录中
• 给每个WordPress实例创建指向这个共享目录的符号链接，而非在每个实例中复制一份核心文件

这样一来，所有实例的核心脚本都会指向同一个真实文件路径（inode相同），OPcache只会编译、缓存一次这些核心文件，直接节省99%的核心文件缓存资源。

方法二：使用硬链接（谨慎使用） #

硬链接会让多个路径指向同一个inode（本质是同一个文件），OPcache会识别为同一个文件，只缓存一次。不过硬链接局限性较大：比如不能跨文件系统，删除原文件后硬链接依然存在，可能引发问题，所以不如符号链接灵活。

有没有官方配置直接让OPcache基于内容哈希缓存？ #

目前PHP官方并没有提供这类配置项。OPcache的设计初衷是绑定到文件实体而非内容本身——这是因为PHP脚本的执行可能依赖所在目录的上下文（比如相对路径引入的文件、__DIR__常量等），如果单纯基于内容哈希缓存，可能会引发上下文不一致的问题。

额外注意事项 #

• 若使用共享核心文件方案，更新WordPress核心时只需更新共享目录的版本，所有实例会同步生效，同时OPcache会自动检测到文件变化并重新编译（因为修改时间变更）
• 确保opcache.max_accelerated_files的配置值足够覆盖总文件数（共享核心后，这个值可以大幅降低）
• 可以通过opcache_get_status()函数查看OPcache的缓存状态，确认核心文件是否只被缓存了一次

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