ThinkPHP 默认已设 UTF-8，手动加 header() 易因前置输出导致“headers already sent”错误；真正需检查的是配置文件 charset、数据库连接与表结构的 utf8mb4 设置及 HTML meta 标签。
ThinkPHP 默认已处理好字符编码，手动加 header('Content-Type: text/html; charset=utf-8'); 通常不必要，甚至可能引发重复输出或 header 已发送错误。
为什么在控制器里加 header() 很容易报错
ThinkPHP 的输出流程中，视图渲染、模板解析、钩子执行等环节都可能提前触发输出缓冲或发送响应头。一旦 echo、print 或任何非空空白（比如文件末尾多了一个换行）出现在 header() 调用前，就会报 Warning: Cannot modify header information - headers already sent。
- 控制器方法开头加
header()仍可能失败——因为前置操作（如日志写入、Session 启动）已隐式输出 - 模板文件（.html 或 .php 模板）里加
header()更危险，属于“绝对禁止”位置 - 入口文件
public/index.php是唯一相对安全的加点，但没必要——框架已默认设 UTF-8
真正该检查和设置编码的地方是配置和数据库连接
页面显示乱码，90% 不是 HTTP 头问题，而是数据源头或模板解析没对齐 UTF-8。
- 确认
config/app.php中'default_charset' => 'utf-8'（TP6+ 默认已是该值） - 检查数据库连接配置：
config/database.php的'charset'必须为'utf8mb4'，且对应 MySQL 表/字段也需是utf8mb4_unicode_ci - HTML 模板头部必须有
<meta charset="utf-8">，否则浏览器可能按 ISO-8859-1 解析 - 如果用
Response::create()手动构造响应，才需显式传['contentType' => 'text/html; charset=utf-8']
调试乱码时优先看这三处输出源
不要一上来就加 header()，先定位真实瓶颈。
立即学习“PHP免费学习笔记（深入）”；
- 用
var_dump(mb_detect_encoding($str))检查变量实际编码，别信文件保存格式 - 用浏览器开发者工具 → Network → Response Headers 查看真实的
Content-Type值（不是 HTML 里的 meta） - 用
SHOW CREATE TABLE xxx确认 MySQL 表结构编码，utf8（3 字节）不支持 emoji，必须utf8mb4
最常被忽略的是数据库连接层和表结构的编码不一致——哪怕 PHP 和 HTML 都设对了，从 DB 读出来的仍是乱码字节流，后面怎么加 header() 都没用。
