PHP数组非线程安全，高并发下性能瓶颈在于使用方式而非结构本身；应减少争用、分层缓存、合理复用，优先用OPcache常量、SplFixedArray、APCu/Redis缓存及语义优化。
PHP 数组本身不是线程安全的，但在高并发 Web 场景中（如 Laravel、ThinkPHP 或原生 Swoole 服务），真正影响性能的往往不是数组结构本身，而是其使用方式、生命周期和底层存储位置。优化重点不在“改数组”，而在“减少争用、避免重复、分层缓存、合理复用”。
避免在全局/静态作用域频繁读写大数组
把配置、字典数据等一次性加载到全局数组（如 $GLOBALS['config'] 或 static $cache = []），看似方便，但在多进程（PHP-FPM）或多协程（Swoole）下容易引发内存膨胀或脏读风险。尤其当数组被反复 array_merge、array_filter 或深度遍历时，CPU 和内存开销会随并发数线性上升。
- 配置类数据优先走 OPcache 编译后常量或只读数组（define() 或 const 定义的数组需 PHP 8.2+ 支持）
- 运行时动态数组尽量限定作用域（如封装在 Request 生命周期内，用完即弃）
- 若必须共享，改用 APCu 或 Redis 存储序列化数组，用时反序列化，避免进程间拷贝
用 SplFixedArray 替代动态数组处理固定长度数据
当业务明确知道数组元素数量且不频繁增删（如日志字段映射、API 响应模板、批量订单状态码集合），SplFixedArray 比普通数组节省约 20–30% 内存，并提升索引访问速度，因为它绕过了 PHP 的 HashTable 结构，直接操作连续内存块。
- 初始化时指定容量：$arr = new SplFixedArray(1000);
- 仅支持数字索引，不可用 foreach 直接遍历，需用 for 或 toArray()（后者会转成普通数组，慎用）
- 适合批量数据预处理场景，例如：将数据库查出的 10w 条 ID 预分配进固定数组再做 in 查询优化
对高频读、低频写的数组启用读写分离缓存
比如用户权限菜单、地区编码表这类“读多写少”的数组，每次请求都从 MySQL 或 JSON 文件重建，会成为瓶颈。可结合 APCu（进程级）+ Redis（跨进程）构建两级缓存。
立即学习“PHP免费学习笔记（深入）”；
- 首次加载后写入 APCu：apcu_store('menu_tree', $tree, 3600);
- 后续请求先查 APCu，未命中再查 Redis，仍无则重建并双写
- 写操作（如后台更新菜单）触发 apcu_delete('menu_tree') + redis->del('menu_tree')，避免缓存不一致
在 Swoole 协程环境中慎用引用与静态数组
Swoole 的协程是用户态调度，同一 Worker 进程内多个协程共享内存。若在协程函数中使用 &$data 引用一个全局数组，或在 static 变量里缓存数组，极易导致协程间数据污染（A 协程修改了，B 协程读到脏数据）。
- 协程内变量尽量保持局部性，用完即释放；必要共享数据走 Co::getUid() 隔离或 Context 传递
- 禁用 static $cache = [] 缓存数组，改用 Channel 或 Atomic 管理轻量状态
- 如需协程安全的数组操作，可用 Swoole\Table（支持并发读写，但需预定义 schema）
不复杂但容易忽略：多数高并发下的“数组慢”，其实是没分清“该不该放数组里”——能用字符串拼接的不用 array_map，能用 key_exists 判断的不用 in_array，能用 isset($arr[$key]) 的不用 array_key_exists。优化从语义选择开始，而不是等压测后再重构。
