thinkphp模板中文乱码主因是输出链路编码不一致，首要排查并清除php/html文件的utf-8 bom；bom会提前输出导致content-type失效，浏览器误用iso-8859-1解析。
ThinkPHP模板中变量输出中文乱码的直接原因
不是框架“不支持中文”，而是输出链路上至少一个环节编码不一致：PHP文件本身含BOM、HTTP响应头未声明charset、HTML meta缺失、数据库连接字符集错配，或模板文件保存为GBK而TP默认按UTF-8读取。四个环节只要断一环，{$name}就可能变成或一堆问号。
检查并清除PHP文件BOM是第一优先级操作
BOM（EF BB BF）在UTF-8文件开头不可见，但会提前触发输出，导致header('Content-Type: text/html; charset=utf-8')失效，浏览器 fallback 到ISO-8859-1解析——这是最常被忽略却最致命的一环。
- 用VS Code打开所有
.php和.html模板文件，右下角查看编码显示，若为“UTF-8 with BOM”，点击切换为“UTF-8”并保存 - Notepad++中：编码 → 转为UTF-8无BOM格式 → 保存
- Linux服务器上批量检测：
grep -rl $'\xEF\xBB\xBF' ./app/ ./public/ ./config/，找到后用sed -i '1s/^\xEF\xBB\xBF//' file.php清除 - 确认
config.php中没有空行或空格在<?php之前，否则namespace报错或header发送失败
数据库查询结果中文变乱码的典型场景与修复
即使页面和文件都是UTF-8，Db::name('user')->where('name', '张三')->find()返回的$data['name']仍是乱码，大概率是PDO连接层没对齐utf8mb4。
-
database.php中必须设'charset' => 'utf8mb4'，不能写'utf8'（MySQL的utf8实际是utf8mb3，不支持emoji和部分生僻汉字） - 检查表结构：
SHOW CREATE TABLE user，确认末尾是DEFAULT CHARSET=utf8mb4，不是utf8 - DSN字符串里显式加
;charset=utf8mb4，例如mysql:host=127.0.0.1;dbname=test;charset=utf8mb4 - 避免依赖
SET NAMES utf8mb4自动执行——TP 6.x虽默认开启，但某些IIS或老旧PDO驱动下可能不生效，可在database.php的'deploy' => 0时手动加'params' => [\PDO::MYSQL_ATTR_INIT_COMMAND => 'SET NAMES utf8mb4']
IIS环境下GET参数中文乱码必须转码再解码
IIS URL重写模块默认按GBK编码处理中文路径参数，而TP应用是UTF-8，$_GET['q']拿到的是GBK字节流，直接查库必然失败。
- 不要尝试全局修改IIS请求编码——不可靠且影响其他服务
- 在控制器入口处统一转换：
$q = mb_convert_encoding($this->request->param('q'), 'UTF-8', 'GBK');或$q = iconv('GBK', 'UTF-8//IGNORE', $this->request->param('q')); - 若前端是JS生成链接，必须用
encodeURIComponent('张三')，后端用urldecode()即可，无需iconv - 注意：TP的
U()函数已废弃，新版应改用url('index/search', ['q' => rawurlencode($keyword)])，rawurlencode()比urlencode()更安全，不把空格转成+
真正难调试的从来不是“哪里要改”，而是“改了哪一处却忘了同步改另一处”。比如清掉了BOM，却忘了数据库表还是utf8；设了charset=utf8mb4，但Nginx又偷偷加了charset gbk响应头。乱码问题本质是编码契约断裂，修复的关键在于让文件、传输、存储、渲染四者咬合在同一编码轨道上，缺一不可。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
