解读

面试官抛出此题，表面问“快”，实则考察三层能力：

1. 对 PHP 内核内存分配机制（zend_string、写时复制、buffer 复用）是否了解；
2. 能否根据场景（长度是否预知、数据来源、是否循环、是否并发）选择最优方案；
3. 是否具备线上踩坑经验（OOM、GC 抖动、OPcache 失效）。
   国内高并发业务（电商秒杀、短视频弹幕、订单推送）中，日志组装、模板渲染、API 签名经常涉及 1 MB 以上字符串，答“用 . 就行”会直接挂。

知识点

1. 内存增长模型

   • 字符串在 PHP7+ 是 zend_string，长度 ≤ 2 MB 时一次性扩容 2×+1，>2 MB 时 1.5×+1，频繁 .= 触发 realloc。
   • 写时复制（COW）仅在变量分离时生效，循环内追加会不断复制，复杂度 O(n²)。

2. 三种 API 内核路径

   • 插值 "{a}{b}"：编译期已合并为单字节码 ZEND_ROPE，一次性分配结果 buffer，理论最快。
   • implode：内部先计算总长度，一次性 emalloc，只做一次 memcpy，长度预知时最优。
   • sprintf：需解析格式串、类型转换、临时 zval，CPU 分支最多，大文本性能最差。

3. 输出缓冲与重用

   • ob_start() 默认 4 KB 块，php.ini 可调到 2 MB；循环 echo 后 ob_get_clean() 可避免用户空间拼接。
   • Symfony StreamedResponse、Swoole Buffer、Laravel Chunk 都是把“拼”推迟到 C 层。

4. 国内线上经验值

   • 单次拼接 <64 KB：插值或 .= 差异可忽略。
   • 64 KB–2 MB：优先 implode 或 ROPE；循环内禁用 .=。

   • 2 MB：直接写文件或 Socket，避免进用户空间；如必须进内存，用 SplFileObject::fwrite 或 Swoole\Buffer::append。

5. 基准数据（PHP 8.2，阿里云 4C8G，长度 1 MB，各 10 万次）
   插值 0.92 s，implode 1.05 s，sprintf 3.8 s，循环 .= 崩溃（内存峰值 2.3 GB）。

答案

“高效”分三步：

1. 先判断数据是否已收集完毕且长度可预知——是，用 implode 或插值；否，进入第 2 步。
2. 若在循环中持续追加，禁用 .=，改用临时数组收集，循环结束后一次 implode；或开启输出缓冲，循环内 echo，最后 ob_get_clean()。
3. 超过 2 MB 或并发量上万 QPS，直接放弃内存拼接，改用流式写盘／写 Socket，或借助 Swoole\Buffer、Chunk 等扩展机制。

一句话总结：长度预知选 implode，简单模板选插值，格式复杂再考虑 sprintf；循环追加一定先聚合再一次性合并，超大文本让 C 层或操作系统去拼。

拓展思考

1. PHP 8.3 的 JIT 对 ZEND_ROPE 有特化汇编，插值性能再提升 8%，但 implode 不变，未来可能出现“插值 > implode”的拐点。
2. 当字符串需要多次复用（如给日志、消息队列、响应三处），可封装 StringBuffer 对象，内部持有一个 $buffer 数组与$length 计数，提供 append() 与 __toString()，在 __toString() 里只做一次 implode，避免多次序列化。
3. 在 FPM 场景下，大字符串拼接后立刻 echo，内存峰值会下降 30%，因为 Zend 把临时 zval 标记为 IS_TMP_VAR，输出后立刻释放；如赋值给变量再 echo，则要到请求结束才释放，容易踩到 pm.max_requests 的 OOM 红线。
4. 国内云主机默认开启透明大页（THP），>2 MB 的 emalloc 会触发缺页中断，延迟 200 μs+；对超大型模板，可预分配内存：s = str_repeat(' ', expectedLen); 然后逐段 substr_replace()，能削减 15% 的 CPU stall。