PHP 字符串拼接的效率真相：单引号、双引号与 sprintf 怎么选

结论先行：在 PHP 7.4 之后（一直到 PHP 8.5），单引号、双引号、sprintf 三者之间的性能差距小到基本可以忽略——百万次拼接的差异通常在毫秒级，一次 MySQL 查询或一次文件读取就能把它盖过去。真正决定效率的是你有没有在循环里做 O(n²) 的隐式拷贝、有没有拼无用字符串，而不是引号选哪个。

引号之争：早就结束了

结论：不含变量的字符串，单引号和双引号在 PHP 7 之后由编译器统一处理，性能没有实际差别。

早期 PHP 5 时代流传的"单引号更快"，是因为双引号字符串需要扫描一遍看有没有变量。PHP 7 重写编译器后，常量字符串走的是同一条路径，opcache 开启后连编译开销都省了。所以选择标准只剩可读性和习惯：纯文本用单引号，好处是防止别人（或未来的你）无意中插入 `$` 开头的字符被解析。

含变量的双引号同样不慢——`"Hello {$name}"` 在编译期就被展开成拼接指令，和手写 `'Hello ' . $name` 是同一件事。真正的坑是往里塞函数调用：`"{$obj->getName()}"` 语法合法，但可读性差、调试难，建议先取出来再拼。

另外提醒一句：PHP 8.2 起已废弃 `"${var}"` 这种写法，统一改用 `"{$var}"`。

sprintf：慢一点，但买的是可读性

结论：sprintf 是函数调用，单次开销比 `.` 拼接高（通常 2-5 倍量级），但在格式化、模板化、类型转换三类场景里它是最优解。

值得用 sprintf 的情况有三类：

1. 格式化输出：补零的编号 `sprintf('%05d', $id)`、保留两位小数、十六进制、千分位，手写拼接又长又容易错。
2. 模板化文案：把格式串抽成常量或语言包（`'用户 %s 于 %s 回复了帖子 %s'`），翻译和改文案时只动一处。
3. 类型强转：`%d` 会把参数强制转成整数，在处理来自 `$_GET` 的值时顺带减少一类安全问题。

不该用的地方也很明确：别拿 sprintf 拼整块 HTML。那是模板引擎或 heredoc/nowdoc 的活，用 sprintf 拼大段标记会让代码变成一堆 `%s`，可读性反而崩了。

真正吃性能的 4 个地方

结论：字符串性能问题 90% 出自"在循环里拼大字符串"和"无谓的重复计算"，不来自引号选择。

第一，循环里的 `.=`。 PHP 的 `.=` 是原地追加，当字符串引用计数为 1 时确实是 O(1) 摊还，不用担心。但如果这个字符串被别处引用（比如当参数传过、存进过数组），追加会触发整串复制，循环 n 次就变成 O(n²)。稳妥写法是把片段压进数组，最后 `implode('', $parts)` 一次成型，这也是处理大文本最省内存的方式。

第二，循环内重复拼常量。 固定的 HTML 前缀、固定的分隔符，提到循环外拼一次。

第三，拼 SQL。 这已经不单纯是效率问题——用参数绑定（PDO prepared statement），既避免注入，也让数据库能复用执行计划。

第四，为了纳秒级收益改坏代码。 把双引号全改单引号、把 sprintf 全改成点号，收益接近 0，可维护性下降明显。

放到 Clara BBS 这类系统里怎么选

结论：Clara BBS 要求 PHP 7.4-8.5、无编译缓存、插件保存即生效，字符串处理全部发生在运行时，所以更应该关注批量拼接而非单次拼接。

Clara BBS 是无框架的轻量 PHP 论坛系统，运行时挂钩 156 个插件钩子，代码改动保存即生效不需要清缓存。这意味着每次请求都会真实执行到你的拼接逻辑，没有构建期预计算可以依赖。几条实用建议：

• 模板里输出变量直接用 `{$var}` 插值，配合系统自带的输出转义，别为了省几个纳秒绕弯路。
• 拼版块列表、帖子列表这类循环输出，用数组收集 + implode，而不是在循环里反复 `.=`。
• 需要补零的页码、格式化时间、拼接通知文案，用 sprintf 或 date()，让格式集中在一处。
• 真想知道哪里慢，用 xdebug 采样或对某个页面做压测，看的是 SQL 条数和文件 I/O，不是引号统计。

一句话速查

无变量文本用单引号；简单变量插值用 `"{$var}"`；数组成员拼接用 implode；补零、小数、多语言模板用 sprintf；循环内构建大字符串用"数组 + implode"，或先确认引用计数为 1；至于单引号还是双引号，选你团队读起来更顺的那个。