Swoole Table 有128MB共享内存硬上限，实际行数受字段大小限制（如5字段每行257字节仅约50万行），且初始化后不可扩容，set()失败静默返回false；仅TYPE_INT字段的incr()为CPU级原子操作，多字段更新须手动lock/unlock。
Swoole Table 不是“随便塞数据的内存容器”，它有明确的硬性边界，用错就会 set() 失败、数据被静默丢弃，且错误无提示。
Table 最大能存多少行？别信理论值
创建时传入的 $size（比如 1000）会被自动向上取整为最近的 2 的幂（实际分配 1024 行），但底层最大支持行数是 0x80000000（21.47 亿）。这数字毫无意义——你根本撑不到那儿。
真正卡死你的，是单实例 **128MB 共享内存上限**。例如：每行定义 5 个字段（1 个 TYPE_INT + 4 个 TYPE_STRING，各 size=64），单行约占用 257 字节，那最多只能存约 50 万行。再加一列或拉长字符串，行数立刻腰斩。
实操建议：
- 用
memory_get_usage(true)在初始化后测一次 Table 占用，确认是否接近 128MB - 字符串字段的
size按字节算，中文按 UTF-8 算（1 字符 ≈ 3 字节），别按字符数填 - 超过 32 列？直接报错，拆成多个 Table 或换 Redis
TYPE_INT 字段的 incr() 是唯一真原子操作
set() 和 get() 默认不加锁，两个进程同时写同一行，后写者覆盖前写者。只有 incr() 对 TYPE_INT 字段才是 CPU 级原子指令，无需手动 lock/unlock。
常见错误现象：
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
- 用
set()更新用户登录次数，高并发下计数少于实际请求量 - 把字符串字段误当计数器，调
incr()报致命错误：Fatal error: Uncaught Error: Call to undefined method Swoole\Table\Row::incr() - 以为
lock($key)加了就行，却忘了在业务逻辑结束前调unlock($key)，导致整行被永久锁死
实操建议：
- 纯计数场景（在线人数、请求总量）——只用
Swoole\Atomic，比 Table 更快、更轻量 - 多字段组合更新（如
last_login_time+login_count）——必须lock($key)包裹整个读-改-写流程 -
lock()后务必配对unlock()，推荐用try/finally结构兜底
Table 不是线程安全的“免配置缓存”
文档说“内置行锁自选锁”“用户层完全不需要考虑同步”，这话只在你严格遵守使用前提时才成立：字段类型正确、不超内存、不跨进程误用、不混用非原子操作。
真实生产中踩坑最多的是：
- 把 Table 当作通用键值存储，往里塞序列化数组或 JSON 字符串，结果
size预估不足，set()返回false却没检查返回值 - 在
onClose回调里没清理 Table 中的连接状态行，导致“已断开用户”仍被计入在线统计 - 误以为多 Worker 进程共享同一个 Table 实例——其实每个进程要各自
new Swoole\Table()，靠共享内存地址映射实现数据互通，初始化参数必须完全一致
性能影响很实在：单线程读写峰值约 100–200 万次/秒，但一旦触发行锁争抢（比如 8 个 Worker 同时写同一行），吞吐会断崖下跌。不是锁慢，是锁本身意味着竞争已经发生。
最易被忽略的一点：Table 初始化后无法扩容，set() 失败也不会抛异常，只静默返回 false。所有写入操作必须检查返回值，否则数据就丢了，连日志都难排查。
