swoole\table 不会自动 rehash 且无扩容机制；其容量由哈希桶数（size）和行大小（item_size）共同决定，冲突比例超 0.7 时 set() 直接失败。
直接说结论：Swoole\Table 不会自动 rehash，也没有传统意义上的“扩容”机制；它的容量上限由 哈希桶数（size） 和 行大小（item_size） 共同决定，一旦哈希冲突比例超过阈值（默认 0.7），set() 就会失败——这不是性能下降，而是直接拒绝写入。
哈希桶数 size 不是行数，而是哈希表底层数组长度
很多人误以为 new Swoole\Table(1024) 表示“最多存 1024 行”，其实它表示分配了 1024 个哈希桶（slot）。由于底层是开链法哈希表，每个桶可挂多个节点，但实际能存多少行，取决于：
- 哈希函数分布是否均匀（key 的散列质量）
- 冲突比例限制（
conflict_proportion，默认 0.7，不可修改） - 每行占用内存（
item_size）是否过大
例如：size = 1024，item_size = 256 字节 → 理论最大行数 ≈ 1024 × 0.7 ≈ 716 行（不是 1024 行）；若 item_size 升至 1024 字节，总内存不变，但可用行数直接跌到约 179 行。
列定义 size 决定固定内存占用，不是“最大字符数”
$table->column('name', Table::TYPE_STRING, 64) 中的 64 是该字段固定分配 64 字节，含末位 <p><code>$table->column('name', Table::TYPE_STRING, 64) 中的 64 是该字段固定分配 64 字节，含末位 \0，实际最多存 63 个 ASCII 字符。它直接影响整行大小：
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
-
TYPE_INT：size 只能是 1/2/4/8，设为 3 或 5 会被静默截断为 4 -
TYPE_FLOAT：固定占 8 字节，size 参数无效 - 所有列 size 加起来 = item_size → item_size 越大，同样 size 下能存的行越少
冲突超限后不 rehash，而是 set() 直接报错
Swoole\Table 没有类似 std::unordered_map::reserve() 或 Redis 渐进式 rehash 的机制。当插入新 key 时：
- 计算哈希值 → 定位桶索引（
hash & (size - 1)，所以 size 必须是 2 的幂） - 遍历该桶链表，检查是否已存在同 key
- 若不存在且当前桶内节点数 ÷ 总桶数 ＞ conflict_proportion（0.7），则
set()返回 false，错误信息为"unable to allocate memory"
这意味着：你无法靠“多写几次触发自动扩容”来规避，必须在创建前就精准预估。
如何预估安全容量并规避写入失败
建议按三步操作：
- 估算 item_size：把所有 column 的 size 加总（注意 TYPE_STRING 含 \0，TYPE_INT 按实际需对齐取 4 或 8）
-
反推最小 size：若预期存 N 行，按
size ≥ ceil(N / 0.7)向上取最近的 2 的幂（如 N=1000 → size ≥ 1429 → 实际取 2048） - 验证内存总量：总内存 ≈ size × item_size，确保不超过共享内存限制（如 128MB 内存下，item_size=512 字节 → 最大 size ≈ 262144）
