ThinkPHP字符串拼接乱码主因是原始字符串编码不一致与拼接时机不当，需在拼接前统一转为UTF-8并清理BOM、控制符等非法字节。
ThinkPHP 里拼接字符串后出现乱码、中文变问号或，不是因为拼接动作本身出错，而是原始字符串编码不一致 + 拼接时机不当导致的隐性损坏。直接用.拼接两个不同编码的字符串（比如 UTF-8 和 GBK），PHP 不报错，但结果不可预测——你看到的是“用户”+“张三”变成“用户寮笁”，而这个损坏在后续任何地方都无法修复。
拼接前没统一编码，.会静默破坏内容
ThinkPHP 的 input()、config()、数据库查询结果默认按当前环境字符集返回，但老旧接口、文件读取、第三方 SDK 返回的数据可能仍是 GBK 或 ISO-8859-1。一旦混入拼接链，就立即污染整个结果。
- 不要假设
input('name')是 UTF-8：IE6/7 提交的表单、某些嵌入式设备 HTTP 请求头不带charset，TP6 默认当 UTF-8 解析，实际却是 GBK 字节流 - 读取本地配置文件（如
conf.ini）时，用file_get_contents()拿到原始字节，必须显式转码再拼接：mb_convert_encoding(file_get_contents($path), 'UTF-8', 'GBK') -
Db::query()返回的字段值，如果数据库连接字符集是utf8（非utf8mb4）且字段含 emoji，部分版本 PDO 会截断或替换为?，拼接前先检查mb_strlen($str, 'UTF-8')是否异常缩水
json_encode() 失败常因拼接后残留非法控制符
拼接后的字符串传给 json_encode() 返回 null，json_last_error() 报 JSON_ERROR_UTF8，大概率是拼接过程中混入了不可见的 \r、
拼接后的字符串传给 json_encode() 返回 null，json_last_error() 报 JSON_ERROR_UTF8，大概率是拼接过程中混入了不可见的 \r、\0 或 Windows BOM（\xEF\xBB\xBF）。这类字符浏览器不显示，但 JSON 解析器直接拒绝。
\xEF\xBB\xBF）。这类字符浏览器不显示，但 JSON 解析器直接拒绝。
- 拼接后立刻清理：
$safe = str_replace(["\r\n", "\r", "\n", "\0"], '', $unsafe)（注意顺序：先换\r\n，再换单独\r） - 对富文本编辑器提交的内容（如 UEditor），入库前强制标准化换行：
str_replace(["\r\n", "\r"], "\n", $content)，再做htmlspecialchars() - 避免用
trim()清理 BOM：trim()对\xEF\xBB\xBF无效；改用ltrim($str, "\xEF\xBB\xBF")
模板中拼接 HTML 字符串易触发双重转义
控制器里写 $data['title'] = $prefix . input('title');，模板中写 {:$data.title|htmlspecialchars|nl2br}，看似安全，实则危险：如果 input('title') 已被框架自动转义过（如开启 default_filter），再套一次 htmlspecialchars() 就变成 < 这类双编码。
立即学习“PHP免费学习笔记（深入）”；
- 查清框架是否开了全局过滤：
config('app.default_filter')，若为'htmlspecialchars'，拼接前先反解：htmlspecialchars_decode(input('title'), ENT_QUOTES) - 模板中禁用自动转义：
{:$data.title|raw}，但仅限你**完全信任该变量来源**（如后台管理员输入、已清洗过的配置项） - 拼接后需保留 HTML 标签？改用
strip_tags($str, '<p><br><strong>')
白名单过滤，比层层转义更可控
最麻烦的不是拼接动作本身，而是拼接点分散在控制器、模型、中间件甚至视图里，每个环节都可能悄悄引入编码差异。建议在应用入口（public/index.php）顶部加一行日志钩子：mb_internal_encoding('UTF-8');，并定期用 mb_check_encoding($str, 'UTF-8') 抽样校验关键变量。
