Docker化Bedrock WordPress项目GitLab流水线PHPStan报错原因排查

• Composer缓存不一致：GitLab流水线大概率复用了旧的Composer缓存，导致WordPress核心的类型定义文件（比如phpstan-wordpress扩展或WP自带的stubs）没正确更新加载。本地是全新安装或缓存为最新状态，而流水线缓存里可能存着不完整/过时的类型信息，PHPStan识别不了WordPress函数（比如add_filter）的正确参数签名，就会乱报错误。

• Docker构建缓存搞鬼：Docker镜像构建时如果复用了旧缓存层，可能导致Composer安装的依赖（包括WP核心和PHPStan相关扩展）没完整更新。比如某次构建里WP核心的stubs文件没被正确复制到容器，重新构建时缓存失效（比如composer.json有变动、手动清缓存），依赖就会被正确安装，PHPStan就能正常识别add_filter这类函数的签名了。

• PHPStan配置加载出问题：流水线环境中，PHPStan的配置文件（比如phpstan.neon）可能没正确加载WordPress类型扩展。本地环境里phpstan-wordpress扩展配置正常，但流水线因为环境变量、路径问题没启用扩展，PHPStan只能用默认PHP函数规则，认不出add_filter这类WordPress特有的函数签名，自然会误报参数错误。

• 依赖安装不完整：GitLab流水线的Composer安装过程可能因为网络波动、镜像源不稳定，导致依赖安装半截。比如WP核心的stubs文件没下全，PHPStan读不到add_filter的正确函数定义就报错；重新运行时依赖安装完整，问题就自动消失了。

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