php中唯一可靠的字符串拼接方式是.和.=运算符；+会转数字导致静默错误，引号类型不影响拼接能力，长拼接应避免循环中用.而改用数组+implode或.=以提升性能。
PHP 里 . 和 .= 是唯一靠谱的字符串拼接方式
PHP 没有类似 Python 的 f-string 或 JavaScript 的模板字面量，也没有 Ruby 那种隐式插值。所有字符串拼接都靠 .（点号）运算符，赋值拼接用 .=。别试图用 +，它会强制转数字再相加，"a" + "b" 结果是 0，不是报错而是静默失败。
常见错误现象：echo "Hello" + "World"; 输出 0；或者在数组键里误用加号：$arr["prefix" + $id] = 1; 导致键变成 0。
-
.是二元运算符，左右操作数都会被强制转为字符串（按 PHP 类型转换规则），但仅限于拼接场景 -
.=效率略高，尤其循环中追加内容时，避免反复创建新字符串对象 - 不要混用引号类型期望自动解析变量：双引号里写
"$a.$b"是拼接两个变量的值，不是调用.运算符；真正执行拼接还得靠.
长字符串拼接时，别在循环里反复用 . 拼单个字符
比如写日志、生成 HTML 片段、组装 SQL（不推荐但现实存在）时，有人习惯这样：
$html = "";
foreach ($items as $item) {
$html = $html . "<div>" . htmlspecialchars($item) . "</div>";
}这在小数据量下没问题，但每次 . 都会分配新内存、复制旧内容，时间复杂度是 O(n²)。1000 条数据可能慢好几倍。
立即学习“PHP免费学习笔记（深入）”；
- 改用数组收集 +
implode()：先$parts[] = "...";，最后implode("", $parts) - 或直接用
.=：比= $x . $y少一次复制，底层优化更友好 - 如果内容来自文件或数据库流，考虑用
ob_start()+include模板，或专用构建器（如 Twig），而非硬拼
双引号、单引号、Nowdoc/Heredoc 对拼接行为没影响
引号类型决定的是「变量是否展开」和「转义是否生效」，不是拼接能力。无论哪种，要连接多个片段，还是得靠 .。
常见误解：以为 "$a$b$c" 是“自动拼接”，其实这只是变量插值语法糖，等价于 $a . $b . $c，底层仍走 .。一旦中间有非变量内容，比如 "prefix_$a_suffix"，就只能靠 . 拆开处理。
- 单引号字符串不解析变量，
'$a . $b'就是字面量五个字符，不是拼接结果 - Nowdoc 和 Heredoc 同理：它们只是定义多行字符串的方式，内部不支持表达式求值，
不会执行拼接 - 想在 Heredoc 里嵌入动态内容，必须提前拼好再传入：
，其中 <code>$result已是拼接完成的字符串
注意 str_replace、sprintf 等函数不是拼接替代方案
有人看到 sprintf("Hello %s, you have %d new messages", $name, $count) 就以为这是“高级拼接”，其实它本质是格式化，不是连接。它无法处理不确定数量的片段，也不适合增量构造。
典型误用：$sql = sprintf("SELECT * FROM users WHERE id IN (%s)", implode(",", $ids)); —— 这里 sprintf 只包了一层，真正拼接逻辑在 implode 和外部 . 上。
-
sprintf适合固定结构 + 少量变量填充，参数类型检查严格，但性能略低于直接. -
str_replace是文本替换，不是拼接工具；拿它做模板渲染容易出编码、转义漏洞 - 真要动态组合大量字段（比如 API 响应体），优先考虑
json_encode()或数组转字符串前的规范化处理，而不是手工拼 JSON 字符串
最易被忽略的一点：PHP 8.0+ 引入了对字符串字面量中变量插值的扩展支持（如 "{$obj->method()}"），但它依然不改变 . 的核心地位——所有非字面量部分，最终都要靠 . 或其等价操作落地。写长字符串时，先想清楚结构是静态为主还是动态为主，再选数组收集、.= 追加，还是干脆换模板引擎。
