PHP 8.3 无已知通用内存溢出漏洞，所谓“扫描大项目内存溢出”实为静态分析工具（如 PHPStan、Psalm）配置不当或设计局限所致；应先排除 xdebug、调试输出、自动加载失控等假性溢出，再通过分片扫描、路径过滤、增量分析及合理调高 memory_limit（CLI 方式最优）优化。
PHP 8.3 本身是官方当前主力支持版本（截至2026年10月），**不存在已知需紧急修复的通用内存溢出漏洞**。你遇到的“扫描大项目时内存溢出”，大概率不是 PHP 8.3 的引擎级缺陷，而是漏洞扫描工具（如 PHPStan、Psalm、Rector、或自研静态分析脚本）在分析大型代码库过程中，因自身设计或配置不当导致的内存超限。
先确认是不是真溢出
别急着调配置。很多报错其实是假性溢出：
- 扫描工具启用了 xdebug（比如 --xdebug 开关），单步分析吃掉大量内存；临时去掉 xdebug 再跑一次：
php -d zend_extension= vendor/bin/phpstan analyse - 日志里只报
Fatal error: Allowed memory size of ... exhausted，但没指明具体文件行号——这往往是工具启动阶段加载类过多、自动加载失控所致，检查get_included_files()数量是否远超 200 - 用了
var_dump()或print_r()输出完整 AST 结构体到终端，这类调试残留会瞬间占满内存，删掉再试 - 错误发生在扫描开始几秒内，可能是 max_execution_time 超时被误判为 OOM；加
-v参数看是否卡在某处
针对扫描工具本身的内存优化
主流 PHP 静态分析工具都支持分片、跳过、缓存等机制降低内存压力：
PHP 8.5.12
下载
修复 Core bailout 状态损坏安全问题，以及 BZ2、DOM、PDO、Opcache/JIT 内存与执行错误，改进 Unicode 字素处理、URL 解析、TLS 流状态、信号分发及会话错误处理。
-
PHPStan：用
--configuration=phpstan.neon配置文件限制并行度和内存敏感项，例如禁用高开销规则：checkUninitializedProperties: false；启用增量分析：parameters: { incremental: true } -
Psalm：添加
--no-cache反而有时更省内存（避免缓存膨胀）；对 vendor 目录加<ignoreFiles><directory name="vendor/" /></ignoreFiles> -
Rector：改用单规则运行，例如
rector process src --rules=SetList::DEAD_CODE，避免一次性加载全部规则和节点处理器 - 所有工具都支持路径过滤：只扫
src/，跳过tests/、var/、storage/等非核心目录
安全且有效的 memory_limit 调整方式
如果确认是工具真实需要更多内存，按优先级选择生效方式：
立即学习“PHP免费学习笔记（深入）”；
-
CLI 最可靠：直接启动时指定，不依赖任何配置文件
php -d memory_limit=1G vendor/bin/phpstan analyse -
项目级临时生效：在项目根目录建
.user.ini，写入memory_limit = 768M（需确认user_ini.filename = ".user.ini"已启用） -
慎用 ini_set()：某些工具（如 Psalm）会在初始化阶段就锁定内存限制，脚本开头加
ini_set('memory_limit', '1G')可能无效 - 不要设 -1：无限制可能拖垮整台服务器，尤其在 CI 环境中
长期建议：拆解+缓存+升级
大型项目扫描慢且吃内存，本质是分析粒度太粗。推荐三步走：
- 把单次全量扫描拆成每日增量扫描 + 每周全量扫描，利用工具自身的 cache 目录（如 PHPStan 的
tmp/phpstan）复用结果 - 升级工具到最新稳定版：PHPStan 1.10+、Psalm 5.25+ 均显著优化了 AST 构建内存占用
- 若自研扫描脚本，改用生成器（
yield）流式处理文件列表，避免scandir()一次性载入上万文件路径
